From teco@inf-net.nl Mon Oct 1 14:01:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F281F0D36 for ; Mon, 1 Oct 2012 14:01:22 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDDZnmk+ueBa for ; Mon, 1 Oct 2012 14:01:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E82BE1F0CD6 for ; Mon, 1 Oct 2012 14:01:21 -0700 (PDT) Received: by eekd4 with SMTP id d4so2775397eek.31 for ; Mon, 01 Oct 2012 14:01:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=jUzwIMM4m8kDvRSvVh9dIHNfqf2Ilo2Xo1Q3be3PIQc=; b=DgDNk6kmdaudIt98jtpwKl8cFrM1HOUPFHYiCV9NAZREdj/RZhE9qGr61SIEt2qU56 bMrtRpXsSJcwBfD6Ck/ny9kJlxGGGXz+GTjBHGv9/dyQr55Mm3IL0N3MO2YYGc6c6ycR QceBDcEJFM8B4DMKueb8NYCUJ9jQvtOsb1n51rDixHAD7WZUsOFOF1mumJJhIzabRrC5 0rYCiwinC4FMzVLJSccrv8eKieS0HyDfvvaIbS9XSAwy77r3eePMXRL/BniNZYOSU0+f gSrulcuivVfQa26aJmYNsLmlKbpS5l2chAPAcmiz3wUj2XwHJS0rg/X8NL/uiVzmc8OR q+xQ== Received: by 10.14.1.69 with SMTP id 45mr5767522eec.23.1349125280244; Mon, 01 Oct 2012 14:01:20 -0700 (PDT) Received: from [10.175.173.28] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id e7sm51038492eep.2.2012.10.01.14.01.19 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 14:01:19 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 1 Oct 2012 23:01:17 +0200 Message-Id: To: " List" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnPOX015rn9Sx5m1CIy9ZBqKMRffKl0GdEBdNzVdv5qkwfU/g0uCzf5c6ovZtkg5CuCyRwq Subject: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:01:23 -0000 I quickly browsed thru the manet-dlep-03 draft and diff with the -02 version. I wonder why the draft is changed as it is. Does it reflect any workgroup decisions? Or is it a best effort undertaken by some authors? Or maybe, is this protocol in hands of Cisco instead of our workgroup? I can see improvement on readability (router and modem, not client and server). Thanks for this. I still don't like the "participants" term. I prefer the clear router or modem terms, where the modem is the only participant that provides data. I see a change from RFC 5444 messages to something else, with UDP as a suggestion. This is underspecified and does not lead to a standard protocol. There is a need to specify the basics. The main purpose of the protocol is to get link metrics for links between router interfaces, from modem to router. In general, (ethernet) interfaces have MAC addresses. I can't see why different IDs are needed, where the MAC addresses would be fine. There are a couple of functions in DLEP that are redundant, because other protocols or mechanisms can provide it. Credits is one example (packet scheduling is to be performed on bottleneck, thus the modem). MAC - IP address resolution is another (standard ARP/ND is to be used, probably with proxy functions to get quick resolution). And there is SNMP. The suggested metric types looks rather useful, but some experience showed me that it is difficult for a router to interpret these data. Also, with a large variety of L2 technology, it seems unwise and hard to me to support all of that in a general purpose router. Especially when the outcome is as simple as a dimensionless additive metric, such as in OLSR. I would specify only one mandatory metric type and all the rest as optional. This mandatory would be the link metric as we have defined in OLSRv2. I don't get why the Heartbeat Interval/Threshold is optional. It looks essential to me. And interval could be fractions of a second. The protocol needs synchronized state machines, maybe with an n to m relation between routers and modems. Getting this right is not that simple. I would use TCP for unicast connections, or use a simple timer-based database update exchange, just like OLSR. Section 7 misses some ACK signal TLVs. The Neighbor Update ACK is only mentioned in 9.18 credit request. I can't find details on the Ack mechanism, e.g. message sequence numbers. On Link Characteristics Request, fulfilling the request could take some time. How the modem should provide feedback on such is unclear. I'm looking forward to a fruitful discussions how we can work this out. Teco From abdussalambaryun@gmail.com Tue Oct 2 05:28:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133AD21F87C8 for ; Tue, 2 Oct 2012 05:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukc+OA19T0+T for ; Tue, 2 Oct 2012 05:28:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE0FF21F87BD for ; Tue, 2 Oct 2012 05:28:57 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so7585804vcb.31 for ; Tue, 02 Oct 2012 05:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=D1SwYRh1pUHQqkr9S0HZqso5odUrNHtIARSNGP0r8OM=; b=HiQcc47BaUuQS6/zGeliCfEn0Qn2qRv52wYt+fkpA8uOh6RxkiHrP0YO6qer9BMrPi Ya3e6OhdZO5hODigZKluchhOwLegO5x7P+S94G+KsxMuaap3r9kE5x69lJ0wagiEIfgH Sro7sX/1THs1MOfznpDe1iTGziHM5tM8FZ7+0/ZpEUn4vw9Q01yzfSElXueMWWq4SNBc 4cxrg2eAkxKgdJZAHtzWwl96OrmDkzZy8U+qP98HMHseHIu+g10cnTuhJTy9fblY6WW1 +TVc25+Zm8xHdCX8tIEoV1pXVOgzreQNlsgicBldpHJWmWMjsIerOT49n7sMdEBFtZrC 0DZg== MIME-Version: 1.0 Received: by 10.58.32.233 with SMTP id m9mr10413909vei.23.1349180937045; Tue, 02 Oct 2012 05:28:57 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 2 Oct 2012 05:28:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 13:28:56 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7b3392297d865004cb12aa19 Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:28:59 -0000 --047d7b3392297d865004cb12aa19 Content-Type: text/plain; charset=ISO-8859-1 +++++++++++++++ Last reminder +++++++++++++++ To: LOADng Workers, Hi Due to your proposal twice in MANET WG without following to discuss issues, please reply. Are you welling to answer and discuss? please advise, AB +++ On Sat, Sep 1, 2012 at 7:41 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > From 29-March-2012 until 30-July-2012 and now, loadng authors did not > discuss issues, however, I will send a fourth reminder after three > weeks if no responds. Have a nice vacation, > > Best Regards > AB > > On 9/1/12, Thomas Heide Clausen wrote: > > You address me nominatively so I will respond - but, note that I am but > one > > among the authors. > > > > I believe that all the various feedback currently is being digested by > the > > authors - but, do not forget that August is vacation-week in good parts > of > > Europe, and some of us are only just coming back to the office. > > > > Best, > > > > Thomas > > > > > > -- > > Thomas Heide Clausen > > http://www.thomasclausen.org/ > > > > "Any simple problem can be made insoluble if enough meetings are held to > > discuss it." > > -- Mitchell's Law of Committees > > > > > > On 1 Sep 2012, at 02:48, Abdussalam Baryun > > wrote: > > > >> +++++++++++++++ Third Reminder ++++++++++++++++ > >> > >> Hi Thomas, > >> > >> I have two emails (on 30 May and on 31 July, as below) of suggestions > >> and questions not responded to, please your respond is important for > >> progress and discussion on the list. I beleive the issue was also > >> raised in the last WG meeting on 30 July, and the WG agrees to see > >> discussion. Not sure if the authors are willing change the draft or > >> not. > >> > >> AB > >> === > >> On 7/31/12, Abdussalam Baryun wrote: > >>> Hi Thomas and All > >>> > >>> I am interested in LOADng and did discuss about it from May 2012 until > >>> now. I gave comments [1] on LOADng but no respond so far, I asked from > >>> before for more discussion but there was no, and hope that we don't > >>> forget the past comments on any document in ietf. The LOADng SHOULD > >>> specify use case that are related to MANET not LLN. I suggest that the > >>> word LLN taken out of the name as well and specify mobility [1-2]. > >>> > >>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but > >>> then changed its direction to MANET [3]. However, please note that > >>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > >>> said, LOADng SHOULD specfy where is its limits. Then we can discuss > >>> adoption. > >>> > >>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html > >>> [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html > >>> [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html > >>> > >>> thanking you, > >>> AB > >>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun > >>>> wrote: > >>>>> On 5/29/12, JP Vasseur wrote: > >>>>>> > >>>>>> We already have two different WG: MANET and ROLL. > >>>>>> > >>>>> > >>>>> Yes we know. That is why LOADng authors should choose either to serve > >>>>> LLN that is considered by ROLL WG or they choose serving MANET, and > it > >>>>> is considered by MANET WG. But the question is which suggestion > option > >>>>> do you think is better for LOADng-draft? > >>>>> > >>>>>> MANET is tasked, amongst other, to publish a reactive > >>>>>> routing protocol. > >>>>> > >>>>> MANET is tasked to publish routing protocols that serve the MANET > >>>>> network. IMO, MANET-WG is not tasked to publish protocols serving > only > >>>>> LLN just because the protocol is reactive. Please note that LOADng > >>>>> protocol does not even mention MANET nor mobile routers in its draft, > >>>>> which confuses its purpose, the authors should look into that. > >>>>> > >>>>> Abdussalam Baryun > >>>> > >>> > > > --047d7b3392297d865004cb12aa19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+++++++++++++++ Last reminder=A0 +++++++++++++++
To: LOADng = Workers,
Hi
=A0
Due to your proposal twic= e in MANET WG without following to discuss issues, please reply. Are you we= lling to answer and discuss? please advise,
=A0
AB
+++
On Sat, Sep 1, 2012 at 7:41 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
From 29-March-2012 until 30-July-2012 and now, loadng auth= ors did not
discuss issues, however, I will send a fourth reminder after three
weeks if no responds. Have a nice vacation,

Best Regards
AB

On 9/1/12, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:
> You address me nominatively so I will respond - but, note that I am bu= t one
> among the authors.
>
> I believe that all the various feedback currently is being digested by= the
> authors - but, do not forget that August is vacation-week in good part= s of
> Europe, and some of us are only just coming back to the office.
>
> Best,
>
> Thomas
>
>
> --
> Thomas Heide Clausen
> http://www= .thomasclausen.org/
>
> "Any simple problem can be made insoluble if enough meetings are = held to
> =A0discuss it."
> =A0 =A0-- Mitchell's Law of Committees
>
>
> On 1 Sep 2012, at 02:48, Abdussalam Baryun <abdussalambaryun@gmail.com>
> wrote:
>
>> +++++++++++++++ =A0Third Reminder =A0++++++++++++++++
>>
>> Hi Thomas,
>>
>> I have two emails (on 30 May and on 31 July, as below) of suggesti= ons
>> and questions not responded to, please your respond is important f= or
>> progress and discussion on the list. I beleive the issue was also<= br> >> raised in the last WG meeting on 30 July, and the WG agrees to see=
>> discussion. Not sure if the authors are willing change the draft o= r
>> not.
>>
>> AB
>> =3D=3D=3D
>> On 7/31/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
>>> Hi Thomas and All
>>>
>>> I am interested in LOADng and did discuss about it from May 20= 12 until
>>> now. I gave comments [1] on LOADng but no respond so far, I as= ked from
>>> before for more discussion but there was no, and hope that we = don't
>>> forget the past comments on any document in ietf. The LOADng S= HOULD
>>> specify use case that are related to MANET not LLN. I suggest = that the
>>> word LLN taken out of the name as well and specify mobility [1= -2].
>>>
>>> IMHO this protocol was intended as for ROLL WG not for MANET W= G, but
>>> then changed its direction to MANET [3]. However, please note = that
>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. = That
>>> said, LOADng SHOULD specfy where is its limits. Then we can di= scuss
>>> adoption.
>>>
>>> [1] http://www.ietf.org/mail-archive/web/m= anet/current/msg12924.html
>>> [2] http://www.ietf.org/mail-archive/web/m= anet/current/msg12928.html
>>> [3] http://www.ietf.org/mail-archive/web/m= anet/current/msg12933.html
>>>
>>> thanking you,
>>> AB
>>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun
>>>> <abdussalambaryun at gmail.com> wrote:
>>>>> On 5/29/12, JP Vasseur <jpv at cisco.com> wrote:
>>>>>>
>>>>>> We already have two different WG: MANET and ROLL.<= br> >>>>>>
>>>>>
>>>>> Yes we know. That is why LOADng authors should choose = either to serve
>>>>> LLN that is considered by ROLL WG or they choose servi= ng MANET, and it
>>>>> is considered by MANET WG. But the question is which s= uggestion option
>>>>> do you think is better for LOADng-draft?
>>>>>
>>>>>> MANET is tasked, amongst other, to publish a react= ive
>>>>>> routing protocol.
>>>>>
>>>>> MANET is tasked to publish routing protocols that serv= e the MANET
>>>>> network. IMO, MANET-WG is not tasked to publish protoc= ols serving only
>>>>> LLN just because the protocol is reactive. Please note= that LOADng
>>>>> protocol does not even mention MANET nor mobile router= s in its draft,
>>>>> which confuses its purpose, the authors should look in= to that.
>>>>>
>>>>> Abdussalam Baryun
>>>>
>>>
>

--047d7b3392297d865004cb12aa19-- From ietf@thomasclausen.org Tue Oct 2 05:41:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25E721F8899 for ; Tue, 2 Oct 2012 05:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Oz5rRcqxHw for ; Tue, 2 Oct 2012 05:41:11 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 55CBD21F888F for ; Tue, 2 Oct 2012 05:41:00 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C792DA3901 for ; Tue, 2 Oct 2012 05:40:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A38FB1BD4529; Tue, 2 Oct 2012 05:40:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A63D21BD4515; Tue, 2 Oct 2012 05:40:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_46609B19-6056-4792-A7F9-2A2C3D97129A" Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Clausen In-Reply-To: Date: Tue, 2 Oct 2012 14:40:54 +0200 Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1498) Cc: manet Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:41:13 -0000 --Apple-Mail=_46609B19-6056-4792-A7F9-2A2C3D97129A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 To: Worker Abdussalam The emails you reference contain your opinions. I do not see any constructive questions or suggestions in there. Maybe that is one reason, why there has been no follow-up to these = mails? Thomas On Oct 2, 2012, at 2:28 PM, Abdussalam Baryun = wrote: > +++++++++++++++ Last reminder +++++++++++++++ > To: LOADng Workers, > Hi > =20 > Due to your proposal twice in MANET WG without following to discuss = issues, please reply. Are you welling to answer and discuss? please = advise, > =20 > AB > +++ > On Sat, Sep 1, 2012 at 7:41 PM, Abdussalam Baryun = wrote: > =46rom 29-March-2012 until 30-July-2012 and now, loadng authors did = not > discuss issues, however, I will send a fourth reminder after three > weeks if no responds. Have a nice vacation, >=20 > Best Regards > AB >=20 > On 9/1/12, Thomas Heide Clausen wrote: > > You address me nominatively so I will respond - but, note that I am = but one > > among the authors. > > > > I believe that all the various feedback currently is being digested = by the > > authors - but, do not forget that August is vacation-week in good = parts of > > Europe, and some of us are only just coming back to the office. > > > > Best, > > > > Thomas > > > > > > -- > > Thomas Heide Clausen > > http://www.thomasclausen.org/ > > > > "Any simple problem can be made insoluble if enough meetings are = held to > > discuss it." > > -- Mitchell's Law of Committees > > > > > > On 1 Sep 2012, at 02:48, Abdussalam Baryun = > > wrote: > > > >> +++++++++++++++ Third Reminder ++++++++++++++++ > >> > >> Hi Thomas, > >> > >> I have two emails (on 30 May and on 31 July, as below) of = suggestions > >> and questions not responded to, please your respond is important = for > >> progress and discussion on the list. I beleive the issue was also > >> raised in the last WG meeting on 30 July, and the WG agrees to see > >> discussion. Not sure if the authors are willing change the draft or > >> not. > >> > >> AB > >> =3D=3D=3D > >> On 7/31/12, Abdussalam Baryun wrote: > >>> Hi Thomas and All > >>> > >>> I am interested in LOADng and did discuss about it from May 2012 = until > >>> now. I gave comments [1] on LOADng but no respond so far, I asked = from > >>> before for more discussion but there was no, and hope that we = don't > >>> forget the past comments on any document in ietf. The LOADng = SHOULD > >>> specify use case that are related to MANET not LLN. I suggest that = the > >>> word LLN taken out of the name as well and specify mobility [1-2]. > >>> > >>> IMHO this protocol was intended as for ROLL WG not for MANET WG, = but > >>> then changed its direction to MANET [3]. However, please note that > >>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > >>> said, LOADng SHOULD specfy where is its limits. Then we can = discuss > >>> adoption. > >>> > >>> [1] = http://www.ietf.org/mail-archive/web/manet/current/msg12924.html > >>> [2] = http://www.ietf.org/mail-archive/web/manet/current/msg12928.html > >>> [3] = http://www.ietf.org/mail-archive/web/manet/current/msg12933.html > >>> > >>> thanking you, > >>> AB > >>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun > >>>> wrote: > >>>>> On 5/29/12, JP Vasseur wrote: > >>>>>> > >>>>>> We already have two different WG: MANET and ROLL. > >>>>>> > >>>>> > >>>>> Yes we know. That is why LOADng authors should choose either to = serve > >>>>> LLN that is considered by ROLL WG or they choose serving MANET, = and it > >>>>> is considered by MANET WG. But the question is which suggestion = option > >>>>> do you think is better for LOADng-draft? > >>>>> > >>>>>> MANET is tasked, amongst other, to publish a reactive > >>>>>> routing protocol. > >>>>> > >>>>> MANET is tasked to publish routing protocols that serve the = MANET > >>>>> network. IMO, MANET-WG is not tasked to publish protocols = serving only > >>>>> LLN just because the protocol is reactive. Please note that = LOADng > >>>>> protocol does not even mention MANET nor mobile routers in its = draft, > >>>>> which confuses its purpose, the authors should look into that. > >>>>> > >>>>> Abdussalam Baryun > >>>> > >>> > > >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_46609B19-6056-4792-A7F9-2A2C3D97129A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 abdussalambaryun@gmail.com&= gt; wrote:
+++++++++++++++ Last reminder  = +++++++++++++++
To: LOADng = Workers,
Hi
 
Due to your = proposal twice in MANET WG without following to discuss issues, please = reply. Are you welling to answer and discuss? please advise,
 
AB
+++
On Sat, Sep 1, 2012 at 7:41 PM, Abdussalam Baryun = <abdussalambaryun@gmail.com> wrote:
=46rom = 29-March-2012 until 30-July-2012 and now, loadng authors did not
discuss issues, however, I will send a fourth reminder after three
weeks if no responds. Have a nice vacation,

Best Regards
AB

On 9/1/12, Thomas Heide Clausen <ietf@thomasclausen.org> = wrote:
> You address me nominatively so I will respond - but, note that I am = but one
> among the authors.
>
> I believe that all the various feedback currently is being digested = by the
> authors - but, do not forget that August is vacation-week in good = parts of
> Europe, and some of us are only just coming back to the office.
>
> Best,
>
> Thomas
>
>
> --
> Thomas Heide Clausen
> http://www.thomasclausen.org/
>
> "Any simple problem can be made insoluble if enough meetings are = held to
>  discuss it."
>    -- Mitchell's Law of Committees
>
>
> On 1 Sep 2012, at 02:48, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt;
> wrote:
>
>> +++++++++++++++  Third Reminder  ++++++++++++++++
>>
>> Hi Thomas,
>>
>> I have two emails (on 30 May and on 31 July, as below) of = suggestions
>> and questions not responded to, please your respond is = important for
>> progress and discussion on the list. I beleive the issue was = also
>> raised in the last WG meeting on 30 July, and the WG agrees to = see
>> discussion. Not sure if the authors are willing change the = draft or
>> not.
>>
>> AB
>> =3D=3D=3D
>> On 7/31/12, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:
>>> Hi Thomas and All
>>>
>>> I am interested in LOADng and did discuss about it from May = 2012 until
>>> now. I gave comments [1] on LOADng but no respond so far, I = asked from
>>> before for more discussion but there was no, and hope that = we don't
>>> forget the past comments on any document in ietf. The = LOADng SHOULD
>>> specify use case that are related to MANET not LLN. I = suggest that the
>>> word LLN taken out of the name as well and specify mobility = [1-2].
>>>
>>> IMHO this protocol was intended as for ROLL WG not for = MANET WG, but
>>> then changed its direction to MANET [3]. However, please = note that
>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are = LLNs. That
>>> said, LOADng SHOULD specfy where is its limits. Then we can = discuss
>>> adoption.
>>>
>>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12= 924.html
>>> [2] http://www.ietf.org/mail-archive/web/manet/current/msg12= 928.html
>>> [3] http://www.ietf.org/mail-archive/web/manet/current/msg12= 933.html
>>>
>>> thanking you,
>>> AB
>>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun
>>>> <abdussalambaryun at gmail.com> wrote:
>>>>> On 5/29/12, JP Vasseur <jpv at cisco.com> = wrote:
>>>>>>
>>>>>> We already have two different WG: MANET and = ROLL.
>>>>>>
>>>>>
>>>>> Yes we know. That is why LOADng authors should = choose either to serve
>>>>> LLN that is considered by ROLL WG or they choose = serving MANET, and it
>>>>> is considered by MANET WG. But the question is = which suggestion option
>>>>> do you think is better for LOADng-draft?
>>>>>
>>>>>> MANET is tasked, amongst other, to publish a = reactive
>>>>>> routing protocol.
>>>>>
>>>>> MANET is tasked to publish routing protocols that = serve the MANET
>>>>> network. IMO, MANET-WG is not tasked to publish = protocols serving only
>>>>> LLN just because the protocol is reactive. Please = note that LOADng
>>>>> protocol does not even mention MANET nor mobile = routers in its draft,
>>>>> which confuses its purpose, the authors should look = into that.
>>>>>
>>>>> Abdussalam Baryun
>>>>
>>>
>

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

<= /body>= --Apple-Mail=_46609B19-6056-4792-A7F9-2A2C3D97129A-- From abdussalambaryun@gmail.com Tue Oct 2 08:13:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5664121F846D for ; Tue, 2 Oct 2012 08:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhYZDgz0UY-i for ; Tue, 2 Oct 2012 08:13:49 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2294F21F8460 for ; Tue, 2 Oct 2012 08:13:49 -0700 (PDT) Received: by iado25 with SMTP id o25so863760iad.31 for ; Tue, 02 Oct 2012 08:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8Z3P+KOVHEWN7/OnWMU9hl//fisWBXNfV7D6BbqcItk=; b=Z1U+2v7u0O2iTDd1RTa4hu10tUwXz62UXgHP0cObxn27HpouWoAcrRJsJFMLwYP5IR aLWYoTA+mAariUjmB9I6Qh/xHNNe2J0XICQymlCxh5U/2d+6FJmfnN8q7rViy+125XlP ebRWBqFXFDR/sTWZqBcPBJKGXtDwSJP7iSEjX6ntrwu+BBo37+GXJWp9RVxcQsA6yk7h 7YywlY7AYgaZ/oyHzG0RBzBwIuHhOD3BPo0YUO1T7nd/BJayW15Bd9PGj56S7szzvQ23 m/swthVcVsy0nOBUD7oWt0fHY6bLTGfTT3MvcPbKwVn8Ged0W4WZFFl2i6YJGBntjOo+ dz8A== MIME-Version: 1.0 Received: by 10.50.5.180 with SMTP id t20mr9264318igt.31.1349190828411; Tue, 02 Oct 2012 08:13:48 -0700 (PDT) Received: by 10.64.25.46 with HTTP; Tue, 2 Oct 2012 08:13:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 16:13:48 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=e89a8f5025480fcad904cb14f8a7 Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:13:50 -0000 --e89a8f5025480fcad904cb14f8a7 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, >Maybe that is one reason, why there has been no follow-up to these mails? no, I think the authors still not ready to discuss, I provided suggestion to the authors for some options [1], and wanted their respond on the MANET-List, then got a reply from an author [2] to wait. After that I got a new draft of LOADng [3] without including MANET but LLN. However, one of suggestion option been taken (joining more authors). [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg12939.html [3] http://tools.ietf.org/html/draft-clausen-lln-loadng-05 First on 30 May, I understood that the authors will amend the document to be for MANET not ROLL by including MANET and reducing refering to LLN. When introduced again in meeting 84 still not changed, I am not sure are you welling to discuss what you will do on the MANET list or you like to discuss it another list/place. Are the authors of the individual draft sure where/when to discuss with the community? Please advise, Regards AB ----- On Tue, Oct 2, 2012 at 1:40 PM, Thomas Clausen wrote: > To: Worker Abdussalam > > The emails you reference contain your opinions. > I do not see any constructive questions or suggestions in there. > > Maybe that is one reason, why there has been no follow-up to these mails? > > Thomas > > On Oct 2, 2012, at 2:28 PM, Abdussalam Baryun > wrote: > > +++++++++++++++ Last reminder +++++++++++++++ > To: LOADng Workers, > Hi > > Due to your proposal twice in MANET WG without following to discuss > issues, please reply. Are you welling to answer and discuss? please advise, > > AB > +++ > On Sat, Sep 1, 2012 at 7:41 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> From 29-March-2012 until 30-July-2012 and now, loadng authors did not >> discuss issues, however, I will send a fourth reminder after three >> weeks if no responds. Have a nice vacation, >> >> Best Regards >> AB >> >> On 9/1/12, Thomas Heide Clausen wrote: >> > You address me nominatively so I will respond - but, note that I am but >> one >> > among the authors. >> > >> > I believe that all the various feedback currently is being digested by >> the >> > authors - but, do not forget that August is vacation-week in good parts >> of >> > Europe, and some of us are only just coming back to the office. >> > >> > Best, >> > >> > Thomas >> > >> > >> > -- >> > Thomas Heide Clausen >> > http://www.thomasclausen.org/ >> > >> > "Any simple problem can be made insoluble if enough meetings are held to >> > discuss it." >> > -- Mitchell's Law of Committees >> > >> > >> > On 1 Sep 2012, at 02:48, Abdussalam Baryun >> > wrote: >> > >> >> +++++++++++++++ Third Reminder ++++++++++++++++ >> >> >> >> Hi Thomas, >> >> >> >> I have two emails (on 30 May and on 31 July, as below) of suggestions >> >> and questions not responded to, please your respond is important for >> >> progress and discussion on the list. I beleive the issue was also >> >> raised in the last WG meeting on 30 July, and the WG agrees to see >> >> discussion. Not sure if the authors are willing change the draft or >> >> not. >> >> >> >> AB >> >> === >> >> On 7/31/12, Abdussalam Baryun wrote: >> >>> Hi Thomas and All >> >>> >> >>> I am interested in LOADng and did discuss about it from May 2012 until >> >>> now. I gave comments [1] on LOADng but no respond so far, I asked from >> >>> before for more discussion but there was no, and hope that we don't >> >>> forget the past comments on any document in ietf. The LOADng SHOULD >> >>> specify use case that are related to MANET not LLN. I suggest that the >> >>> word LLN taken out of the name as well and specify mobility [1-2]. >> >>> >> >>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >> >>> then changed its direction to MANET [3]. However, please note that >> >>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >> >>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >> >>> adoption. >> >>> >> >>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html >> >>> [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html >> >>> [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html >> >>> >> >>> thanking you, >> >>> AB >> >>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun >> >>>> wrote: >> >>>>> On 5/29/12, JP Vasseur wrote: >> >>>>>> >> >>>>>> We already have two different WG: MANET and ROLL. >> >>>>>> >> >>>>> >> >>>>> Yes we know. That is why LOADng authors should choose either to >> serve >> >>>>> LLN that is considered by ROLL WG or they choose serving MANET, and >> it >> >>>>> is considered by MANET WG. But the question is which suggestion >> option >> >>>>> do you think is better for LOADng-draft? >> >>>>> >> >>>>>> MANET is tasked, amongst other, to publish a reactive >> >>>>>> routing protocol. >> >>>>> >> >>>>> MANET is tasked to publish routing protocols that serve the MANET >> >>>>> network. IMO, MANET-WG is not tasked to publish protocols serving >> only >> >>>>> LLN just because the protocol is reactive. Please note that LOADng >> >>>>> protocol does not even mention MANET nor mobile routers in its >> draft, >> >>>>> which confuses its purpose, the authors should look into that. >> >>>>> >> >>>>> Abdussalam Baryun >> >>>> >> >>> >> > >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --e89a8f5025480fcad904cb14f8a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
>Maybe that is one reason, why t= here has been no follow-up to these mails?
no, I think the author= s still not ready=A0to discuss,
=A0
I provided suggest= ion to the authors for some options [1], and wanted their respond on the MA= NET-List, then got a reply from an author=A0[2] to wait. After that I got a= new draft of LOADng [3] without including MANET but=A0LLN. However, one of= suggestion option been taken (joining more authors).
=A0
=A0
First on 30 May, I understood that the authors will amend the docu= ment to be for MANET not ROLL by including MANET and reducing=A0refering to= LLN.=A0When introduced again in meeting 84 still not changed,
=A0
I am not sure are you welling to discuss what you will d= o on the MANET=A0list or you like to discuss it another list/place. Are the= authors=A0of the individual draft sure where/when to discuss with the comm= unity? Please advise,
Regards
AB
-----
On= Tue, Oct 2, 2012 at 1:40 PM, Thomas Clausen <ietf@thomasclausen.org= > wrote:
To: Worker Abduss= alam

The emails you reference contain your opinions.
I do not= see any constructive questions or suggestions in there.

Maybe that is one reason, why there has been no follow-up to these mails?<= /div>

Thomas

On Oct 2, 2012, at 2:28 PM= , Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

+++++= ++++++++++ Last reminder=A0 +++++++++++++++
To: LOADng Workers,
Hi
=A0
Due to your proposal twice in MANET= WG without following to discuss issues, please reply. Are you welling to a= nswer and discuss? please advise,
=A0
AB
+++
On Sat, Sep 1, 2012 at 7:41 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
From 29-March-2012 until 30-July-2012 and now, loadng auth= ors did not
discuss issues, however, I will send a fourth reminder after three
weeks if no responds. Have a nice vacation,

Best Regards
AB

On 9/1/12, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:
> You address me nominatively so I will respond - but, note that I am bu= t one
> among the authors.
>
> I believe that all the various feedback currently is being digested by= the
> authors - but, do not forget that August is vacation-week in good part= s of
> Europe, and some of us are only just coming back to the office.
>
> Best,
>
> Thomas
>
>
> --
> Thomas Heide Clausen
> http://www= .thomasclausen.org/
>
> "Any simple problem can be made insoluble if enough meetings are = held to
> =A0discuss it."
> =A0 =A0-- Mitchell's Law of Committees
>
>
> On 1 Sep 2012, at 02:48, Abdussalam Baryun <abdussalambaryun@gmail.com>=
> wrote:
>
>> +++++++++++++++ =A0Third Reminder =A0++++++++++++++++
>>
>> Hi Thomas,
>>
>> I have two emails (on 30 May and on 31 July, as below) of suggesti= ons
>> and questions not responded to, please your respond is important f= or
>> progress and discussion on the list. I beleive the issue was also<= br> >> raised in the last WG meeting on 30 July, and the WG agrees to see=
>> discussion. Not sure if the authors are willing change the draft o= r
>> not.
>>
>> AB
>> =3D=3D=3D
>> On 7/31/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote: >>> Hi Thomas and All
>>>
>>> I am interested in LOADng and did discuss about it from May 20= 12 until
>>> now. I gave comments [1] on LOADng but no respond so far, I as= ked from
>>> before for more discussion but there was no, and hope that we = don't
>>> forget the past comments on any document in ietf. The LOADng S= HOULD
>>> specify use case that are related to MANET not LLN. I suggest = that the
>>> word LLN taken out of the name as well and specify mobility [1= -2].
>>>
>>> IMHO this protocol was intended as for ROLL WG not for MANET W= G, but
>>> then changed its direction to MANET [3]. However, please note = that
>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. = That
>>> said, LOADng SHOULD specfy where is its limits. Then we can di= scuss
>>> adoption.
>>>
>>> [1] http://www.ietf.org/mail-archive/web/m= anet/current/msg12924.html
>>> [2] http://www.ietf.org/mail-archive/web/m= anet/current/msg12928.html
>>> [3] http://www.ietf.org/mail-archive/web/m= anet/current/msg12933.html
>>>
>>> thanking you,
>>> AB
>>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun
>>>> <abdussalambaryun at gmail.com> wrote:
>>>>> On 5/29/12, JP Vasseur <jpv at cisco.com> wrote:
>>>>>>
>>>>>> We already have two different WG: MANET and ROLL.<= br> >>>>>>
>>>>>
>>>>> Yes we know. That is why LOADng authors should choose = either to serve
>>>>> LLN that is considered by ROLL WG or they choose servi= ng MANET, and it
>>>>> is considered by MANET WG. But the question is which s= uggestion option
>>>>> do you think is better for LOADng-draft?
>>>>>
>>>>>> MANET is tasked, amongst other, to publish a react= ive
>>>>>> routing protocol.
>>>>>
>>>>> MANET is tasked to publish routing protocols that serv= e the MANET
>>>>> network. IMO, MANET-WG is not tasked to publish protoc= ols serving only
>>>>> LLN just because the protocol is reactive. Please note= that LOADng
>>>>> protocol does not even mention MANET nor mobile router= s in its draft,
>>>>> which confuses its purpose, the authors should look in= to that.
>>>>>
>>>>> Abdussalam Baryun
>>>>
>>>
>

_______________________________________________
manet mailing list
manet@ietf.org
http= s://www.ietf.org/mailman/listinfo/manet


--e89a8f5025480fcad904cb14f8a7-- From internet-drafts@ietf.org Tue Oct 2 09:47:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54C621F8539; Tue, 2 Oct 2012 09:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIk+btzhmGaO; Tue, 2 Oct 2012 09:47:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF4921F8549; Tue, 2 Oct 2012 09:47:39 -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: 4.34 Message-ID: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 09:47:39 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:47:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : The Optimized Link State Routing Protocol version 2 Author(s) : Thomas Heide Clausen Christopher Dearlove Philippe Jacquet Ulrich Herberg Filename : draft-ietf-manet-olsrv2-16.txt Pages : 108 Date : 2012-10-02 Abstract: This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hrogge@googlemail.com Wed Oct 3 00:18:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654A621F84C4 for ; Wed, 3 Oct 2012 00:18:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCu2OLfS2FpL for ; Wed, 3 Oct 2012 00:18:26 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D013B21F84BF for ; Wed, 3 Oct 2012 00:18:26 -0700 (PDT) Received: by padfb11 with SMTP id fb11so6153198pad.31 for ; Wed, 03 Oct 2012 00:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=MRUQgmBa4MHjjkGekrqbQ/xm/L4q0Dc5Xiy3gn3mn8w=; b=znRvkx3JbHQ/5smuOOfWjDcxScqxtP98ftctUtbyNXfpOE83sKLtJSMACY9adxpA6s /Ckf0KZjrW+c79HBHYu+rtJbiMid0UmCNlZ2L3gSYe/PjjNoIrWObAxt+sdbpIa2v2h6 eW91s6h6VZ+Vai2s06mw+RUtSKgA0mDdo77PkNEhLc80vR8n88+dcLhwsUNnginSt7Bz mmRfbtsM5TSgl55sau0Jx7P7uqnFNKw8V+OSI6MfN9+pCmX9BcZRgOTDcorAxJm92vbG rORW86uTderEzDIxknhyLKS5GRjsABkP8U03/R22BNpz96okLb6waFN3InAlX8blZRzL Lx6w== Received: by 10.68.138.198 with SMTP id qs6mr10644216pbb.151.1349248706561; Wed, 03 Oct 2012 00:18:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Wed, 3 Oct 2012 00:18:06 -0700 (PDT) In-Reply-To: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> References: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Wed, 3 Oct 2012 09:18:06 +0200 Message-ID: To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 07:18:27 -0000 In Section 6.2 the names of the variables a and b have been switched. Was there a specific reason for this or do I managed to miss some real change? Henning Rogge On Tue, Oct 2, 2012 at 6:47 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > Title : The Optimized Link State Routing Protocol version 2 > Author(s) : Thomas Heide Clausen > Christopher Dearlove > Philippe Jacquet > Ulrich Herberg > Filename : draft-ietf-manet-olsrv2-16.txt > Pages : 108 > Date : 2012-10-02 > > Abstract: > This specification describes version 2 of the Optimized Link State > Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-16 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-16 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From thomas@thomasclausen.org Wed Oct 3 01:22:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4FF21F85B8 for ; Wed, 3 Oct 2012 01:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru-bCjJ7sCHu for ; Wed, 3 Oct 2012 01:22:46 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id BB09521F85B1 for ; Wed, 3 Oct 2012 01:22:46 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 9128AA46DC for ; Wed, 3 Oct 2012 01:22:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D5CBE1C0797; Wed, 3 Oct 2012 01:22:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4EC8C1C0791; Wed, 3 Oct 2012 01:22:44 -0700 (PDT) References: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <28923335-41A1-4B80-BE5B-F4D53BDD6714@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Wed, 3 Oct 2012 10:22:44 +0200 To: Henning Rogge Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 08:22:47 -0000 Henning, Yes, there was a very good reason: to render consistent with RFC5497 (TimeTL= V), which also uses the exponent-mantissa encoding. Thomas Sent from my iPad On 3 oct. 2012, at 09:18, Henning Rogge wrote: > In Section 6.2 the names of the variables a and b have been switched. > Was there a specific reason for this or do I managed to miss some real > change? >=20 > Henning Rogge >=20 > On Tue, Oct 2, 2012 at 6:47 PM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. >>=20 >> Title : The Optimized Link State Routing Protocol versio= n 2 >> Author(s) : Thomas Heide Clausen >> Christopher Dearlove >> Philippe Jacquet >> Ulrich Herberg >> Filename : draft-ietf-manet-olsrv2-16.txt >> Pages : 108 >> Date : 2012-10-02 >>=20 >> Abstract: >> This specification describes version 2 of the Optimized Link State >> Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-16 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-16 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Oct 3 01:37:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0121F86A1 for ; Wed, 3 Oct 2012 01:37:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvEzyBvQu4sI for ; Wed, 3 Oct 2012 01:37:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E15C21F868A for ; Wed, 3 Oct 2012 01:37:27 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so9760280pbb.31 for ; Wed, 03 Oct 2012 01:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=L2JTevKgHjBMASDvrCYqiXY4BoUjpGlA4rq8qQpfGd8=; b=zI5MT50uCpxSA7aW/C0rFlIDG4HBNe8BuV476iSoyDWxwVR0SSccQ6FJlxwmqrwdiA HZxXFa1a3XRj4SIM/IZ0SymEAEtj0RyJnlQTpmMBG1PwIpG+NQy0nd0j+pszAugYtDJs E3adN0T2CPWljrsD+k66V8Qa7uawKgn0/O/ldqEg4UqEKfGM2xbvOpZmaX/oYe+G1Z0V bPMOMQyoEcYDNzVhSlg1tANhG1EWpB9ftblFI10xaxj+50PHIYxdqCJi+79ErpMvSmsA CeqEuUjc5YJiT370g736avBvzI022aO5kOakZxEP9PncoFEm1RiKd6m1MOWPHGkZOpIr j3FQ== Received: by 10.68.221.166 with SMTP id qf6mr11113292pbc.54.1349253446827; Wed, 03 Oct 2012 01:37:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Wed, 3 Oct 2012 01:37:06 -0700 (PDT) In-Reply-To: <28923335-41A1-4B80-BE5B-F4D53BDD6714@thomasclausen.org> References: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> <28923335-41A1-4B80-BE5B-F4D53BDD6714@thomasclausen.org> From: Henning Rogge Date: Wed, 3 Oct 2012 10:37:06 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 08:37:27 -0000 Thank you, that explains it nicely. :) Henning On Wed, Oct 3, 2012 at 10:22 AM, Thomas Heide Clausen wrote: > Henning, > > Yes, there was a very good reason: to render consistent with RFC5497 (TimeTLV), which also uses the exponent-mantissa encoding. > > Thomas > > Sent from my iPad > > On 3 oct. 2012, at 09:18, Henning Rogge wrote: > >> In Section 6.2 the names of the variables a and b have been switched. >> Was there a specific reason for this or do I managed to miss some real >> change? >> >> Henning Rogge >> >> On Tue, Oct 2, 2012 at 6:47 PM, wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. >>> >>> Title : The Optimized Link State Routing Protocol version 2 >>> Author(s) : Thomas Heide Clausen >>> Christopher Dearlove >>> Philippe Jacquet >>> Ulrich Herberg >>> Filename : draft-ietf-manet-olsrv2-16.txt >>> Pages : 108 >>> Date : 2012-10-02 >>> >>> Abstract: >>> This specification describes version 2 of the Optimized Link State >>> Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-16 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-16 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From thomas@thomasclausen.org Wed Oct 3 01:53:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F203921F86A0 for ; Wed, 3 Oct 2012 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-WkXHZcqU4H for ; Wed, 3 Oct 2012 01:53:08 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8424821F869F for ; Wed, 3 Oct 2012 01:53:08 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 670AFA6A98 for ; Wed, 3 Oct 2012 01:53:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B716F1C075E; Wed, 3 Oct 2012 01:53:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 639401C032D; Wed, 3 Oct 2012 01:53:05 -0700 (PDT) References: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> <28923335-41A1-4B80-BE5B-F4D53BDD6714@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8BBE7F9A-128D-4713-B8DB-C9DA4D774AC5@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Wed, 3 Oct 2012 10:53:06 +0200 To: Henning Rogge Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 08:53:09 -0000 You're welcome - yeah, we thought that consistency in notation was a good ar= gument :D Sent from my iPad On 3 oct. 2012, at 10:37, Henning Rogge wrote: > Thank you, that explains it nicely. :) >=20 > Henning >=20 > On Wed, Oct 3, 2012 at 10:22 AM, Thomas Heide Clausen > wrote: >> Henning, >>=20 >> Yes, there was a very good reason: to render consistent with RFC5497 (Tim= eTLV), which also uses the exponent-mantissa encoding. >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >> On 3 oct. 2012, at 09:18, Henning Rogge wrote: >>=20 >>> In Section 6.2 the names of the variables a and b have been switched. >>> Was there a specific reason for this or do I managed to miss some real >>> change? >>>=20 >>> Henning Rogge >>>=20 >>> On Tue, Oct 2, 2012 at 6:47 PM, wrote: >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF. >>>>=20 >>>> Title : The Optimized Link State Routing Protocol versi= on 2 >>>> Author(s) : Thomas Heide Clausen >>>> Christopher Dearlove >>>> Philippe Jacquet >>>> Ulrich Herberg >>>> Filename : draft-ietf-manet-olsrv2-16.txt >>>> Pages : 108 >>>> Date : 2012-10-02 >>>>=20 >>>> Abstract: >>>> This specification describes version 2 of the Optimized Link State >>>> Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-16 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-16 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From Chris.Dearlove@baesystems.com Wed Oct 3 01:58:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A43F21F869F for ; Wed, 3 Oct 2012 01:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOEWOdZEre3E for ; Wed, 3 Oct 2012 01:58:18 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 068E621F86A0 for ; Wed, 3 Oct 2012 01:58:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,527,1344207600"; d="scan'208";a="275443123" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 03 Oct 2012 09:58:16 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q938wG6L017452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 09:58:16 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Wed, 3 Oct 2012 09:58:15 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen , Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt Thread-Index: AQHNoL3AU70QNlh+UE6u9AR9QC8JQ5enHDgAgAASDwCAABo0sA== Date: Wed, 3 Oct 2012 08:58:14 +0000 Message-ID: References: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> <28923335-41A1-4B80-BE5B-F4D53BDD6714@thomasclausen.org> In-Reply-To: <28923335-41A1-4B80-BE5B-F4D53BDD6714@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 08:58:19 -0000 Just to be picky, RFC 5497 uses a similar but slightly different encoding. = But it still seemed sensible to keep as close to it as we could. (This one = is a thanks to I think Thomas who caught that I'd switched them.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= homas Heide Clausen Sent: 03 October 2012 09:23 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Henning, Yes, there was a very good reason: to render consistent with RFC5497 (TimeT= LV), which also uses the exponent-mantissa encoding. Thomas Sent from my iPad On 3 oct. 2012, at 09:18, Henning Rogge wrote: > In Section 6.2 the names of the variables a and b have been switched. > Was there a specific reason for this or do I managed to miss some real > change? >=20 > Henning Rogge >=20 > On Tue, Oct 2, 2012 at 6:47 PM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group of= the IETF. >>=20 >> Title : The Optimized Link State Routing Protocol versi= on 2 >> Author(s) : Thomas Heide Clausen >> Christopher Dearlove >> Philippe Jacquet >> Ulrich Herberg >> Filename : draft-ietf-manet-olsrv2-16.txt >> Pages : 108 >> Date : 2012-10-02 >>=20 >> Abstract: >> This specification describes version 2 of the Optimized Link State >> Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-16 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-16 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Wed Oct 3 02:00:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3562821F86B2 for ; Wed, 3 Oct 2012 02:00:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvR5m5FLemxF for ; Wed, 3 Oct 2012 02:00:13 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50EF421F846F for ; Wed, 3 Oct 2012 02:00:13 -0700 (PDT) Received: by padfb11 with SMTP id fb11so6236423pad.31 for ; Wed, 03 Oct 2012 02:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rIdhTdJ5WNrResryIa5XzgS0QO2GGHUtcyf/6OtIM+A=; b=aXRpeBsXjWYNcpVG2pnnTzB/ZvJN6gJ3NAR6/qDzFG/AOJY6jR2AU7eoOjRlsmjQav y8r7Eaeo31RxqMkPIunb5ZihBnvYJ2GCDqqVu8gA5SClAsmgi6TZYaMZQ1S4brq38LUE upHq4tlZdwNyUk5AYAfZAmm6YPiiUzCo0yr5Dy+qo1L7DqpTjuY1+E8eYuKpcXa2fENj R5Hg4SS1au+3oa+Qd7+kgUdY8OOlrOxJEV1c6BitviTVBDG9+ga3Akn081Gh6Oo0fQhF wmW1N/2zhxDxHMJxPPWYyGHXH8SJn8fBEB+jIyUs+wVT4S1AE4XvC0DJHGHhk73M/vxP 9Kcg== Received: by 10.68.242.9 with SMTP id wm9mr11201932pbc.62.1349254812781; Wed, 03 Oct 2012 02:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Wed, 3 Oct 2012 01:59:52 -0700 (PDT) In-Reply-To: References: <20121002164739.16413.49883.idtracker@ietfa.amsl.com> <28923335-41A1-4B80-BE5B-F4D53BDD6714@thomasclausen.org> From: Henning Rogge Date: Wed, 3 Oct 2012 10:59:52 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 09:00:14 -0000 Yeah... the sourcecode for both is similar but not equal (especially because of the 1/1024 factor in timetlv). Henning Rogge On Wed, Oct 3, 2012 at 10:58 AM, Dearlove, Christopher (UK) wrote: > Just to be picky, RFC 5497 uses a similar but slightly different encoding. But it still seemed sensible to keep as close to it as we could. (This one is a thanks to I think Thomas who caught that I'd switched them.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide Clausen > Sent: 03 October 2012 09:23 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-16.txt > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Henning, > > Yes, there was a very good reason: to render consistent with RFC5497 (TimeTLV), which also uses the exponent-mantissa encoding. > > Thomas > > Sent from my iPad > > On 3 oct. 2012, at 09:18, Henning Rogge wrote: > >> In Section 6.2 the names of the variables a and b have been switched. >> Was there a specific reason for this or do I managed to miss some real >> change? >> >> Henning Rogge >> >> On Tue, Oct 2, 2012 at 6:47 PM, wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. >>> >>> Title : The Optimized Link State Routing Protocol version 2 >>> Author(s) : Thomas Heide Clausen >>> Christopher Dearlove >>> Philippe Jacquet >>> Ulrich Herberg >>> Filename : draft-ietf-manet-olsrv2-16.txt >>> Pages : 108 >>> Date : 2012-10-02 >>> >>> Abstract: >>> This specification describes version 2 of the Optimized Link State >>> Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-16 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-16 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From prvs=062363d1be=npowell@harris.com Wed Oct 3 05:33:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88221F84F1 for ; Wed, 3 Oct 2012 05:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO-V6pA1pkcb for ; Wed, 3 Oct 2012 05:33:51 -0700 (PDT) Received: from mlbefw1.harris.com (mlbefw1.ngenready.com [192.52.233.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9854721F84F0 for ; Wed, 3 Oct 2012 05:33:51 -0700 (PDT) From: "Powell lll, Nelson" To: Teco Boot , " List" Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfxI3NnYC7q8k+nkZtOb2VpkZenf/vA Date: Wed, 3 Oct 2012 12:33:37 +0000 Message-ID: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:33:52 -0000 Teco, From the way I read the changes in the draft 3, DLEP has been modified t= o support a broader set of L2 devices and not Cisco specific. If it was Ci= sco centric, we may still be working with draft 01. I think Stan and compa= ny have done due diligence to reach out to vendors of all varieties and aca= demia to get opinions and requirements in an effort to satisfy a multitude = of use cases. =20 That being said, I must disagree with the Modem being the only device pr= oviding information. There are a number of scenarios in which an exchange = between the router and modem are beneficial if not crucial to optimized per= formance. If you are experimenting with WiFi or WiMAX, you may not see a b= enefit; therefore, I would concede to the addition of a configuration messa= ge or TLV in the discovery process that the modem would send to the router = informing the router of the ability to perform bi-directional information e= xchange. But we cannot have the information exchange removed all together. I agree with the need for a defined protocol (UDP vs. TCP) as well as a = need to define a separate FSM for both the Router and the Modem. That will = ease integration issues for everyone. Keep in mind, the specification of U= DP or TCP should remain a "suggestion" for IP based connections, as modems = may be connected to routers using non-IP based interfaces. Regarding the Ethernet MAC address comment, there are many L2 devices on= the market that do not utilize the IEEE waveforms or phy, and cannot provi= de IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP ov= er the wireless interface due to bandwidth limitations. Pushing additional = protocols over bandwidth constrained waveforms can cripple user data throug= hput or significantly reduce the user's perceived performance of their devi= ces. DLEP was designed to allow for optimized performance of wireless devi= ces "in general," not just IEEE wireless devices. Thus, we requested additi= onal features to eliminate the redundant and chatty overhead of the protoco= ls you mentioned. Furthermore, one should also acknowledge that a modem de= vice may not be connected to the router via an Ethernet interface, but coul= d be a PCI card, USB connection, etc, and therefore not contain an Ethernet= MAC address. =20 I agree that the heartbeat is essential. I guess the definition of the = two FSM's would help rectify their behavior. The FSM could allow for a simp= le heartbeat message whenever a period of time since the last DLEP message = was seen had expired. If a DLEP message (in general) is received, then the = timer is reset and there is no need for a heartbeat. This would keep the c= oncept of a heartbeat but reduce the occurrences of heartbeat messages on t= he link. Nelson -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: Monday, October 01, 2012 5:01 PM To: List Subject: [manet] Some comments on manet-dlep-03 I quickly browsed thru the manet-dlep-03 draft and diff with the -02 versio= n. I wonder why the draft is changed as it is. Does it reflect any workgrou= p decisions? Or is it a best effort undertaken by some authors? Or maybe, i= s this protocol in hands of Cisco instead of our workgroup? I can see improvement on readability (router and modem, not client and serv= er). Thanks for this. I still don't like the "participants" term. I prefer = the clear router or modem terms, where the modem is the only participant th= at provides data. I see a change from RFC 5444 messages to something else, with UDP as a sugg= estion. This is underspecified and does not lead to a standard protocol. Th= ere is a need to specify the basics. The main purpose of the protocol is to get link metrics for links between r= outer interfaces, from modem to router.=20 In general, (ethernet) interfaces have MAC addresses. I can't see why diffe= rent IDs are needed, where the MAC addresses would be fine. There are a couple of functions in DLEP that are redundant, because other p= rotocols or mechanisms can provide it. Credits is one example (packet scheduling is to be performed on bottleneck,= thus the modem). MAC - IP address resolution is another (standard ARP/ND i= s to be used, probably with proxy functions to get quick resolution). And t= here is SNMP. The suggested metric types looks rather useful, but some experience showed = me that it is difficult for a router to interpret these data. Also, with a = large variety of L2 technology, it seems unwise and hard to me to support a= ll of that in a general purpose router. Especially when the outcome is as s= imple as a dimensionless additive metric, such as in OLSR. I would specify = only one mandatory metric type and all the rest as optional. This mandatory= would be the link metric as we have defined in OLSRv2. I don't get why the Heartbeat Interval/Threshold is optional. It looks esse= ntial to me. And interval could be fractions of a second. The protocol needs synchronized state machines, maybe with an n to m relati= on between routers and modems. Getting this right is not that simple. I wou= ld use TCP for unicast connections, or use a simple timer-based database up= date exchange, just like OLSR. Section 7 misses some ACK signal TLVs. The Neighbor Update ACK is only ment= ioned in 9.18 credit request. I can't find details on the Ack mechanism, e.= g. message sequence numbers. On Link Characteristics Request, fulfilling the request could take some tim= e. How the modem should provide feedback on such is unclear. I'm looking forward to a fruitful discussions how we can work this out. Teco =20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Oct 3 07:57:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777E621F8672 for ; Wed, 3 Oct 2012 07:57:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nwo4kE2hkcB for ; Wed, 3 Oct 2012 07:57:17 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2AE821F866C for ; Wed, 3 Oct 2012 07:57:17 -0700 (PDT) Received: by padfb11 with SMTP id fb11so6564607pad.31 for ; Wed, 03 Oct 2012 07:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=fJS9dLkLX05jNpeM/CugIpRKnGtdfIfHty31a4JWtWY=; b=05e4JOSIXReN2dzdY7CfAI7W5A/ZsmgDGkpLoyBfGDbuDmD5MXSea0OgAgvngWwzqP eHe14ACkYUuyQpI8ZxB7IR30qry34Uj5IC1chJ9YfyxIHwv2pGr8L0pLYkpfd1QmAuO6 eyS5hoXU6xLRZeS7v1Unae2H65iX3QvplzrFbzoDGCB1y/bWtSwudLlTmPH0RdzJFeg5 ElWon3ey3YxOR7qJtnZBp4sjRoB0eFPMmgKZtv0NZsVKhFqRhpXHRbWO/iRprJLMnxP1 8oJK+eevBvKy6tH8RF9JoXuVGjqevNCiy22Nro9v9dgMGIFF1odZ0k0FOvzucEsqiOc0 Zaog== Received: by 10.68.138.198 with SMTP id qs6mr13603375pbb.151.1349276237615; Wed, 03 Oct 2012 07:57:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Wed, 3 Oct 2012 07:56:57 -0700 (PDT) In-Reply-To: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> From: Henning Rogge Date: Wed, 3 Oct 2012 16:56:57 +0200 Message-ID: To: "Powell lll, Nelson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:57:18 -0000 On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson wro= te: > I agree with the need for a defined protocol (UDP vs. TCP) as well as = a need to define a separate FSM for both the Router and the Modem. That wil= l ease integration issues for everyone. Yes, specific FSMs for both the discovery process, the normal message transfer and the ACK mechanisms are necessary if we want to have a chance to get interoperable implementations. > Regarding the Ethernet MAC address comment, there are many L2 devices = on the market that do not utilize the IEEE waveforms or phy, and cannot pro= vide IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP = over the wireless interface due to bandwidth limitations. Pushing additiona= l protocols over bandwidth constrained waveforms can cripple user data thro= ughput or significantly reduce the user's perceived performance of their de= vices. DLEP was designed to allow for optimized performance of wireless de= vices "in general," not just IEEE wireless devices. Thus, we requested addi= tional features to eliminate the redundant and chatty overhead of the proto= cols you mentioned. Furthermore, one should also acknowledge that a modem = device may not be connected to the router via an Ethernet interface, but co= uld be a PCI card, USB connection, etc, and therefore not contain an Ethern= et MAC address. Thats why I suggested increasing the size of the "Radio/Modem ID" to six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide an unique idea, but it doesn't make it mandatory to use a MAC. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Wed Oct 3 07:35:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D5721F867B for ; Wed, 3 Oct 2012 07:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EMa01wS2sG2 for ; Wed, 3 Oct 2012 07:35:40 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DD3E921F8652 for ; Wed, 3 Oct 2012 07:35:39 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5182DA30AC for ; Wed, 3 Oct 2012 07:35:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1F5371BD9213 for ; Wed, 3 Oct 2012 07:35:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.89.143.150] (37-8-175-143.coucou-networks.fr [37.8.175.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2450B1BD9221 for ; Wed, 3 Oct 2012 07:35:30 -0700 (PDT) Content-Type: multipart/mixed; boundary=Apple-Mail-9B2CF6D8-3635-4138-900A-793DD316BB11 Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Message-Id: <604F1AC3-4677-4A66-B7B3-C697BBB4A629@thomasclausen.org> Date: Wed, 3 Oct 2012 16:35:23 +0200 To: manet Mime-Version: 1.0 (1.0) X-Mailer: iPad Mail (10A403) X-Mailman-Approved-At: Wed, 03 Oct 2012 08:20:59 -0700 Subject: [manet] DLEP-03 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:35:40 -0000 --Apple-Mail-9B2CF6D8-3635-4138-900A-793DD316BB11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable All, I promised Stan a review of DLEP-03 last week, and finally got around to get= ting it out. Apologies for this delay, hope that it still is timely. I shall add that I provided a review of a previous version of DLEP privately= to Stan, and I want to commend him and his co-authors on having reflected m= any of my concerns when they updated to -03. Note that I have reviewed only the non-appendix parts of the document; some c= omments may apply also to appendices and there may be more comments to add t= o the appendices than that which I say in the below. I include the annotated PDF, as well as the annotation summary as text below= . Respectfully yours, Thomas Annotation summary: --- Page 1 --- Highlight (yellow), 3 oct. 2012 13:32: Intended status: Standards Track Note (yellow), 3 oct. 2012 13:32: Now I am nitpicking: I believe that the proper term here is "Proposed Standa= rd" Strikeout (red), 3 oct. 2012 16:29, TClausen: mobile or Strikeout (red), 3 oct. 2012 16:29, TClausen: other Highlight (yellow), 3 oct. 2012 16:29, TClausen: necessary Note (yellow), 3 oct. 2012 16:29, TClausen: I am not sure I would say "necessary" - maybe "recommended" ? --- Page 4 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: cable/DSL modems Note (yellow), 3 oct. 2012 16:29, TClausen: The abstract spoke only about wireless. Should abstract be extended, or shou= ld the cable/DSL examples from into be removed? Highlight (yellow), 3 oct. 2012 16:29, TClausen: (in the case of cable/DSL modems) Note (yellow), 3 oct. 2012 16:29, TClausen: The abstract spoke only about wireless. Should abstract be extended, or shou= ld the cable/DSL examples from into be removed? Highlight (yellow), 3 oct. 2012 16:29, TClausen: individual Note (yellow), 3 oct. 2012 16:29, TClausen: As this is in introduction, perhaps add something about why this is (differe= nt distances, physical obstacles etc)? I know that the subsequent example il= lustrates this, but the previous sentences provide "abstract reasons"? Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: a=20 Note (yellow), 3 oct. 2012 16:29, TClausen: suggest: "exclusively detected by way of a" Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: e.g., --- Page 5 --- Note (yellow), 3 oct. 2012 16:29, TClausen: suggest adding: "is a signaling protocol that" Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP protocol Note (yellow), 3 oct. 2012 16:29, TClausen: As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundan= t: expanded it becomes "Data Link Exchange Protocol Protocol". Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...." Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP protoco Note (yellow), 3 oct. 2012 16:29, TClausen: As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundan= t: expanded it becomes "Data Link Exchange Protocol Protocol". Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...." Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Note (yellow), 3 oct. 2012 16:29, TClausen: You should make it such that figures do not split across two pages. In xml, a= dd a before this figure (but I think you use nr= off - I forget how one does there?) Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP session Note (yellow), 3 oct. 2012 16:29, TClausen: At this point, the notion of "session" isn't introduced yet, so this is conf= using. --- Page 6 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: changed Note (yellow), 3 oct. 2012 16:29, TClausen: Do you mean "changed characteristics", or do you mean "the set of interfaces= , forming the link, has changed members"? Highlight (yellow), 3 oct. 2012 16:29, TClausen: MUST Note (yellow), 3 oct. 2012 16:29, TClausen: You have not yet defined RFC2119 requirements language. In general, I think t= hat introductions are non-normative, and so use of 2119-language therein is n= ot recommended. Suggest "are expected to" for MUST and "can" for MAY in the i= ntroduction? And, of course, make sure that these normative requirements are called out i= n the normative parts of the specification. Highlight (yellow), 3 oct. 2012 16:29, TClausen: MAY Note (yellow), 3 oct. 2012 16:29, TClausen: You have not yet defined RFC2119 requirements language. In general, I think t= hat introductions are non-normative, and so use of 2119-language therein is n= ot recommended. Suggest "are expected to" for MUST and "can" for MAY in the i= ntroduction? And, of course, make sure that these normative requirements are called out i= n the normative parts of the specification. --- Page 7 --- Note (yellow), 3 oct. 2012 16:29, TClausen: There is an RFC2119 errata, that stipulates that also "NOT RECOMMENDED" be i= ncluded in this paragraph. See http://www.rfc-editor.org/errata_search.php?rfc=3D2119 Highlight (yellow), 3 oct. 2012 16:29, TClausen: MUST Note (yellow), 3 oct. 2012 16:29, TClausen: You have not yet defined RFC2119 requirements language. In general, I think t= hat introductions are non-normative, and so use of 2119-language therein is n= ot recommended. Suggest "are expected to" for MUST and "can" for MAY in the i= ntroduction? And, of course, make sure that these normative requirements are called out i= n the normative parts of the specification. Highlight (yellow), 3 oct. 2012 16:29, TClausen: MUST Note (yellow), 3 oct. 2012 16:29, TClausen: You have not yet defined RFC2119 requirements language. In general, I think t= hat introductions are non-normative, and so use of 2119-language therein is n= ot recommended. Suggest "are expected to" for MUST and "can" for MAY in the i= ntroduction? And, of course, make sure that these normative requirements are called out i= n the normative parts of the specification. Highlight (yellow), 3 oct. 2012 16:29, TClausen: Requirements Note (yellow), 3 oct. 2012 16:29, TClausen: I would recommend that section 1.1 be promoted to a top-level section 2, and= titled "Terminology". I would, then, also recommend actually defining the terminology used (sessio= n, peer, ....) in that section. DLEP introduces and uses a whole slew of terminology, and I know that it wou= ld have helped me greatly had there been a single central place for me to go= look that up as I read the document. As it is, I had to search through to f= ind (at times, partial) definitions of a given term. I believe that completely defining in a central place, and then consistently= using through the document, the terminology is a great help for the reader,= and is a good way also to ensure that one is consistent and correct when wr= iting the spec. Highlight (yellow), 3 oct. 2012 16:29, TClausen: When Note (yellow), 3 oct. 2012 16:29, TClausen: Suggest: "To break this race condition when it occurs, ...." So as to render crystal clear that DLEP does actually recover. Should it not be stated how a router discovers that a race condition is happ= ening? Even moreso, is this really an "Assumption" (as the section heading states)?= I would think that it is an integral part of the DLEP design? Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP utilizes a session-oriented paradigm. Note (yellow), 3 oct. 2012 16:29, TClausen: This is not really an assumption either. I think that this section should be= better titled "Design Principles" or something, as there's nothing much (tw= o exceptions, see comment later) in the section that actually are assumption= s as such. Highlight (yellow), 3 oct. 2012 16:29, TClausen: the discovery process Note (yellow), 3 oct. 2012 16:29, TClausen: which discovery process? "The discovery process, specified in section XX" ? Or, an external process in another spec? Or, a non-specified process? --- Page 8 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP assumes that participating modems, and their physical links, act as a t= ransparent bridge. Specifically, the assumption is that the destination MAC= address for data traffic in any frame emitted by the router should be the M= AC address of a device in the remote node. DLEP also assumes that MAC addre= sses are unique within the context of the router-modem session Note (yellow), 3 oct. 2012 16:29, TClausen: This paragraph is the one of the two which contain real assumption, and so o= ne of the paragraphs that, from this section, would fit the section header "= Assumptions" Highlight (yellow), 3 oct. 2012 16:29, TClausen: This document refers to a remote node as a "Neighbor" Note (yellow), 3 oct. 2012 16:29, TClausen: And this is a terminology definition. Again, I strongly suggest making a pro= per "Terminology" section, centralizing such. Also on this point. In MANET, we have a - by now - well established use of t= he word "neighbor", even a protocol that has the word "Neighbor" in its titl= e specified as RFC6130. I wonder if it would not behove us to come up with a= different term here, so as to avoid confusion? For example, I can easily im= agine a system using both DLEP and NHDP, in which case "neighbor" may refer t= o distinctly different concepts. Highlight (yellow), 3 oct. 2012 16:29, TClausen: an information base Note (yellow), 3 oct. 2012 16:29, TClausen: I like defining a protocol as something operating on information bases! That said, I also think that defining the information bases in a separate se= ction is a great help: it allows the implementer to consider what data struc= tures and data storage is required for making the protocol work - and, allow= s specifying the protocol operations (message processing) as operations on t= hese information bases. I would suggest that a section be added to the specification, entitled "Info= rmation Bases", in which the different information sets, and their content, b= e specified. This should come before the actual discussion and description o= f protocol operations. I would guess that it also would render describing (and understanding the de= scription of) the protocol message processing an awful lot easier. Highlight (yellow), 3 oct. 2012 16:29, TClausen: effecting Note (yellow), 3 oct. 2012 16:29, TClausen: affecting? Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP assumes Note (yellow), 3 oct. 2012 16:29, TClausen: This would be the second of the only two sections containing actual assumpti= ons Highlight (yellow), 3 oct. 2012 16:29, TClausen: rolls over at 65535 to 0 Note (yellow), 3 oct. 2012 16:29, TClausen: Need to specify how to properly identify that, e.g., seq# 5 then may be cons= idered bigger than seq# 65530 -- i.e., roll-over behavior -- if any sort of o= rdering is required. If not, then I would suggest that this be prefixed by "DLEP uses sequence nu= mbers only for correlating a response to a request, and not for freshness in= formation, i.e., two sequence numbers for the same destination are never com= pared for anything other than equality". Highlight (yellow), 3 oct. 2012 16:29, TClausen: It is assumed that DLEP running over other transport mechanisms would be do= cumented separately. Note (yellow), 3 oct. 2012 16:29, TClausen: This needs to be more explicit: "DLEP running over other transport mechanisms MUST be documented separately,= and such specifications MUST register or specify appropriate code points to= use" Note (yellow), 3 oct. 2012 16:29, TClausen: Two comments here. 1) Suggest terming it "Credit Windows" or something, so as to avoid co= nfusions of the sort "I would like to credit XXX with having come up with th= e efficient algorithm used to make whipped cream". 2) This (and following, and part of the previous) sections really read= as what we typically see described in a "Protocol Overview and Functioning"= section. I would therefore suggest that a section 2 be "Terminology", section 3 be "A= ssumptions" (containing the two paragraphs pointed out in the above) and a n= ew section 4 added titled "Protocol Overview and Functioning". In section 4, the remainder of Section 2, plus this section "Credits", and t= he following "Metrics" and "Normal Session Flow" be included as subsections t= o this proposed section 4. I would even suggest that "Mandatory Signals and Data Items" also be include= d in this proposed section 4, as "Signaling Overview" and "Information Base O= verview". The latter would even, in part, accommodate my previous comment as= to making "Information Bases" appear more clearly. Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP Note (yellow), 3 oct. 2012 16:29, TClausen: On to the credit windowing. When I spoke with Stan Ratliff in Vancouver, I d= idn't fully understand what this was really useful for, and almost considere= d it as "useless". After talking with Stan, wherein he patiently explained i= ts use in a few eloquent phrases, I got convinced that it probably was not j= ust a good idea, it was actually required in certain important cases ;) I would recommend adding those eloquent explanatory phrases to the beginning= of this section, as motivation for why this functionality is included in DL= EP. --- Page 9 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Highlight (yellow), 3 oct. 2012 16:29, TClausen: .g Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Note (yellow), 3 oct. 2012 16:29, TClausen: I think that my comment here refers to Figure 1. Figure 1 explains that DLEP runs between a router and its modem, i.e., "loca= lly" (wrt. the rest of the network).=20 The credit windowing, as described in this paragraph, seems to relate to the= "remote node". This is a little in conflict with 2 paragraphs up from here,= at least it is confusing. My understanding (ignoring what Stan said in Vancouver, but just reading and= thinking hard about this section) is that: 1) If a router, R1 communicates to its local modem (but not beyond that), no= credit windows is used 2) If a router, R1, communicates to a remote router, R2, by way of its local= modem (m1) and remote modem (m2), then credits can be used. In that case, R= 1 will know of the credits corresponding to m2 Remembering back to what Stan said in Vancouver, this is not entirely correc= t, so I think that this section needs both some clarification and perhaps an= example with a figure and a reference to figure 1? Highlight (yellow), 3 oct. 2012 16:29, TClausen: in the introduction section of this document Note (yellow), 3 oct. 2012 16:29, TClausen: Use a section number reference here. Highlight (yellow), 3 oct. 2012 16:29, TClausen: within the network) Note (yellow), 3 oct. 2012 16:29, TClausen: Technically, it is not within the _entire_ network, is it? It only concerns t= hose, with which a node has a direct link? Underline (red), 3 oct. 2012 16:29, TClausen: Peer Highlight (yellow), 3 oct. 2012 16:29, TClausen: Peer Note (yellow), 3 oct. 2012 16:29, TClausen: This is undefined so far - we have a (somewhat) definition of "Neighbor", bu= t not "peer". Really need a good terminology section. Highlight (yellow), 3 oct. 2012 16:29, TClausen: specific characteristics Note (yellow), 3 oct. 2012 16:29, TClausen: I understand that you do not want to provide any firm data, but are there an= y guidelines or examples that can be provided? --- Page 10 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP protocol Note (yellow), 3 oct. 2012 16:29, TClausen: As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundan= t: expanded it becomes "Data Link Exchange Protocol Protocol". Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...." Highlight (yellow), 3 oct. 2012 16:29, TClausen: experimental implementation Note (yellow), 3 oct. 2012 16:29, TClausen: That is fine. But.... If more link types become prevalent, should there also not be a space for fu= ture standards-action code points? I can only think of a silly example right now, but consider this: In the near future, smoke-signal based links will become prevalent, in which= case we would want DLEP to understand meteorological data, as well as data c= oncerning the stock of firewood of a remote modem, to accurately describe th= e characteristics of a link. Thus, the SSWG (SmokeSignal WG) specifies a DLE= P extension for carrying and processing such data. What happens in that case, compatibility wise? Can an existing implementatio= n of DLEP in a router thus handle forward compatibility, when faced with a S= mokeSignal Modem?=20 Highlight (yellow), 3 oct. 2012 16:29, TClausen: maximum flexibility for extending the protocol as conditions warrant Note (yellow), 3 oct. 2012 16:29, TClausen: I would make a counter-argument here: having experimental spaces increases the probability of non-interoperating s= ystems, especially if future evolution of the protocol is envisioned to happ= en by way of the experimental space. I would feel a LOT more comfortable with a smaller experimental space, and t= hen guidelines as to how to proceed to standardizing code-points for future= evolutions. I should note that I didn't use to think like that, but our friendly AD (ADr= ian) managed to convince me. I would therefore suggest that, at the very least, a generous space of code p= oints be allocated to "Standards Action", and that this paragraph states tha= t this is to be undertaken as or when the need arrises. Highlight (yellow), 3 oct. 2012 16:29, TClausen: Normal Session Flow Note (yellow), 3 oct. 2012 16:29, TClausen: I won't comment on this section in great details, but I will make one overal= l comment: when I read it, I found myself doodeling a state machine on a nap= kin, to keep track of what the protocol was doing, and when. I would suggest that such a state-machine could be interesting/illustrative t= o include. I didn't draw it in ASCII-text, so I can't provide a drop-in draw= ing, but if the authors are interested, then I could forward my napkin to th= em on occasion? Note (yellow), 3 oct. 2012 16:29, TClausen: I would like to see some sort of "Signaling overview" before the description= of a state machine, of the sort: "A DLEP device can send, receive and process the following signals: NEED_MORE_APPLEPIE:=20 sent when a DLEP device is out of apple pie NEED_MORE_SOUR_CREAM: sent when a DLEP device has apple pie, but needs sour cream to consume with it " Another thing is, that the document - and this section in particular - talks= about signals and messages in a bit of an incoherent fashion. I would recom= mend using "Signal" as the logical interaction between the devices, "Message= " when referring to the actual bits and bit-format sent between devices. Finally, a session exists between a router and its local modem, right? The s= tate related to a session describes the "neighbors" (or is it peers?) reacha= ble by the router via that modem? If so, then this would do well by being ex= plained, perhaps in a Terminology section as the definition of "DLEP Session= "? --- Page 11 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: partners Note (yellow), 3 oct. 2012 16:29, TClausen: Is a partner different from a peer? or from a neighbor? =3D> Terminology sec= tion. --- Page 13 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP protocol Note (yellow), 3 oct. 2012 16:29, TClausen: As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundan= t: expanded it becomes "Data Link Exchange Protocol Protocol". Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...." Highlight (yellow), 3 oct. 2012 16:29, TClausen: SHOULD parse, and silently drop Note (yellow), 3 oct. 2012 16:29, TClausen: Disagree with this. The requirement would be for an implementation not supporting an optional si= gnal to identify and drop without processing the signal. In terms of a message (the encoding of a signal into a byte format sent acro= ss the wire), it would be required to parse only the header, not the full me= ssage (presumably, the recipient not supporting an optional message would ac= tually not be able to parse the message). Actually, this links in with the whole "unknown/experimental" discussion: it= should be such that an implementation not understanding a signal can identi= fy and skip that signal (be it due to not supporting an optional signal or n= ot understanding an experimental signal) Highlight (yellow), 3 oct. 2012 16:29, TClausen: Packet Note (yellow), 3 oct. 2012 16:29, TClausen: Now, I am confused. Does DLEP use the term messages or packets? In RFC5444 we enshrined the notion of a packet as an encapsulation of a set o= f messages. I am not saying that we should use this format, or terminology, b= ut it seems to me that we should be consistent inside a specification. I see that section 9 and 10 try to make a distinction, but it still is very u= nclear and confusing As I understand it, DLEP defines, in this section, a PACKET, with the type o= f the PACKET defining the interpretation of the content (the TLVs contained)= . But DLEP does not define a separate entity "message", rather a "message" i= s used for describing a "packet" in some circumstances. I think that, readin= g 9 and 10, "A message is a packet containing some pre-defined set of TLVs"= , but that is very nebulous. Also, if I understand it correctly, does lend i= tself to a less clear parsing logic also (so either I do not understand it c= orrectly, and it should be explained so that I do ;) -- or, I do understand i= t correctly, and we should come up with a clearer way ). It seems confusing to have/use both terms, pick one. My personal preference w= ould, probably, be message, but I have no strong religion on the choice of w= ord, as long as *one* us used ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: INSERT REFERENCE HERE]. Note (yellow), 3 oct. 2012 16:29, TClausen: Yes, please do ;) Note (yellow), 3 oct. 2012 16:29, TClausen: OK, generally..... 1) It needs to be said how the fields are encoded. For most, the term "xxx i= s an n-bit unsigned integer field, which ..." seems to be what is needed (v= ersions, lengths, ...) 2) Some enetities (RouterID?) do not have length nor references as to how th= ey are made. Are they IP addresses? MAC addresses? Derived so as to be uniqu= e, but otherwise without semantics? 3) I do not know what a "n bit unsigned number" is, but I do know what a "n b= it unsigned integer" is. I also do not know what a "n bit unsigned value" i= s, and even less how to encode "add/drop" and other textual things into an o= ctet, unless told so. Change "number" and "value" and the like to "integer", or I will produce an i= mplementation trying to read a version number as a float ;) And for "add/dro= p", tell me how to represent it, or I will come up with creative bit-pattern= s.... Note (yellow), 3 oct. 2012 16:29, TClausen: I sorta think that it would be good to structure this section somewhat. For e= xample: One section for "Mandatory TLVs" One section for "Optional TLVs" Or a structure with a 2nd level section for all TLVs related to a specific "= state" in the DLEP state machine? Or something? Also, I am somewhat iffy on this section mixing the syntactical structure of= the messages/TLVs, and their processing. I would find it a lot cleaner to s= eparate the two - a lot easier to read/implement. The separation is - kinda -= started (section 11 and forward defines how/when messages are sent), so I w= ould recommend trimming some of that information from this section. Writing t= he same thing in more than one place just means that it is easier for the sp= ecification to contradict itself ;) --- Page 14 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP protocol Note (yellow), 3 oct. 2012 16:29, TClausen: As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundan= t: expanded it becomes "Data Link Exchange Protocol Protocol". Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...." Highlight (yellow), 3 oct. 2012 16:29, TClausen: TBD Identification TBD DLEP Version TBD Pee= r Type TBD IPv4 Address TBD IPv6 Address = TBD Maximum Data Rate (MDR) TBD Current Data Rate (CDR)= TBD Latency TBD Resources TBD Exp= ected Forwarding Time (EFT) TBD Relative Link Quality (RLQ) = TBD Status TBD Heartbeat Interval/Threshold = TBD Neighbor down ACK timer TBD Link Characteristics A= CK timer TBD Credit Window Status TBD Credit Gra= nt TBD Credit Request Note (yellow), 3 oct. 2012 16:29, TClausen: For this, you really should set up (and reference) the IANA registry, with m= nemonics, and then just use that. This table reads like a "mini IANA section= , outside of the IANA section", which is bound to be confusing and a source o= f errors. Highlight (yellow), 3 oct. 2012 16:29, TClausen: An 8-bit length Note (yellow), 3 oct. 2012 16:29, TClausen: An 8-bit unsigned integer field, containing the length.... Note (yellow), 3 oct. 2012 16:29, TClausen: Should probably add that the encoding and internal structure hereof is speci= fied for each of the different TLV types, given in the following. --- Page 15 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: Router ID Note (yellow), 3 oct. 2012 16:29, TClausen: This applies throughout this section: How big is that field, and how is it encoded? RouterID, is that a Well Known Entity? --- Page 16 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: .g. Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: Length Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? --- Page 17 --- Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? --- Page 18 --- Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? --- Page 19 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: TLV Flags=3D0x10 Note (yellow), 3 oct. 2012 16:29, TClausen: Wait, what? 1) This TLV doesn't match the other TLVs: length comes after type. Hence, ne= eds different parser-logic where none is needed. 2) The TLV Flags semantics is not defined anywhere, what does it mean that i= t is set to 0x10 ? Highlight (yellow), 3 oct. 2012 16:29, TClausen: number Note (yellow), 3 oct. 2012 16:29, TClausen: integer Note (yellow), 3 oct. 2012 16:29, TClausen: integer Highlight (yellow), 3 oct. 2012 16:29, TClausen: number --- Page 20 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: number Note (yellow), 3 oct. 2012 16:29, TClausen: integer --- Page 21 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Note (yellow), 3 oct. 2012 16:29, TClausen: 8 bit unsigned integer? Highlight (yellow), 3 oct. 2012 16:29, TClausen: value Note (yellow), 3 oct. 2012 16:29, TClausen: integer --- Page 22 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: number Note (yellow), 3 oct. 2012 16:29, TClausen: encoded how? Highlight (yellow), 3 oct. 2012 16:29, TClausen: Specific Note (yellow), 3 oct. 2012 16:29, TClausen: Set up an IANA registry for this, provide default registrations, and referen= ce that registry here. --- Page 23 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: Interval Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? Underline (red), 3 oct. 2012 16:29, TClausen: Threshold Highlight (yellow), 3 oct. 2012 16:29, TClausen: Threshold Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? --- Page 24 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: Interval Note (yellow), 3 oct. 2012 16:29, TClausen: Encoded how? --- Page 25 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: number Note (yellow), 3 oct. 2012 16:29, TClausen: Integer Highlight (yellow), 3 oct. 2012 16:29, TClausen: number Note (yellow), 3 oct. 2012 16:29, TClausen: integer --- Page 26 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: number Note (yellow), 3 oct. 2012 16:29, TClausen: integer Highlight (yellow), 3 oct. 2012 16:29, TClausen: Reserved Note (yellow), 3 oct. 2012 16:29, TClausen: This field is reserved for future use. For compliance with this version of t= he specification, it MUST be set to 0 on transmission, and SHOULD be ignore= d on receipt. --- Page 27 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: DLEP Protocol Note (yellow), 3 oct. 2012 16:29, TClausen: As DLEP is "Data Link Exchange Protocol", saying "DLEP Protocol" is redundan= t: expanded it becomes "Data Link Exchange Protocol Protocol". Suggest saying "DLEP is a ...." instead of "the DLEP protocol is a ...." Highlight (yellow), 3 oct. 2012 16:29, TClausen: string Note (yellow), 3 oct. 2012 16:29, TClausen: Technically, I would not say "string" (that has a common interpretation as a= String datatype), but rather a "sequence" or better a "set" of TLVs Highlight (yellow), 3 oct. 2012 16:29, TClausen: messages (signals) Note (yellow), 3 oct. 2012 16:29, TClausen: See previous comment re. message-vs-signal --- Page 28 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: association Note (yellow), 3 oct. 2012 16:29, TClausen: This is the first use of "Association" - is that the same as "session"? --- Page 30 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) --- Page 33 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: OPTIONAL, and MAY be present if an implementation supports them Note (yellow), 3 oct. 2012 16:29, TClausen: I know I am a nit-picker, but doesn't OPTIONAL exactly mean that it "MAY be p= resent if an implementation supports..."? It strikes me as just redundant (this is not the only place where I see this= , btw., just the one where I chose to point it out.) --- Page 36 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: e.g. Note (yellow), 3 oct. 2012 16:29, TClausen: The RFC editor uses: "...blah blah, e.g., blah blah" and "...blah blah, i.e., blah blah" Recommend making their life easier (and reducing their processing time) by j= ust doing this from the start ;) Highlight (yellow), 3 oct. 2012 16:29, TClausen: IANA Considerations Note (yellow), 3 oct. 2012 16:29, TClausen: First, let me point to http://tools.ietf.org/html/rfc5226 Second, for the registries set up, there needs to be specifications of what t= he ranges are (how big are the registries), what default allocations are mad= e, and what the allocation policies (see RFC5226) are for these registries, a= nd for specific intervals/parts of these registries. You mention earlier that there are some experimental ranges, and that is goo= d. What are they? Are there ranges requiring standards action? Expert review= ? What are the considerations that the experts must be aware of? Or, is it t= hat the registries are infinitely big, and IANA should just register whateve= r they are asked to register? --- Page 37 --- Highlight (yellow), 3 oct. 2012 16:29, TClausen: 27.2 Expert Review: Evaluation Guidelines =20 No additional guidelines for expert review are anticipated. Note (yellow), 3 oct. 2012 16:29, TClausen: I do not understand this. Additional guidelines -- additional to what? IIRC, there are no "default exp= ert review guidelines" anywhere in the IETF Note (yellow), 3 oct. 2012 16:29, TClausen: I do not understand this. Additional guidelines -- additional to what? IIRC, there are no "default exp= ert review guidelines" anywhere in the IETF. (report generated by GoodReader) --Apple-Mail-9B2CF6D8-3635-4138-900A-793DD316BB11 Content-Type: application/pdf; name="draft-ietf-manet-dlep-03 - flattened.pdf" Content-Disposition: attachment; filename="draft-ietf-manet-dlep-03 - flattened.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nKVWTXPbNhC961fs5BJ7RqIka9w4ucmx7LpjZ9yIMznUPUDAkkRFAjQAita/ 7y5I1ZId100jjS1+AG/37Xu75ANMkilM+Nv/ymow/voBcj+YwBX95YOHwTQugP5HVnCe0qIzvpBm g27fFM6m8MvpR0irwdGtXekSYa6gsBK+YGitW3v4Rv+1yeGNzzKBryKUOsuO078G0ymkN4OjK2eb +q2d//I5T+Acndsevx8cXZuAzmAYXTiRhR8EukrgV+Gc9tbssIxCBT6I0PhPsAzCKOGUh9QJuX4d 6CKBpQiUSVvogIy1eKy1Q8K4FU4WMBvCyWQ6+09ZfdZeWlhufcDKM9YPsnr5IRV+a7p6/TQWW2Be 1z+FNW/yxgeYTWJVTghrNovOeLHyYmtEpSXcaLOGxaMshMkR7pwNVtoS7o8ubhZ398eE0HvrtZCK 7THSGLJRJdgvqsR6NJnRzpOTuHO+8oFUDj2zbwUaIKMGdrnCjZbowWG5BWugsoq0gWABswxlAGmr qjFaiqCt8WA36A5yaskMJXoPJRHxQwgFbsEgeS3oikHJaCCkbJwICGtj2xIVMbUZL+1TIvacIJJh g5a+vxkhqRK+Jrhh9C4OAYNM7o9BG7BOoeNUK7HeIWXWteTrjprUnpNO4JqJxW63DixBO0Cz0c6a Ck3w0NIV5JD+tYx6fTKHDw1tKbdDimoaUVKBTKZzptcVyO3x0iYjYCMj3Zg/3aTS58U/AvB6J4yv rQtQ9/J7UJZEMXanmShL28aa8L4n1vHSCslye2znsNKKZJGckSipZBtKedRDKafp9FDXSM9gSVCh Rbq7F4n149PoDNC7vjVItvHCbZMnoy3jdOnU0x5usbL96pTPn000uuKbVaVpuijmc71IL1nWrCm7 qlpHJabatToUfVGffEel2nSEOd755zv4cBZzjYcf97KixYeRPQhSu+3nvLKy6VzQu263GBYm1+Rk R6sOQqfCr+HSOkrt/oizvj8egu5gBbUAZ8Gnuwg5PxVIF/hiowHETtXOid1tkpN6pfQWFFnO6RUV /zs5ir0y9igdp7cJx0GxB7URpVbcMCAo+KOumiraVD+S1iYU/oA0k+IUVwhNrcjJ1JEO61JIPuK2 WnlbImu52vbM9tIOBLAb0zwYqBrX0QLaiJq0rJ2O3WGh8fgyfR5QfSv1IJXg5qT+s7EZpI6lJYd2 oanKhre94xKyqyhGTo8tn7w7KFQaxwz1DzGnGUURwovokqCINg0x2k/8on5PlSlCqD+Nx23bJjyF E+vyMR+Mp1qNRD97fRIeQ/Jq6GetsSyEon6/iE1sncb/lYSPKEkRqvJ55Jfd2GrqOozPdn4OXOLK NdTdcDLtHvCMcHoaEfr3HprEZNhk71HUvxq89Wbwx52gUTr9kxAX6eB3+v4NCN/U12VuZHN0cmVh bQplbmRvYmoKNiAwIG9iagoxMDY0CmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGggMTMgMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyll11z2jgUhu/5FeeuyUxrsCF87B2BJJtZ2qHB k15s9kLYx1itbTmSTMK/3yNZAdPNtJjFk5DY0qPzpffIz9DzfOiZy31Heaf7MIKN6vTgjn42neeO bweA+4pyuA5p0NjcCJNOPc+HsQ/DSQBh3rm4LzTKAvWnuWSJhnc+88XN8r379JlWm0ppCHp+cBl+ 7/T7EC46FzNR7iTfpBq+CM0jvPzQCQL7hKYcHj5dRE+Xdi7c34S3EErDYkUMOkUoUSpRKOAxFpon HGNgyjwhmu+/0WIRVTkNAFbpVEjlkU1ZBnYBBRIVyi3G3pEFYcrVYSL9rar1d4w0aAHXsyWMxnsj DnZ9ULDADcuOVl9KseWKGzMfMGOaFxsDsbPmbgFFM8zYp4tU6/KPblcbHKLHUSeekJtuRiEqFH7i RSIoILwATBJjjyisETHTCCJxnLJa0wRai56KhAY0nPFgmSFTSI5vOb6Y2fRP/JMlEZOYVFm2++gi uoMYVST5GmEnKvkWPRMEiqCWPNLWxxeuU3OnJOMci7z9yQJKcIz0Ky9FYRYFfNWSRZryl0iRHw+H nGLhULyIsoqmrnheZnXCr1dzWNTRAU0cY++bqbEJ1AqtaTDwGhEyMatryWasmSXjEnkPpbkVE8O4 JCoNL0xKVugdreAoR+sY5Pt2NUorZOvMmEHO0546xNv3gDaZFHFVGwte6wv6R3VnmD5QzT1XXKLN bVsqjJx1gQdTpaq8rHPc3rYGq+/BTGLM9Xkcyxo71sCDz2hq73+wJo515cHNK6WkLgKq2VrS2rD8 nmMNPVI1mVNdrVAZINxm4uU81oh8pJJkWsgd1demYFldo3OmGdxrzH+bVxLemjX24A4LpIDV3i1Z 9AM1zDHhBT+t7vy+Y028mtEwo23s9yxDo1q9dzLulKsda9BgBa4hPVJ/OGM3+VcNVp8kHFFCuCux tYfEGjZYA4DP0xlM45gU8ox4NVlXFK/ldrCHtWWNGqyhZQ3PZo0brBH5yF55XuV1aTyYznQma0yd opLSNIGzWJMGawK0v01XIm2+FZLEPDatOOQ5nuJv0GvWag9gQbYU0e4cpT5mWZFW1FMjbB15YvlN VgDukLFFaj7FD/hasYzrE60MgiaLCn+lma7O09ZjFhX+n8ikXiPTYE+TW5Z1w5SqLRVZ/DvWkU5Q 4VvXZimzZwbJlTYdYDr7y2ZT/prV1AmfCr9uRvCNFzFJdCuPj1mjPevOHBNs56WT0amspub44z2r HcWx3nTC7zmRpuONFpHIqF0qxTZ4ek6Dg0745p3CtSA6ZTzCI8uqNjW7Z/l03LGiOucqElukzuYM O51ldGIwsKcdkgU6dCVArYxlXuPVgzY8nX0UCZKMUuh/NC8S/f++ofy9NCsH/xDxJux8petfYFQO 3mVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKMTA1NwplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3Ro IDE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpZfRdqJIEIbveYq6m+ScGVdo NGbvmJid9azJugm7ezEzFx0otDdAG2g0vv1WIyigjuDASUy0+7P+6r+r6Dfo90zo67t49SLjl6cb mKdGH77Qz9x4M8x8ABQvXgSfXRo00m+4gbGdZ8LIhOGtBW5kXE1ihUmM6tM44YGCI9d4ej879j5d TjbPUgVW37Su3f8MxsCdGlf0gWn1YIaYwJ9BQL8fME35HKHX4bZG1x8M09wRWY3o3P3RmWrdEjFn 2QXr76XPFe5AHaJj/ZI1qLOqgbVlmSVrWLBcTCIRcyVk3FHlnnVzhNUta3vWqAePKOaLF6l1XpQv q2Td1lmX5KtkWf0KayzXcffIGCtZZpPVObI9y6ppvMRjzC5Z5PvfkSfqBbm6JPNVFvl+KuJXuFvw hHu08UWqhJfCE75lmKoW3mCDkjU4wWrvMTYsWeR7eEYvS4TawJ2MU+Fjkls2batxxyLfw8R5dC7j 1Fg5zQRKz5zElaBuua+xLID79yUmipArgetf4X7Fw2y7Ob9kFG0oYjwVK7upshilTMxjHsK3qyLf 366pWv4D7maJtZhb0Oyizo+54jBRGDVEn1E5qrIGBetfDMNPr7HeSzNJmltmrMYaFqyHLCR3cfKo 4/sJye3GYlQpnOUSY1+8g9PrtoYHcTHdgbfVdYorDHd+/y2U6zaRVVhbmuY9SJ/SPiZjeHr5UkWb PoWxSD25wmRzKuZDltVgjVGhR6hK+3RFhDJTTSa7bbLIZU80kKZUZk9len417X6TpT22U/OceZ5e xla5P2QNdnGV6nilTKpC3lGW2WQN9/k6jWrJuoF610XanUEio+030Ab9Qe5sq0kbnaJttZe4czRi kSd2Hel5iZ4IhNew7Y/y34jM2vu12svb+YI1WdbBWo6zZUi7nfRW8EciPGQxqE75CI8SpnxDaFYW Djyh1LabLLvGgrVQC5jMVnZOpT+GpzUesAYnWMBjvytrWF1LUqQrfLmdzuS+7N6Op+tyiP4cI4xV l+54wHqUSURdYqWLFlUHjL2THewsaxIHP0uzy47rZGohkw9pZeE7a9Qsy8rPIPR8SGelRPqZp1ti 8SXugmIEfKdWCUr6fEPFw5NhiPkgkAFE+Tbx81KcglpQTfGkBoVAzf41pTG1g86KJ4K/hAgvZI21 8Mko2iNvGQ/p6ahHDxA8Woao5xENUwRF/T7/N+cRzLZz2BNXoQgCQAU87FWObfQMIigj8MATbwHs oz7AMTi4vs50cWDfiXjvGn/R/T8sgU2ZZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iago5NTYKZW5k b2JqCjIyIDAgb2JqCjw8L0xlbmd0aCAyMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nG1XTVMjNxC9+1d07WWhyvZiQ5LNKcUWJKEKaj9wag8hB1mj8WjRSIOksXF+fV5rNB8QoMC2 Rmp1v379uv1EZ8sVnfFvfpX17MO3X2gXZmf0B/52s6fZKm2g/CJr+rTBpo+8sCln3bkVfVzRz7+u aVPPTm5sVN6quLjyooz0xs/V7fWXt9bxc9nu2hBpfbZan25+zM7PaXM7O8EDbaVpC0VGW7Vw5SLo XRXp4eT28/3DKXlRaBfmFERUxuioCD7U2gqDRWGL0/ez1ao3JcXWqA9X97dUu0LVYUm/m1bGVkTt bMBNFBqlCj5HT62AuSO5kmKlQrr/McBcZ8iSk7L1VLS40ZF0ttS71idLcA6mcAr7cBAWXl/8cDon 57MxHBBYr5WNi+gW3TvaiqARQrbfVMegpTB4oyxvEPDnUVHdmqgbEatsS3MKSuWVlQpXbEP0CJCj mwMqeFWKAg9UlEu6iaQDASiHYBm5xoWg4Wi2FSsRU9QDFozLFv8OuogV7YXXKtBB471XQE5GdlXb Qu91gSPZjlXI2Nb50EXKFlNqupMMUzw2CaYI3pRa0lZpu6MAGJZ0CRdttqSeRd0Y+A+4gy6UfwEy cvLxbL1crXYkpFQhICDgAW4ov2eD62xGhOCkBmEKMqKJroG9ummBHBhxw5kDLsrutXeWczFP1wgb Dnyj40/Z0lOrQsr4u+8MFo7xzhEi19Ggd4tD/+0db3sH8AvVKFuEkQWHSsvqDe8O6r0HSMI8chRi 69rYAZjO4F6s40PZ5y2jiGsmQL6j75U2KvlTao9S66zP86aeYebYc9y4oHK4rwCtxZEqscfyNNaS frq42zaBSueptTAW4kuXOiAd/vlXt3tlUDp7ZY5gqCdxEEeukIHBqsiWtkcK4D8e/ADf5qkSg+Yy EFa5Npi3PXMWD87X7F42NHFySX+6g9orP0+rqaZ4fUCSAaTSu3qCRTaTEQFuU9zTASSmYwPD6EGf WqO+kDOohIJGdOnWg6b0ErJlhm/bniAMT+YRi4fJivQqJYOZNrScRFp3uUA8BtseTpd4vl73SgiW i6LQibtIcRu10f/yTVzU7MEEviR8SLrbMn+g7wfnkxKOwirAT1nhXmV34C2SxB5a19kfdAQhWmQN 8gAxOWhgJjmXTOWd6+tgz0Wma7Ukui7LtJ1pMboopmwJlfNxYfChGMy7Xi+QicY7RFNju2R9v/lC HuWDzX0cyF1Ia6kIvItOOoM6BvJAJhvyfBVCQZ2lnHB62UdoGmL7fH9Dt+IIv88ZzBo6G1lr8xVj fhHajpUZyVfLHWh3fXv7mWrkR+wU61zxAfnySrqd7XKDXF9dX171DvYCVvwQEoYgv0gsbVJ/ehuJ kCpki3yqCIHLMA7llCQYG8B+dJ/C47SlRnBX3dVzqAtaCZiG/hAGhwQCOwyqng09nDDT0ECyEqtn HWJHXYU2zTWhd+jKqkiAuwbNRjHCMJeQXGRDr3x4SdtL24kH67VBjaYbSiEjLk+l+5KjiZfMxEKX qSnGF6ytVaxckTwe1W/ADpb7mqtRinuNcuvlMHHIL7PLd6mn90CDIcYdeYrgjOaOjHThuS+YgyIf fx+4ZkJq8wOOfIgCxKwQBtDli3unOsRGD2ivBV0zJAh5Tn/df5qY4pyyMYWKNqkAc3cbW2Z/lGUi 7xMxClmltjflyJDPsUS4bKOSldXcBudDEQVXxkNSBGGRL2DSx5ZWeRyalEJiXuimKT/RujTYdbLR VUtvZErGCeUghKjZyCH0jvQU5WnLYi8naOzdGUFkbPCrk1XMgxAm0Qg5zn8Zvg1PBkbIx7HbpsMW JcxNwOHWYarppFSnyQlpHwR1DkUWReKSyEYQTzeE5oqbDJ9peEmS8dXxwAv8S3C847Z6jl7VaujZ zHMt0b/YOEYTKLkOVcoUzjXKg9+9POVoeNTh2U0n8qPZ9vjgbtAaRxfcwYq+3wRZ4Ua8tmlWoau0 B2Ma1ze23aWJdBgiL7tTDydXl3eXLAQ8wDG78szdsmnEnZr6OMSHY4hpQP+eBCobYxvZm27DfOhi SNnYsXg+4bzuhTZjO+WG04+kiZbd5a3lBtk1rE43hmpXtR6HAAh9atwVSKX6GkNvyxUF9iIqQDjA Dtt8gItOeoVxPitKbzBZK5ziVnpxkUTpm4gGKcR8DjItJ9+Orp8bjRmb7oQH7Odz/p50/v8vUX9/ QSOhi39g8Xoz+4rf/wDafZuPZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iagoxNjY5CmVuZG9iagoy NyAwIG9iago8PC9MZW5ndGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyt Vltv40QUfs+vOG+kiuM26QLlKnXVAitld0sVnggPE3tiD7VnvJ5x0oDht/PNxXGdZMUK4apNM3PO d+7f8Qe6imd0ZX/CZ1KOLh+/pEyPruhH/GajD6OZE6DwkZT0egmhG3uw3Iy83oxuZvTFV3NalqPx G2l4LbmZ3tVsY+jMc7e4fzh3jue2yRptaH41m18sfx9dX9NyMRrjQipDWcNqBnROLE2FEUqygtZM pjuRmpx2osBXXBaFSpjh6TdUM5PzOiJhqGT7i89Gs1kHWHPdFIaEpJQZRoXSmgD1ErrmBvZ0KbTG gSYlCXBUCPkUA2s+77Bu0xRwWsjMCSQ5XOAy4xqyGo4QW6stj9wla0yuak0523JK+ZYXquLpwDUr dmedWsAS3T8DD2D0UCujElVEpGqXw5iWVtJmswp3VDdSA8zCrLnZcS6JUa0a1MSFJwzCNIYlOdwq VcpL64RIuI5c4nZdEO4uIBlFiSrLRgqbV5cAG2TNEsAiQpEAVFu1PXlnI2csUXLL64zLhAckxCvh wWrMkg+N0C7TTtTlX22oUgYSwmYfTltnJBdZvkbKVhcu4IC0UZ23qWBZzUq4UHNqNOKCv+gFNFJt 3bXR6ARZtvg+Wyx54kYPi9hO/bNA8xT0DuGHg7Zvz07mkZfw84VQOyhge9zWB/2z/x7JhAAnwdZ0 Ei4mR9/PHPU6AaSlR1/79jv/tPTWFb398+/w/HU4Ooh0OgeQI59bunM9MwhneNTr/J/hnGSv/3Sz cvbqRHdqm6Cva3uYrF6nE/l3u6sxj7P40wyffN5czePZbHVxXrnvzY88P4isQc/PvvZt/Q4Dr+qn YPaNPNxHtMt5IC/X3d3gG54YN7cgEK7tnNoZAWG4/h70tISKI9LV+AgH7kM1xfyRFpklTjt/wA20 sxXMUxp8DL51dBXTLxUIoOYJF5Wxtt2wOpTohb8BCRxOhj11FLDLMd5bS2yJ4xE4l3JuiaCCgaoW uI5IN0lu2UlIsA0znjHAB1DcH7mjHW1dgl5B+Y2V/Ol+sXhPJcidWTp3ROg5zXknfcZjei8DFLMC MGK1gaankvMUlLRmWuioZ9aOdQkkV4g/Ao0bFWBqXqnawJv9CdGGJDkSXo0P6y+iAuHKZB8RNwlq YpCdgOZ2jSfmNPaWhE1IyisUDnw7ADV7UKXlZKMqVaisy5JuKuuUDWbfBzIk0dBxc9K52mHJqZ03 lzDZ6fsUbawgc2VDb0LFl9iR+KDvICvRpbC6E1jyqdhsIA6XD77q2Pa6yRESf2ZlVaDontFug+fC HpZu8zBsGCHN1Kip+8fB+G3ldV7b1PRGbfOyLgGohN2aPBVN6YyuFVxKmOahtMNdDKBuHYV6msP6 +k9VjW1ZVZeqOEAtDz0Fg6zQCq8bBbeCsN67pbl7jbHneJkSG19Dj3UYqMASfv7dzFtQLGcT2ZKi +rJ7QTCitIJY43UX47QL7tyMnCe0k7UwfAYboG+Kw9Wkq/T5ddqtttvJ0RJp/R+/s+y3b93qo8tL 8kvw++H1gMzbc44/TOfTh34LDa5f7sDJx4M9H/7k/D7/RITBMn/1yiXwkZkCY4SOQrvEL4TvnysU U9NbVoMzryP7Hn59ivnrA8iQPv8NiPfL0c/4+QcbR2X1ZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9i agoxMjMzCmVuZG9iagozMiAwIG9iago8PC9MZW5ndGggMzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJytVk1v20YQvfNXzK0SLCmWHKRJbi7sFgGs1rWZAkHVw2o5JLchuczuUrYA /fjOLElpacmwDqUgiFjOvHnz5oP6AZezOVzyp/uVZfTu4WfIbHQJv9E3i35Ec28A3Y8s4ZeYjD7y QZxGrd8cPs7hw6cFxGU0+lI5NBW66Y0RqYMT183d7f2pc7qum6yxDhaX88U4/je6uoL4LhrRg11v sXvF8+V1cBj/FM3nPc7FdDrl7/TiTJyDA+GMBuD++HWs8PEucL7oDpc6QZLzdEK74HHo3D+9wY2S 6InoF5/g8cWQ9jEv9obHXBhM2vvw8ZHni0vDEhPVlHT3lmkLDedYdqZnGHrLc+zOsDo/60Nl3rbs q3RO9KMmex33fzE6P+YOHnRDQ/025mDoztd7sejHc3/9qrLGICw+t9vid3RP2nyHJ+VyWDaFU3WB XSFakW0X0ZsnmKoKLQiw6ECnUOhMSVGAVVklCguNpYZfb6FkBLKrEnA5KjPYFcI5IXMyND59O4M4 xz0EzUwL4zRIXZZNRREcAm6wcpbghOsoaSkbA7riEFDnW+upFKr6vhrZ1RhKUYms5cMWntNnSLUB fBYlJToB0UEZLDXFqMgEkBetqjIgwwLFhm/Zv2q1mvA5s/CHHA1y0askc1FRyBlcW6ulIt5Jqy3Z 2mGOew0T4QQox3pNOxhVEctSOOWTo1AJWmnUGq0PGrJdjXCWzSiTJDFo7THAajzhOrzzrJEZGiE5 Q+uUtExgnwcpfoDvkDjIbNBLXKzaaKelLkDZrikSENwXdFag9MQZeVvjtMAqc/l0I4qG6cZ3f63G g35YCy53SeypXHYCtkap0m2vey+aF4KVw+dOZlhTSRCrQxnbeeK2E229J30PhjKL4+J0UWYdUJxz Ylo2JXVDR0ix+kZUttbGF86PxL6kFCYIsVE9Jwb/enN/cJ3BH3RmDgfW96QLZeU0a22tWlOXdkDr pk2fcrSKKu9ZS11jW8OA8LBeQ5oEkDbGEwgKR6NC5LXZcnPrmutHYsBj6zWo1pMqCu421RoVW2r/ DQYIrEQPEUjSS/uFJ49Z+u60sPz6GINtaq8q4QVIobb9GmGIg0WgODXvmtqbIEkcfu/S8qgLJUiO 45jX3zoogtf76FaX6MebaEz6ydincrrSJ7Sm7dWuSKqfrqbaKF4pCdQ0eYnKyn3b7rcSlcK/0Ah6 oLVyg2Zt25vSSaHsd3Xo3y2Wfr2SItyE7997uAfhCpWmgKzyLHgl3D7XilYHLIWROVxN+F/i1fGb 5e97mk748A8h3sbRn/T5D2lk2eZlbmRzdHJlYW0KZW5kb2JqCjMzIDAgb2JqCjk3NwplbmRvYmoK MzcgMCBvYmoKPDwvTGVuZ3RoIDM4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic jVbbbhpJEH3nK0p+CZYwMTjaJNonYpNdS2A7hGi1Cnloehqmk7m5uweH/fo91Zfx2PFDjCyGmZpT p07d+p7OxxM650/8luXg9eot7e3gnP7C/35wP5h4A4pfsqQPaxi94xvr3SC8N6F3E/rj/ZTW5WB4 XTllKuXOrozYOXrh72oxv3vpPv5m7b61jqbnk+np+vvg4oLWi8EQD0zdApY2Q2FJV/RR71ujaLo5 HZEgqxphhFMB2SprdV3R8svnNamfGni72pASMj99NZhMEmRZZ6oc0/UOCP6aMnXQUpFtm6Y2zlLZ Fk43hSJZV5WSDqiWXA37QAdwDLQZHrR4NC7qvZaiIPhs8qP115pF2QmpLDPGk+QjQjxz0GEFP/Z3 goxIKdQe5JjWubYR63UINb3fmPqgM2XhQApjNDQGQsTSFa5LwRjwIXNR7b0WEgnW1Z4qpff5tjYW EhhV1iBXAR0xksuFI2FURBJSssMtQmKtXK6eSD6mmYUkMkegBZTbeYsEf1aogyoiUuLhy8BLIUVF W0WqOmgOSWWEGtm2usiYIx72w9gKqx41T4Gwt34AoFFl/m6hqx8Ej0ZIiAeZtfQZcnndAflXxvgx nabaWnICpUDpOXTBTktCAsA7K0APxK/vEJ17qM0PUD1CBaMPni0txBE5mNJydvmkWkWWGUjoA8gI kTC7YHyRHo5pAaWM2DOUN4FXK3NVqlHk+iKxWIyBWigvXTbFkak5o6Bc1MjzVFnCml12tCC5qI5U w8rADDpVQXBdxVz6aFGKdXLH9zsNU9P0XkUWkM1UDJ4WOgDsdSMqxzXnjg2/VBxHbBKRQpmjBEPa rX878BIxdSp0jEL+E3z0nzIaK487J1Yqk4G5diyYeEBpp1efYWn7LKQENkKJhbnyYlF958HH083R Q90WWa8Pf1NZ/LCNkpqzKop9bbTLS5umW8QK2K1VLEUgRKVyhikAtOzqYzPEJIkxQM1+YqiLEVpb jA9PxMq66TTomPg3Qj/hbqGwEuA4PU2DBtWGIq2c6EZgBoNM9bpqgiVFK3XfauNNEwUO+4c6IjCT WTrhgXgyCt90c+uvV/NPX65X8yu+/vz3bLHoLoLFk0bDg9svi2jLV48ol7fL5fzmKgAtZ/+ehLhO bu/W17c3s8VJyEmnTlbLlqnyIOSYMKX8ImiMcmFMQVVp9DZ03ofLO5q8GdHq4yVNJ5P3EeUrfvPP bz0xpjwxbVs2Xq9ouArLwnPyKbdhDIcdCG/cPqlqrSjDsEOi1Xg/HnnbpyPHcF/4BkvbRGUoBR64 rdOF/k+huDKNxGPqYFQomVf6vvWx8osu9aRfSL6C2U0Liodah/F81hiNSmUHO17qImysufb1DvG0 O3KrP+tv3qHdFomcdKWd5g3pR1VHCytO+uF4XcEMiy91Ahwo2oJWcKP9TokQ3eu8etGnfu9l2jce +6qlbM04Iv2Tqzhsn1l6KzsK+yXw9nUpFXig0yEENvQhhdZ3ihxisDY176H6MdRX8IEeQDM+XTh+ PMakWH9a8Pv9DNIiONQXHx4yvceBZ5aodHXCo6Yk8ST56YCw5dxzez4ugV+V7Z0vzvrDpjtloCxR g5baquBtgeS1kLzgYadCpjfDCR8bdAn6ABp1iy5CsWd+imd0EAUU8Huk0CrzB6rNcMoz36LacVNq h6J1tanQhA8+irBLemj9ZTKmm9oXDtqFZyM3CZyZx1MGkFOb/5laxY8upPf5+OICkXldxyHbVvSA INFtCdTPVrXbKZ997K9EKzy2yg/JcHThklQh5M0pJ/3NG5+jlXCF3u0ItqIY987Q858NRqSlpTDo uosRn6Yvfj1qf70TOM29/QbE+XrwCZ//AeiL4stlbmRzdHJlYW0KZW5kb2JqCjM4IDAgb2JqCjEz OTkKZW5kb2JqCjQyIDAgb2JqCjw8L0xlbmd0aCA0MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nI1WwXLbNhC96yt2fKkzI7OWFSfu0Y3dTmbcxE3UQybOASKXEhoSUADQsvr1fQuA FCV7OpVGlkwAb3ffvt3FDzovZnQu7/xdtpOfP72llZ+c0+/4rCY/JrO4gfJX2dKvC2y6kgeLepLO zehqRm9+uaBFOzl9bwI7w+Hsxqk60Auvm7vb+5ee43XdrTof6OJ8dvFq8fdkPqfF3eS0P6O871r2 FNYq0Ea5oEu9UUGbFbW24tZPSZkKy6wdbdY7r0vVUKPNd1kpw6ufJrNZj6g8KQpOGQ8kNoGWTlcr Lujzhktdy9FmNxWwZHcTtDWks3U8BprgVOzhgYqrf1y/I1VVjr2n2jqqVIg2asCRNvBuR7VTLRO3 OgSuaLkbQTnbgTvya9s1WOJofIxpa/hc8aMuWeBk2XFrA5NB/EVkKWOpxttDwkZAeISYqTP6R8e0 1WGd0UqL7D0FMXTs1lmkmHDWI9QCaxcXPZeLNXipbAljINJxzQ5GYX/sXmL85APr1Xpp3UlB/U9P pTIHyUHsugIW8pBIYvgIamLEiSWb/otepbw73iA48UBlz31O5UGSHk65WBVypKfj4VViiJ+0D2A5 cSG6eTjFYgZrlVGrIWXJcEG3T6rdNDzkZm9Hm7LpJGxhvs9KMgjjQn6poPU7tUM08/0SAlPUdk14 cb3ISNeeTkzP30lMZ6V9aR/ZcTVN9ZKY8pGcVCC07DSkFdkWFG0g0zb5u1SeJfZRDDhalpLwZcP0 qNU48HdrZVaIW/dYwheVa+VQaezApC49Qv8ih4xkFPmxTkQPISxZqvYkYp1tkeuTjILs1DWXsaiv 7+5oiDG7guMHjiB3IEzMwEK/ecAaxYKNvRyOxcuJLq9XBmUjRVCihYkHe+th3YnXpW1TWW7VLpZ4 5viwtez5RhG0SpuATxKpsRA19KzKNdmoabUERJTjKBs5gpiTQdfikdgeWpsANnYVf/eyHpQzCPd/ JTS3lSLScSyLDLSNfUl6hNJD8YhT4/29H6N2EyPPGB/vF+8/fkBmv0yPpc2otenLMno4bTk4/JId L4PVjd1G35xtjhwqURI64Oxh4p/PFM9l53TY9S0gN7scE6lOpCzsRmBbH2S93yyDyUASU2JTut0m 7+3nQCzwJVIPQUrXZNWE2ILRWHJYYrozFbtmF1MehxRKh1oGMUb7dmAZzaiLKVCjbb4r133D8XSz uPtMX+Xvt2MGPjP6P8ROH7p2KZ1CFB1pASVeSXn7gHAI3JxHtUmfQWNDWwcRsRkecGANR4wkb6dX 0F2Tm3P0L4+9DF+k6uuMlB4ez96cLXXIrh85h0prUJzS4MSdN5eX80spr/PieRj74dYr98URp3Ld 55G2xzFjHGk5Q5OLB2C1tM5xowLHGQfaDQo1TzyA+PBfAzL3IZnCKHoZH/JYDUI5bkhJ8HuW47VC B+kvrjOxUUVa5OBfN/d7JUypC7rR/ySBbLlpzr4buzWyKwd0L4JJ8Rb0PogkU0lUqSTSIBlbSV1r sNFPx16aPrcJtOM+YGB5RlmArmYnxOR73RxTJJXm87rM0zNS1Jc5pULGvDCV3YpDvlyDO+xRaIO2 i/02XVwONTnyBDL4+um3d5eXb6++IWIRBWJOQNPhsrbksGU2zy9nQ2+PV0HHKg+0sLUiuUo7GV5W ZJ/c9EXMPlBev44ufVKh0XVNjLJqitHl9/Zpg9OYmcqheuZTuQbPn9+Rv96jcujqGxBvF5M/8f4X PDLKh2VuZHN0cmVhbQplbmRvYmoKNDMgMCBvYmoKMTMwNwplbmRvYmoKNDcgMCBvYmoKPDwvTGVu Z3RoIDQ4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniclVbRbuM2EHz3Vyzy0gSQ 3Ti5u97hntJeUBxwKXKui6Bo+kBTlM1GIh2SiuN+fWdXoixfUhS1YTuRyOHuzuysHul8Nqdzfve/ upl8v/iB1nFyTj/js548TuaygPof3dCPSyx6zxeW1aTbN6f3c3r34YKWzeT0s0smOJOmn4KqEr3y +vTl+va163hdtes2Jro4n1+cLf+aXF7S8svkFDdKr9vGuES2xLetrImUNiYa2llX+l0kJRfo5MaX pqGF0cY+GbqTuycF+XD23WQ+z3g3i7uClCu7PQvfIujXNtFicTfDzouLvPNzRTqY0iYcGQy10ZQF o+zp5rdfl7QytA4KNShptRf00KEG8o4UrfGnOwqlS4CmWKyQXyx44b+nQvenCP7+TA6lRpbYCETG CiZuvYt2VRuqEL2EYt16CDn5LiZJGBWoa7/j+zYBF3cyjty/P+P10aBMpUoqb5YzZ/TFPpidjaYY If6PSPokF0zEbmP1pgsmHo7okV4LoTvtmBiRlXne4uQIdQCtP6vbaR25tlkxDxV5nUyKM1oCK/mk 6v7eETG+GgereqIOsrEOt0WUiEqVpfx0iRasjT5+Ve/UPg6RlaxURe/eTFcIrUWJ1g4XH1uuT9q/ EFsnsLHkGuXUGlskKGfserPyYRq3RqMvNK1UtPHjoKajlKLZqqCSyZXRvnUDqnUJHwAzX0aBkQwO Nh9bG5i+g0aiCU9Wmxn91MdWenI+kdpu630mSkgBHdEK3wjJPNuIxSuTdkY64aC3KKUV7uOoDm9m dGNSsDprS0BR/botOxsgtbI1iieRj9Q4wHE42jdN66xG+kc1aTrsLrpgqtroJCB6g1pBKAEB84L7 UzNbz1BfV+5smTYF1cByeo8+8VVWKzY+qWAVhD8FqRJWbd0DCxBczugqEosGBUGpreullIIvW81X h/LKf6zCtLFxcMBiCHijnli9bDksEugTC1kT2sN/nhNNeyjh81k129ocdotYpR4wXKiXxZnDgX3v fHiYdZXu+nKENYLA2ZE7oD8b2/LpEY6WF/ImRVmhPdIgLjYeH02/SgySQCzcQkkFMvYhMHY/sNAD nQjFU3BiTgYwYXOQIpvBCBJC07prxierRpoWpPuzQXAUW0DYrtmkGLcGuuKeVbX0TcE2X5rKOsvI xRhIQvo4VGGM9UtO/r+hhNss7KHLh+p5V39rGtz3VJtKjMky7SycPnPuhI3nEoG4zp9xpmrrBN3W LRoKBmLKYyeU6ttwOP6b3oCqy1KiRqX3RafYxmCVszEbOfoHTHJbgplRhXjMvsyrlxF66+bq90Hj yQ/zZetDguG4KZ+yhjfJvI6cpx5kDibFTrhZ2L6629KQmSlZ+KLZ+dD+jMwfVxpf+kipL8UsnGCR 2PMoS/HlgmzVjSbvXNfh8TUNiiXn1u+DhnbbYKDOI7Z5hEHnwbNh++ow0jnI0laVCdygQ1ceGljm 4hHPMtEUT8+VTxsRHOzw2fbumgcfnHTLl3HJ84Di0zrIPgUG5uE6si2IDNOl7sd7VgYmP8LrH5S6 MZ2NJmGOxsamxONv43fmiR9YjnpA1WsfIKmGvXnLz1l4ONToI5M0dFPJM5+0UEICf/fji0q48jR7 ZCYXoWJmcD5R+62RXGWadc5ostlIrKO8mIy3b6WAC5Vq1BunI7LZ6Kn2+nlrAUI3KoCjy4Kfby9f Pvz+cYuxTh/+BOL1cvIV738AFPnGYmVuZHN0cmVhbQplbmRvYmoKNDggMCBvYmoKMTI5MwplbmRv YmoKNTIgMCBvYmoKPDwvTGVuZ3RoIDUzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt CnicdVbRbttGEHzXVyz8UhugFctO0/TRgZ0mQFKniYKiqPtwIpfi1eQdc3eU7H59Z++OsmjZMgwJ PHJ2d2Z2lz/obL6gM/nL32U3e/X1F1r72Rn9hv/17MdsEW+g/FV29G6Jm97KhWU9S88t6O2C3vx6 TstudvzRBHaGw+mVU3WgZz5Xn66/PHcdn8thPfhA52eL85Plv7OLC1p+mh3/PKfr+8DGa2s8BRsR Tn6anZ/HYzz3Z6NbptBoT1UM67h37NkE3N8wrRioXNfW4YKt47XSnqohNNb5gpSpgLdYjHhyvrXu Tps1rZ0d+kLCrpjqwZQBaai2fQBC17ccuCAdCKEdl3Zt9H9cAUAFIAoWH6ROW922pA0BhVp9x61u rK0E33DJ3iv3QMpTZx3j3NxlpPDQsyeFi0PQrcSZ09IKit0SakN2YcCpNsZulKRZxEoiJRlDbi5V AI4ZuhU7qdD3quQIwPc9LnXgTSFBqS7+DjF78LayoclAXq/BghfqqFJBgQPu/HwiSyz2Kczn79+W UmqperWCaoDtlfOSiGAp8Iuf1kjqE1E6HKtgwc3zsYWyypaDxIIE2iRD+J5LXesyhp/n7GNmGebV HoToFhm2fZK5INCiIqmRy32GMtYjkU6ZNdO3DzffP11JiR6uNAFOqZzte+S0gq7mCSOk61Hfhh9i LGMDDaZi5wN8MeV02UgusFQYjTym+gIthfCyZVhN+QNOJ4I/cUQhng5TfzkAOKp4w63tu5TEPqW9 s8GWtqWalXgxJTN2zZw+qI3gT8LGYBlEmtZtwJSEE7e9pPVabwDeqXvdDR3VLd/rFXoiPGSg5GbQ VEk8oWmXGmgoLa4nO26Vg2xhTu/jE0q0KXatu5fmXvDSDm1s18EnUZ96HKxh+FRjz1UpGEA6Dk6X fk6XMj1W2iQLQMkpJanocTBFEO9tqZU4e1/baSqIu0sFswSqiXSoNjg72tWXDc6Rwsea/LDy/GOQ u4V55comEb0ncMW1NpzQsqhjSnvSxkljZBD6ZkzJB+lYV8WJyDpaR4mSNPSoAQPb7pyvH3s3tVy8 b4+5CHaqWotcDlo6L4o3c/rdug53f8MUFWLfo/5J+1yGaAagudhAityA5J+dVLfH0YGY/0EyR7Wd rbi7PZm0kDZIUck4zmul6waTc/MYbaEB1SiFvl89DVHEwjMH2pTtUMHUtmcTpyFB8TsOMTKskpxs 03JCP5/eGbs11GOpCVHQZYS6PV6+u7o9mdONKV/MSrobaxEzWPuGq+JwMmW0bdQz6VfADn1uKtAL Z9V6PbhcDVqs5GRDMbOtEBCLcizQ+4FR1dEXBp1X2pd2w+7hCE2BlbfmeZxt00P6fPlXtBJyGpsy GWmjVaysG9qAMH7HwW7FpSESlc2ERGfJgypjRUoeH43nMqtlwlpJtUfbYdLIamd8H0UHFBgaOm+p 3dzCeZ8dNS1hOr7fiaOijaKs2Vt7HpLXAjqqHtmBRAHcXKeyD5aiQKU1n7BiDeLbIr1mpLZ8gfrJ Ln+W/3Q0yhBxor7qKXc762lQcNpDfadJHNpyteZxV40aYVz74LMi2dM7JR/HZrwX0h2uwCyIe47x 0VAy03pMegx5kLcr/6au2R1NWMxVyvg0Ytogzyq4XOKLmzEtdKl7OcgvAukNIo2ZyBwAX7+OgF9V aHWNkQ5ywOrj5/q+17ITP8dBe1HIi+7FwUvw318k98XZP0C8Xs7+wN//667PW2VuZHN0cmVhbQpl bmRvYmoKNTMgMCBvYmoKMTI5OQplbmRvYmoKNTcgMCBvYmoKPDwvTGVuZ3RoIDU4IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicfVddc9s2EHzXr7jRS+wZRrbsTJv2TYnTNlMndlN1 Op26DxAIUahJgCZAy/r33cOHRMqa2uMvEtzbu9vbo5/ocjanS/5MP2Uzufj2PVVuckk/46uaPE3m 4QClH7KhD0sces8XlutJfG5O7+f03Q9XtGwmZ5+NV51R/u1NJ9aeTnzc3H66P3UdH4u+6p2nq8v5 1fny38n1NS1vJ2e40Smp9LPqyK5J0L3Cb3frNb43yjlRKRxwrTWlo632GxyZDs4sPv46PX8zmc8z WnqoIGmbtlZem4pK7aRFhN2M/tzoWpHfqBjoJt/ZB/uy+At4jLRS5JTx5G04H1Jr+tprKZCHKEvw cvRwtvxw83BeHDADsYKEKUnUdQJz/cqppz7goXhrLQvSbhSgN2NkvxGebKcrbYRXZQJ6TX1Gd0aq o/jkdGVEzTGEfDR2W6uyUmVBK+s3CaoVHZLRrTCe8+hsj/YG3o0tVfNwzlSN015bk0lOtQFp53Bp Ss6DWJHQZKdEqLag2lZIpS7igXVf50dQU79VygSoECSEw18JJHKY0e+HcoW6x2yQSxcSNdR2VgJT lUEUOiJKC4G++IQFOeGOS5gXMVwiMouwXAGjOke9C7j4niN5m2XQ6zpQ1F1QopIeaiVt1rZrRKjN SgAWNyvRlUFvynluGu7FNiYoZi8k89YrqPBZi0MhomBqbR5JbkQnJDhrwEgk7ZyVeqCBMAd+Y0F3 GGqG21dXeRCWJ7sV24SyrXYh9n409omjYo3QxuMrBDyMVm+8rskaFUuraG3r2m45Y1S+1DFfK2Xf /TiiYiObLAJEUC9tDen5GixU10SFQ4O9Y7Qg42W6jid4vGw34nIE6TXml9DoIjSjBEuMXIsg+J1v 4hY9i7pXR1X6bIBcIhz0ndMOuR0r9ng6Crq7X36++7q4HfFq0TVbaknTXxTEtUKxp9lbHJsL24p6 QYsNxnHGSaCL+wNQSOoxqChTMntLj0q1I1KihgSjYnAb7dPrHa10qTtWp0Uf81BaY4Jgtd+Nhs9v 7Wj+00BAAJZn61lDWOgvJ5ygcrqxO3+0Jatp77ZDunDeJpgZDjjbKIrZ4kw2QyixZ8tRs2qGNPIB yKoWO6Bf700QHEWjUHnHEsDRUPy3W/BLYHlkAPBw/qq5wBn516HSK8sl5GsjH9zquo6+12g/am1c APl5VFZiGb4a9yQfbMmt7R6PG5xNHK5eIc/omdZcBOkpI4B5USpeW6CMckyN0tVmZTs3Tch7eYzt J48kBKBbDd+c0U+ol3oRvAWLXLiYXnw4IyFp4b2QG3QvqTyBtWiB4t0SNrNR22Gq2b4SzPRrYgpp TJOZzOgb7/bWR4DBCZKiZ88MlGPMveFiadqgnVhHtksBfwIX23f4qxisGkNIFTf/vzbJL6FGuLde s6dm7X1ZfKRF1FpBt4hq5K6gG+FFAvvGK46Ul1iHqSy5J6G5WHaQachvWBzthmOQjTs7/qFYN3Zr crniQEcpByGlOYnSTRDDIDEJ+Fq342qESXjqYQ5+F6clJhYMOqIiiYPFDAmeoBZH/NBLTnZYWvah hFTBjsy+LlFkcEKHBZYHInb5jXvdnbBWEtDD2ZwpvioQr/H4mliy15RMmtMK70iHl4mNcNwPf3A/ 6Nof+t+pxkJYBodDgR7OrvgtZ09v/JKQhzUvKHc6dNJvjj2OytOFDLJXQdh15Dp2qkUFAyhgE3AG qFMKE/cET+Dpl5wouSzokVHt+5B7etTSg2vjEndxYKrcEu2O5HrC8WdsrjK892w3qlN76vyOkxYI b2EgvXsXiGGQar1eY5SI1XT4+PTSYm9hOYpObui64H8Rrl/9+/D3Pb+dz+f/APHTcvIbPv8Dg5U4 YGVuZHN0cmVhbQplbmRvYmoKNTggMCBvYmoKMTQwMQplbmRvYmoKNjIgMCBvYmoKPDwvTGVuZ3Ro IDYzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VbBcts2EL3zK/ZWe0aRLTnT pO3koNiejqZS7NjModPkAAEQtS1J0ABoW3+fB4BUJFlJ406PgcZDmcS+3X3vYak7Oh2O6DR8uqus spObV1S47JR+x1+R3WWjuIG6i6zobY5Nr8ONfJmluBG9HtHPv4wpr7Kjae21rbV/cWHF0tOBdTG7 vD50H2vSFq3zND4djY/zv7OzM8pn2REe+JUma1pAn1RG6Yqcdo5NPUhPtNR8ry3NP9zm1FjTiEJ4 HZ9V2luWjrw5/ikbjXpAUZZUay5WC2MdcU3sw2VpbCU8gGkhXAAQnoTVJKREQq3onkWABVZAMZYL roU3dkiT1FgjrGfJjag9zSd/otBabYpYGL8KyUQXf6glkgYUPnr6eNQlo2uN3j40KvRUYZco9Mdj EgDugVyjJS9ZbnraQ3nX304oIRqN1WvyXOkh5ZuOVrq17HwoFlyQaJpyzXXRU/ylFXZUagjsDXHV lLrStY/MuSGgxuOe6Cm6VYojp9ibcAJiDyQWICG2WXL9z6Bj0Zp7VhpP6x3Zrq7z6dW7yYwcF7Uo g4zmIaCJjsuU467VsJEgxcultqiMRGVaXMyy63MB9h5Y+dUAIlIJTmq5HtDSmirZJkgSiEGfXS58 sxpwFiwgi3AdVNg+Q+l0vhJWSBTREThPUg2iUgXYc1s+jl/Fgkv262TOgKU0Ej0wXBKaYMdQnGtp NdzooCVqVbr7FyKaZWRAony139hJ11TwG3rB7RfB04qcXEGtaHqBPuFupVFQxXWsu8NBQK3tlpav hjQHSDD7mm4jJS52diG8oKnXVU8I3ATz9MpEPV2/H9ngTAdtA40yZAeXgYvewtFEv+2ovmewdMxd 2zTGRufgpHYJEteRWueM5EAMoeb+nHAocxBaN1Yltyz2KkIuxuH9dcfFaaWuvzK7dnn4Unxab+L6 Wuibzerq7Mah9wJiqTQALthJgym37p5OFRjZMHag3Bh1FU7AoZxPwg8GTs7/2A+8hQytexqQRw+l 6fmsTNuBO/kOZNoaZN/T074M317zyTlNlLI4tztJ/yVKPHLVVkn/GzjuGbHnrY3j6b/EztL5fkbE jXamtXiTPSsGcwSzK424960IA+uA2fbeMHsoP4T55vo/hXn5MjKLmku8/Ujj3VcOt+IuHxsGkWDH yhWdDcKvrbMn6H9d481Fo/EnIF7m2Xt8PgN1erMFZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago5 MDUKZW5kb2JqCjY3IDAgb2JqCjw8L0xlbmd0aCA2OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nK1WXW/bNhR916+4yEsTzFFjO22TAnvwaq814MSerQQo2j7Q1JXMjSIVkkoaID9+ lxIdS4lbpNgoGJIo3sNzvw59AydxH078Fe68iF4v30FuoxP4SL88uon69QIIN17AHwktOvMTSRY1 dn0468Pb8wEkRXQ4VQ6NQnc8NixzsGeMZ5PFvnkaoyqvrIPBSX9wlPwdDYeQzKLDx8+XKPLNWhsY 6zv1zHiaonIiE5w5odXRq6jf75r/fFyMPsAoTQ1aS7aDwdZ2JCVot0HTELciV0xaYCqFlDkGwmFB rwZhvkim88vRLIZpUUosiE5NxXa4XIw+A99obRGchtLoW5HS4waLZ3Y0yxykGpR2YKuy1MYRlkfR pV/B5I/4rD7Nr2ZjKJmx2Ks/WiEJWN5DanRJU1IGqEoFaEzbaK8pzjvAeBeTsxg+okIjeBORBeP/ oIMxZkKJEHqPm2xw70JOngnrLOgMGFi8qVBx9G/J7NrGtV0mDNUBvXdCZ7Ck9JAXPjIYyMIahcoJ tSgq5ZNPbnw9xDiPyUk4eKyZq/KgB3Rngd7BAimn8yxDc/D1KIZVtW641PtaT9MxoeqdWoEt0Tih /CqnA1KLy3bjC/ZdFFUBY2+4JE711jN6UPy+B+g4bdkpsx9FaxfWLaPG+UxLqe+855lAmdr3gQz1 4/PR3zM32DM37HaNb+0BDOEU3sBbeAdncP4rc4HRb8f/8Qo4D6smxpQdSO5LhAeYocrdZsv+oQlc q2jjuOXcw//IZ5c3GoFXdxzDXNVF7ZNV82rRd57+LZMV2hfqVOrLgCq7LkhhSRR45YUifkqmG5JH Mr68ZPPJt53XtBa1XcheSIdZq7moe+1OEGbNqemBZ4ye7NAJj4FCm3Z/UW8ortPGU9+HvRcz+mmM wlFyHjd06r6cBodbWm/BG1CzEQwyIwWaXmNBQu0015IWWMtybCTfGaZs0E5iwDpkabVEXrfufnGD IGeeMWu2CehwcbVKSNm2ar8rpV0VUay2HjZO27DZl+nlarJMYDn5c7KcXH6YBJRP9PatofCo82ar JASxvm822pMUodL6XFV5W/NK5P68peOMKR+R+rhSSFB0sq2RrKxjFE7mtllB0nCO4hbNKxuQhMq0 KeoDD9bMYrd+rpkU6dOcedrvd0ndFYGP6fZhX91c+5araxItN6JsnVZh/P7SQWanpzU8ybsUWUai Tn3VFpzJ91JQgukwMHwDw57/XzN8VrhfFj7f/eE3Qpwk0V90/QvjHo0YZW5kc3RyZWFtCmVuZG9i ago2OCAwIG9iago5NDYKZW5kb2JqCjcyIDAgb2JqCjw8L0xlbmd0aCA3MyAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nK1WbU/jOBD+nl8x35ZqITRtj4XTaSW2hV20hYNujtNp2Q9u Mkl859jFdoBK/PgbO2kboAGdbh1VacePZ555dW+hH0bQd0/zTspgf/YBchP04TN98uA2iDwAmldS wqeYQIdOEGdBfS6CwwgOjgYQl8HOmbSoJdq9iWaZhS1rMj253CandVzllbEw6EeDXvx3MBxCPA12 Nvvxp0n95SxFaXnGE2a5kr13QRR1Qb25a9SmBm6DXCJqiJcL7Ng/u7wbwXGaajSmG3LwBuScPfCy KmHCLIMZswg3O+eT2U2vAz+utCYvn+DHr+CnBJHJsmN3hkZVOsEudicPC0wspnCq9D3TKZc5xLx0 Rk9O406jMxSUgjuEKZf/wFXFBLdLOjObXnWe+WaZrbp4fEGm7RyZBV9Jd0zsxwVFtVAi7ThygTwv 5kpDqu4lHI+/giXiuitMjui4YJqRu5obyxPz5qGxxpRb+JNLsvG6Aw30s2bSvg6Z4W2FxoEGg1X1 +mpNXca5xZKk1wYSJS3jEmyBkCkh1L1LTsZRpObXlYk+vFzRFtlgi2z4tIFcRw9gCCP4BQ7gAxzC 0X+RNYze7/3Pp9HzCC4Kvj092UeYosxtsSL/CNdMVBiG4RbP3P5P5LPJU5vSHhxLONybU0oraXgu qYs4FW9OU8VnCQz1Fs+WLm0uiS6/22ZWs3zm5+jQhgZA+MRw2/mWYVGLVeYN3LmINLYb0bqmmnD4 oMFazwbcaPqtNvQR7gueFKsaNG9xrz3lCVgFDBbUyzypBNMb+86dZrAf0cXzcpS3glxw02qG8z++ xYAP1LIUXmBC1N1S0shlOZpdYDKtQXOsm4Vr314bshtlTViawzSxMMzDXdqrNfCypB6liSqWTc95 uMsuE00IqQZueiGcVpq29K4DaFwT+P1i+hcoic8cbFFwTjSq2o6E5HcrX5vQ86eKuMyULuvvlcHV dKTA01Bhc8FN4TkvtFpQJTo1+GDXnrotrSqagfulSsmOIfOk66ZHDq/mIJ1NnJhK0VOk31YlSqyD Hj5LmJtQjtQqvs+c93fZmXf+542u0cjbpytS8CwDtFQb7WFAVxunG4QuYE2VPNx1/y+GLzR9v3R1 EI1+kMaTOLii518PZ0ftZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago4NTAKZW5kb2JqCjc3IDAg b2JqCjw8L0xlbmd0aCA3OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nLVWUU/b MBB+z6+4t4JGuyYtUCbxUFQ0VWpHxzKmaezBTZ3UKLVT2ylU4sfv7DglKR2oGySCirvr9919d/ax hHbLh7Z53We08D5en0KivDZ8xp/EW3q+DQD3ES3gIsSgnjGEsVd8z4eeDydnAYQL72DINZWc6uZA kljDjmcwupzssuPTz5NcaQjafnAY3nmdDoQj78B4DEsAHejCMZzAKfTgbB/bYcPz/RLsQ/M/X0Qz OI/h6AbCdUbhHMKLARpgRHmi5/h3z9bzuKnsWuSoCwwHlWofHc6b5VOVchdhJWIsZnSx7X3PfHYR 7sOIkUFQdnAjvH2acEPSnJoeODzXBij9PWevi9KEIZ+xiGiqQM9pxStia7CTqqhSTPCWg6jX0QRW g9h4X0AY5JLxBLQkXC2YdZlwUgRPKKYwYCoSKyrXoFjCSXpkwdw3NCZZm+fx928hkmhgWhluLRCs EzSnTMMyJ1wzvUYAouGepSlMKeSKzkxYztkyp+naZcZmFINjE8xUmTbEUiy2+RsKMipVRiPNVrQF IboFxkiHhFmsbE9sbsho0rMYAhrtRgt+zCkHSVUmUD+jhrBuU30p05YGcHuwYmQTBVdxjL8L3+3h M4Uss4Oi0Rwl4WskjCjmO9vkd4TmmRMwz7J0bTUU99xJ42R0OE9iiqpWtC6VQaiJ049NPn8r72Ol GvoQzQlPMC2VTxXFBLh2JWJWvOiLGRMHUvLaAiLBNWHcEpX14bemxoglb9r4WhIFb0TNvLob+KwV uHv7BgtDxvppLAfdOe3xxEQJh6tJOLz60h8VJg5THJKnFm7oa+NsOlJJZ4E1koSqYsi2KMpBLk+h wXa1rVykO4mZFFpEIgWZc24mziklJEsYJ1pIbBRkRGoWsQz7DOP+TweFLIX0jMdCLog2uMg6oxGO ATDHILQZCZzUsi0GjWMJTDmgkhuPIrEDJ6TGAlK6omnrdU1dh4urJhZpKu4NWsxoOlOfHAeuu+eP v8MW7LB1ap14g637Tvu2WLfFNX/eLbfJ07Ihd0JupPuHbbPXfhszvoNtD74Xd1ux1bpd678mOmVx DHibkrRV4bp8yBhep1i5jObQOTL/Q3WetffXBE8S+Me/EfEy9L7i+wf8iJDJZW5kc3RyZWFtCmVu ZG9iago3OCAwIG9iago4NTAKZW5kb2JqCjgyIDAgb2JqCjw8L0xlbmd0aCA4MyAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1W227jNhB911fMmxPUVi3LzToF8uCNs8WizqWJdoGi 6QMtUTK3EqmQlGMD+fgOL3KkrFBg0VBIFA5HZ84ccoZ5gmkYwdQ8/p1Wwc/3H6BQwRR+w58ieAoi 6wD+lVbwMUGnhTEkeeC+i2ARwdn5DJIqOPnMNZWc6slKklzDwFitr+6G7DiWTdEoDbNpNDtNvgVx DMk6OMGFNeWF3rZuk3bOFMxPR8Fs1vpdk29CwlcqFRMc/dx85+ciB72lUImMVoB2KRokC7UUWqSi DBHKgjDeB7HzHwR5aOpaSO3ckWdm5cA/GM9YSjTNYHMARbVmvLCIPe6IEkVtVlrAKBqNgfDMefYI mtV4BI8nNCzCozUK48dTQ8aLeB7GAHcUmSaHmvZESxDyuILGr4Ym4XB7l3y+vVmunYnDRqDkunVe MZUKFOVgaPXo2uXbPMffFVWKFFSFw0Ea5WQwoF5HB2ZgnMKYXcF2FEiWMY2JkRKp5EJWxMyAKOPB NL4Q14WpTRgzxRAei4DS0ghtJMTAlO+YkQnD4+cb6pggbBccQ9WNrIWiLYzXGIMi2brRRhUCGVN1 SQ6QiqpCfCf7f8mbCq4J48rmnYuyFM+GW85omalffazpQH1EA7bZgC3u7Yep0BnEMIdf4Aw+wALO f8Tm+Pw0+Z+Pg3kx+VshLpKPK5y7Sr5wm4bzV6Ue3I71x4uHeWu22+33uKT85ZrsTZOAC1gMCfny fkl1NrpN7bVPYY5+O/sdrNvEsEO8nlifwuMJ0happniwK7JnVVO5Y3Wsr65EE7gRfHLTlCVgCVWM 2/bioMbt90YWH24x7Z2PgeFCh/AJK4LuSVWXdGyKCIHLkum2/VWs2GrTxDyzgWGb345IRjYltb3q 4QjiyZajTsGch3PswMtLWGaZxO7hkU0RGStxVqv19ZeHBEhdUyJtIWL6nCKjjZATIRnlVgVWYATV S9iX8Y13hi/1uDuB5eXvHcNKPPM3U+vhmXU+zDCzMawZ/wcut0QSFFEypVmq4J4+NVRp18ONh//6 rR8C40Yf01120u11jVYHdxt5sAwjmM231xR3XZVWApXmuF3hdyJeL/80vY8y9MTO61Hq7UHhDVWa y43Ajknd4KSDHcKVOxI2/KCLh3oWTZmZEASqpsQECd7uHQZjE8PQ3EhBsnb12Gyn+0+d8bavvmOH fIcWOZ9bsHuiS5bnQDWex7AT8GpfM0wZb3mZbiEem39y4u9o/XWHtyVEZ38j4lUS/IHPv4etmjpl bmRzdHJlYW0KZW5kb2JqCjgzIDAgb2JqCjk0NQplbmRvYmoKODcgMCBvYmoKPDwvTGVuZ3RoIDg4 IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVbfb9owEH7PX3FvAw1SEkp/TOoD HdWERFvWZZ2msQeXOInXYKexgSL1j985cSBu03XTcIQiX87ffXfn+8QD9FwPevox7/nCObg5hlg6 PfiEv9h5cLzCAcxrvoDzAJ1OtCGInPKcByceHJ36ECyc1pgrmnOquqOcRAoa1mhyMW2y4xou46VU 4Pc8vx38cvp9CCZOCz+87/7n037neF6F9hRMbiHYZBTOgvMR7ieUxyqBMzgqaDztGF0OP8IwDHMq 5c74hGj7YtWy49VXY+ymtU8+vl9VaVskXF3AQpkoplhQ2o+MtU62a+1EBCqhEFKpGCeKCQ6zFmVo yyFLNpLNSQoitzpkrxXL1ZKks7aLTuZSnLoDgPF0dVjFsbljwPrHIhkmgXC4ngbj66vhRJtcGEcg l1kmckXDDjCFzL8DyTJKbEKMwxVlcXIncviadeqbkCjaQeQQppRWBlhgVBJT6cK3hHJTJMbn6TKk oQVXeXaKMr1gPRdcEcbl9qvBInZ5uYFDJhLWNE31m2BydziMsCDyHlYkXVJMmRcHNFkDZVMuyvAi 6vN4ImexbicmUFoMlgEpwpgmz4mkZXI6H5JKsYPHhjAe4hUo7oWIDMo6ocVRlWDTdN8wvzXGBPrI 9DWKKzodbSwcQppSAwLEwGQ5XTGxlOkG7rlY8+qU+/ZlsQoQiTQVax02YjQN5QeD32sYRq/B5jfY +tb90irqQx8OYYAidAwncPovtpLPnvTob+QRS3UwykVW7q3qVXL0XNWa9uOy99jD7bF9JVEPZfNr XOj/pZyVSz0r+2TTLKmvampNVOtVRvOtHuDtvOBtfHNM/iCq1lRbLK1qdXfj8Yri6HgZiolrSFtl 7MLQ0qBZq9ft+7M2KAF3VCttylAPcVeTt1cp18Z3MCh8bohKWRQB4pPUrblePGYMfZFGPk+g39F/ KvovAH9MUavAO/6JiBeB8xmf35ntNZFlbmRzdHJlYW0KZW5kb2JqCjg4IDAgb2JqCjczMAplbmRv YmoKOTIgMCBvYmoKPDwvTGVuZ3RoIDkzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt Cnic7VZRT9swEH7Pr7i3US0tTcpKmcRDoWiq1kIHgWla9+Am19YjcYKdtiD1x++cOKWGIjYNaS9z hYIvznff3dn3+Q6aDQ+a+meeYeLsXx7CTDlN+ER/M+fO8YoFYB5hAicBLepoQzB1yu886HjQPvIh SJy9vshRCszrPcmmOewYvcHZaJedRncxW6gc/Kbn14KfTqsFwcDZO2q0AfqjZRu6USRRqdo7x/eL V/RNMEfrJdlvgCtgAi5GQf/ivDvQpgb0p6AWWZbKHCMXeA7D7jeYICwURoToeRUiF5AT6Dny2XyS SrjO3O1JxHJ0YYQoocdVmC5RPrjkLipt5QIC1FBDIsRmqBrwdY6CkMN4EWGkXWwQE7PGJa/Em75m xA4TCFORMy6UwcqrQJkJNJ0WNmGAKMKSuE1tw8zAVAFQAioHL0Knks+4YDkXM8gIQrswMMhpgYSQ KXSLtY+8WazSR2ymw454SCip0MCrOepPN1FRzLpcFMeKHALec1U4NFxcbSwWRBhjBcIgk7jk6ULF DwbpVqQr8fgVU7DCONZPRoWf0J6EhKnbxuu7x8rLNI3jdKUJTTnGkfpo3NHGfz68HTZ/h61lbbji DPnQggP4AG04hA4c/YnNMHpf/8ufwVnrHAQPGcJxcNKj+QDFLJ/DMXgdzXatT2oU7fdkmpVzK4Ow rnCeBL1r3i+3BpV4x/u3jmtHIYph039x/Ofzj/m8wmMNV+UxH9Ixf2M+Wx2jOhx61IFOiHFjTgmY F17H2LePCtlvWLzATUuktmL64cud0O4V9qga9nived/0xrWiWzJYUXeOJFuxuGiWwl7nj2t2F7QS W7enT1RG4xdSYKKzUl6H7narhWURK/mse35nXIM81YLLsizmJII0K4QnW7Z/I0TtcHMhOCRpZfc8 WSTQ07pzWUqu3defrSAmw94l8TBXBK38lhRvK71F6SXV31L88gow4OIWTudMspDuQbp+oYLu6ecn 9wEdu9kCWCQhMVzp/1SSyoVUuUJRZSnWAiY8V5T5SjcVkkpFWnoZCTlVWCc2nHNcUkxpeRGIiYy5 eSSYS02FSQSJ5SXIIC05KylU3GKiTSBsQkG6FrsNIxheXwXkkiAODookUX5jPp0ClZ7Fja3ynd1n nOpH1ZDhHFquvt21nhX5+4hc05n5QYhngfOFfr8AfgetXGVuZHN0cmVhbQplbmRvYmoKOTMgMCBv YmoKODg4CmVuZG9iago5NyAwIG9iago8PC9MZW5ndGggOTggMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJzlVt9v0zAQfs9fcW9sIi1N220t0h62ZiBEh0bJ4IHx4CaXxJA4me3sh7Q/ nnPqZitJJQYDHrioSn0+f3f33fnaSxj0PRiYx77D3HmxOIBEOQN4TZ/EuXS82gDsK8zhOCCjiVEE sbM658HEg/3pEILc2XkjNEqBuudLFmvoEH9+ctalJzmqkkppGA684W7w1RmNIJg7O7QhsSykxqi/ +8wZDtda8t0Wr0M37NCNCMrzHkB5ZDaCMezBPhzABKaP0RGYgXne+83H4twF848Q3JYIh8GxT+s5 ikSncEj+jNzd53HqL+BiZ1mqi92H6d09dURbSrbNf1v+ZETdQfy0x42uaqhvpEfKY9+C2UrAxvbE bp6yG55XOfhMM1gwjWbzCPbHvSXXUAnFE4ERiCpfonRNW0tUKDQXCegUN1uyS3LrgIwLiZqHLIPI OJPkzAUugBwpKFHaiDpFYViIaM2YS2hMQ8joMAILU45XFGQhjBfIuPhmrp29jNM+deCskpKivk9z k0A61bIgZzN/QeUx9HIFlSIXFO475Em6LCScl26z2ODhvIzq3M4QJfhchcUVylu7Xm/OKUqYpUyy kOYPV8SMggVeVqi0a6lglHKn3dHsLeSoFEtQgS4orIiIpZhN/oZYIHquUx6mFmnNi0kkXGWa3UJB rDNTShcoH76iL2QKoYjr78a5RdgWam0XoeKS6GkKCzEBNsWATykKi5OjluY8k9gMSbjirLZucmJL 4myFbcO9x1537vmHwJS/e9J2l9SUkhpJMy5UDR4XWVZcm2aOOWaRerluwv9nUJv1q4wl6nBwQz+S rcE9+3FS/bVB3fK8Tf59RL8cwZMN8nazP3aQj8d1HHQ243EMqIFl/QfOTm5KuuSKfjJkmMLINf96 Ri2KPp/RBQZv+oUQTwLnPT3fAZ+2NfBlbmRzdHJlYW0KZW5kb2JqCjk4IDAgb2JqCjY5NQplbmRv YmoKMTAyIDAgb2JqCjw8L0xlbmd0aCAxMDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJytVtty2zYQfedX7FvtKa3q4iR2Z/IgR07HUzlxHKadTtMHCFxSaEiQBkDZ6vjjuwuCCpVI qjMpZI+M5fLsBQdnfQfDwQiG/Anfsox+un0BuY2G8Av95tFdNPIOEL5kCRcJOZ2xIcmi9r0RnI3g +fkYkjI6utIOjUZ3MjMic7BjzeaXN7vstKZN3lgH4+FofJz8HU0mkMyjoz3OIBtjUDtIhRNghMMY lIaFchZqNGBRVjqNwS2FA2WPf4hGo6fgFWtYIAi5VLjCFCpNCAiF0p9iqAxvCGovSIpWGXptk9SO nNjEmHPCPIT1aimMkNRPZZ2SFm7xrkHqT4nWihwHcJUxjqEYFnR1MC2G0NIpKmeB7h5Rb/onKKNS PKiyKX3ah3C4Iht/3Xq4/vA+4b5ZdEBpigLcwYS4/n5QjzKgN8Khnw/OAS4faqT6U3hdmXthUqVz SFTJBzAed2eZENI+R/h4dPk6+XhMvr9xk+hHaHh7k1y9fTOdt4GVw3KwxQ5qq23qujKESJxycD39 g2trLPqze4MqXy6ICx/quL9JPQdvEE2ofKasrFZo1rFvMj8Jbt0ZWmoTQaZKspGb4tY1bQooyKDl OiB1Z8Yewhi1Io8qAwG5WpG5FvITNZ6I7iGM0LZUznEbUlwpiRw/QLGHQYm1J0PlKfQFQMWsAqSU w2Nm/wColQFDVuVCac6+DWUtYznqOPUrLTD8eS+Uz6HdZQbxn802IHFfiNVNZ+d+cMQUc3JvL69b VhaBSib2U/XcPKHphaxhlkFH2LYVWxmVmKrGn+4T+cI8oSvqhNLW55FVRVHd8/NMYZHanztSD3eQ erTDNt5hm2yLEUvoGCZwCs/gObyAMzj/FlvI6MeT7/wEnEfuQbKuEV4mFzPaz1HnbgkvKS6vx14h xAi6YqWlG9Zbj/93RvBfIZ8ccZsJXaG0Tmh7MQswoWIID06DmUN3i8xTmIxPSNqh0Vblmtikm3KB JqbrVRu0JJCe1cQiDHw7NISyz1QMF4n4q4pCtUODVLc3iraUkoYxzDdysc30YO8E8Jsk7HOqPSHr iVjsJ9i+MdVqXm/Gfek3ffXrfhkUZdXQgCH9CUIYqg9Ym3EcRqkUpBBBrA4n1QvUE8RuFHXBDLn7 Od7vOfy+RNYUZxiRhYgO2k+JgLRSokXrqhIL6lq8OYRuSHavbQvTd0vK6amHuhWuUFkGrOfFoH91 HmqqycK1MHIJk5j/0Zp8hfTnDaVOj/4ixMskekeffwEhXbtuZW5kc3RyZWFtCmVuZG9iagoxMDMg MCBvYmoKOTQ1CmVuZG9iagoxMDcgMCBvYmoKPDwvTGVuZ3RoIDEwOCAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nK1W32/TMBB+z19xb3QiLU0KZUPaw7YOhChojIwXxoObXFKz2Mls Z1ul/fGcU6dJt5QJhqMqin98/u7uu7tew3gUwNg+7h0L79X5W8i0N4YP9Mu8ay+oN4B7xQKOI9q0 byei1FufC2A/gOlBCJHwBh+lQSXRDGeKpQZ6xmx+etY3T+OoyiptIBwH4V70y5tMIJp7A7tibwlh Aq/hDUzhLezDwd/M7b3wgqABezl85kNoFuc+mn+HaFUiHEbHM/qeo8zMEg6JgR33jVlzZlDGK7gc CH2517H33iH9D0Zh2Ni3oUVjSJ/HM3eN4wduIWymHT03fQTBdLjgBiqpeSYxgRuWV+iDwlKhRmm4 zMAsEYxiUguuNS/klocfjARztqITzACDksVXaIBuLCqrFQ1MA93GdYNnDCaO2oNR3KCqb865vBrB RwlfkGfLRaHgovS7HwnZ5AOTO4DmdB5OlkyxmChwbXis4ejkk0/oRKQ22DIikwtFdIhjP1Btmg9c guB5zjXGhUz0CCIiGbM8rnJmyDtQpJA7N/MdUFyUOQpy7/pEgiXKhD5H8J5Mwjtm1/21+Q5KsFU/ 1gLJ06qS0oaKkddY1vIhc1JViBqJ1+nK8n6Y6worQiBPp4SX4A2PLYyUhWnRGja+jeLni2/RTkod b1LRseGzFHpjcY50tzb9UJ9RazJoK1gbceoaVLA7LirRxqcfqRs0n3xcYmz5FbJVGR10dehgRAon ZrqoVIx6O+do+2alzkBiVmnC4k+J9AxRbWXPjOvYKn21XuuqeadwQax9QtYXzlQuEx7b+FDOIdEi YZEILgfjYTAeUxliwiagVabaEL8c4IjCvWCUg6rRVlncoqIDCgXjtaKcfwrFMy5ZXQ9KYlrrRKBR lhRTbcB9h3TDWX2QLci+DWW/4zmrn65URk94mSJniNQ66GmR58WtZZNyzBP9rgn6+HHkqU88HuF2 FfvLpvOvxfzJdrKmattJa/wzmsc/NYvATXcZ1M2i1ZYPtbR6GsVGan/qEq28Nnr0QVfx0pYLp8i1 Fq3O+vO5VbKrUotu2aMUctWCRE9MG7XtwmolOJ3WpM+ZyXmaAvUvlo86e0/vSq6sfJkivhPf/oWZ PEL8cWYzMAx+EuJp5H2l5zdmVnhdZW5kc3RyZWFtCmVuZG9iagoxMDggMCBvYmoKODU5CmVuZG9i agoxMTIgMCBvYmoKPDwvTGVuZ3RoIDExMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nOVVS1PbMBC++1fsrTCN09ihPDrDAQjtMA1v00vpQZHXjootGUkOpcOP78qWAyEZBjrTU+VJ PLve/fa9uoVBP4KBe/ybl8GHiy3ITTCAL/TLg9sgagTAv3gJ+wkJbTtGkgWtXgTbEWzuxJCUwdqR tKgl2nCkWWZhxRmND89W8ens1XltLMSDKF5PfgbDISTjYG2nH8UAF1gwK2YIYyFv4LxmhbD36++C OG6ESDuZ4mopuF67GJ9fr5PgNxAGaoMpCAknKPLpRGm4qnpzgiCjqIO8qlJmsQdniBpGwnA1Q33v 6e4jk2lr7mDKNOMUvzBWcAN7B18JzeGUaAzL0YBVZDgVnBTBkr+33kOVNWThYJgBzgpeUyTk5+Te ffE4SotcSIpQ5lCRD304ygjcameOaQSNldJObSZYg8gm5PLcfg8oER7r+OoygcmjSv+VyXRJ5Epa JqRpTGSqKNSdcykTWKTmkzdArbF8ohW8eCHnTUfFMIQN+AibsAXbsPMSz1t7H77x8XoPLp7kvkLY TfZHRI9R5nYKu97Vh8UswEOn9yyIJfp58801/8bTJ4Xp3F04IX3YH3kDPgJYEom8wOrCksAeSCXD VJQojVCSFSDrcoK6B4MwGgx6i4VafaifNBqUTZPqzlLT2b7b+2Rnxooaqe27Xll9yOYjHnV4C+OH ZUoDi7QuOtSXoY5aJaoFTZeUyrref5wzGuM3+LRqdh631RDg0jJbm6WJatndHmISTs+So9OTvbFj 0TBbx3axuiVQMW1drEwupJ3xG6nuCkxzLJ2kn+0eZFqVgIKi1E2opUqxpJXREFrV1tXRKh/dwhoy NecE44QzJopaY2MYciqdpChva0r08oJ4Es7/tBGa/wPKbuvsP5rr8KWJDueznKAumytBydankNKw C5dtReleo4H+jVoR73Nb2j5cVshFJnjb8eY1U920g+yw7BOj3BlNsUK6BolsL6uNjQbvgtlCZBkg NXTRfwJ3+KsSNNVwzDSfwrDn7vzhktHvZ9TYEMc/CPEwCc7p+QNmHC9TZW5kc3RyZWFtCmVuZG9i agoxMTMgMCBvYmoKNzgxCmVuZG9iagoxMTcgMCBvYmoKPDwvTGVuZ3RoIDExOCAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1W227bRhB911fMW+1WknVxE7tAHhzIaA341ogJEFR9 WJFDcQNyl+YurajIx/csubxYUmoU7RIGreXszJkzZ4Z8osl4ShN3+XuYDc4+vKWNGUzoV/xtBk+D aWVA/hZm9D6A0YXbCOJBfW5KF1N6czmjIBuc3CjLhWI7WhQitnRkLW6vH4/tY12Vm9JYmk2ms9Pg y2A+p+B2cPIdYyydcyGs1IoKfirZWI5odcLjzZjuWW6StS7oYz48/WEwnb7iqrVf6K0aEttwdTrG QY/hcjw9J/qNRWHXLCxVaT6L9CxICjaJTiPYzmZNkCDhfzSG3SeShoSih8fg5uH+6tZtjekmfgHW lHmuC6Q1JGnp7uozrZkMK0tRWUi1oUdmQJYm1M9c7MhqkiqSobBMNmH4cl4iNrIANR0iKzPWpaUt rPXWhXXmlOmIM3gI0xJnqq32jPfV5FJnoPYADKszBVxj9+7jMiCW2ClIhCHntoepQSAbfy7VVALl etdhGRIqUvAXDquze9HG3tceCRkbIzYVfqQaaVLaNkm9zKnNxjs6mlPLKMrlqXQ8Q21inUqT9JKq Ez+raTSA4aS5BQMuU9RahFY+S7trs/dixSOpYqmk3acH2EqGEl2FjjmAhvoayfKUM8ijagrjfTnZ hInWpsLd2lDC0JCxMnQ+wqSmy8iNEqmpRHZWcMjymaMmPTZc18GFLxr1HCi/1QjQlQYlRViTcyjj HShEz0rt+hRMGw61iszqlGIUuq+1rgfumnKuTpbMtIQWHK2zuaPFheu6qmKrH7UpXcMqrJtmUGW2 Rg469mkYNL0AC9hw2SHaoUxWp96Rxz10MbYCrblmJMCN2nMclKHMhWtUDlNR+G7qC6R1Vcsk1cai zAp2SCAUhutmchoUaUoi0yXcNfB8QHFMeTjvo0aVW7fBX3OAcLQIx2Rboh87+uqB57wt62K5AQPR tbY1vUAw6fVEx6kjI5IGXdHw3THY9iRkBdN056Vf59gXTCUxfaQl2lZYsrUOmj1Se5ycVAJQEeO0 awqhqnFrqkb0vsTBwSqramJhwtYTp5tF6AOZS0A/1PqrUx5CsUKqmqhYp6neOvCx5DQyv3g8iH24 pkf2Zkf25i/fb+6FPKM5ndPP9Ibe0gVd/ps9j+in0X+8vJ9vjoNglzO9C94v8PuW1cYm9M6n960r vv/dK437/T/i6VWuAdWsEQGdD+URUu/hdP/t1z2aIJWFpvuHwE0dDFWvB0Pa93KO18nI6pG7v/Yp 4qcBvl+0Gv3FhYb3JuiQuok5dAOzEc/hSg4ab1+5PYrrPO4P5yH+P5R3i+C1VPZGYz2RqpHygpF2 AFr9/XzQk9V8hMX5eRXzg7CpjGN8qJFIxz3T66+5dOP2ThSY5vOh+5qcHzj84xGk4B3yJzxeB4Pf cf0NenIxr2VuZHN0cmVhbQplbmRvYmoKMTE4IDAgb2JqCjEwNjcKZW5kb2JqCjEyMiAwIG9iago8 PC9MZW5ndGggMTIzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnictVbfT9swEH7P X3FvA63tSMvPSTwARQytBVbCpmnswU0ujVliB9uBMfHH7+w4jELotAGOqqh35+8+n++79hJWeiGs 2Me/4yJ4N9mAmQ5W4IA+s+AyCF0A+FdcwG5EQZvWEKVBvS+EzRDWt/oQFcHSoTCoBJruULHUQMsa jvZP2uy0dqpZpQ30V8L+cnQRDAYQjYKlrV64BjDi4gfsZUyxmDJwbXisYWfvI0S8QLX8Juj3XTTB RBn+JZwiPwPXwAQcn0SHx0c7I2vqwWFKSGHYIOmqLKUymHSAGxjvfIUpgkZhIKkUFzM4QQIbch3L K1Q3YCRwkfCYGQSTIWFZlAQ1V5iAqIophcuUIGIpEm3jrxkhp1IBA4W6lEKjNTN3Ag/w8BwTvKxQ G0vXbpMVuWh3jPwKCTSjk9kDpkoW5C9kgkVDpY12x3JtYMZnpxEgJwtRimMsjfMaKhsFeJgrllfY AWmzXmBch8yDOnJ3VOglC25sJT0EL8ocCyolM5wO3ZTasjNP3Z8/N5x+OD4bDT1QnElJNWNU5pRV uanJ9f6nI+hSDONCOwapzHN5bfmkHPNEv/f5qOMfr7DF1p9rJSeUPgxgFdZgHTZgE7YW2Xy2t91/ fPy+W3ue6KZE2I52h/R9hGJmMtj2VG/BKZVqVZO9fUa+e3VuktrVBcrsYX128I7Qm+c4dOno2zCU cHQcQaXvek47ebRd33yB55eqe4X6TtRtWPf3O6cGEqDW1HY9OJKi+wuVhO3meudXw5AGgGhk27nT 7RSJGtq+0TxBJy3WjrOwnzOmCQoF5JJU/aeiNPnWSf00OyjXF5os8hpOSTCV9klsX7e5F8w3iF08 +RS2zzqY3jgBuEFdMtJkzEsmaMv50lTSLd6bFkwk7qur6vlyI26ziJebMM0c9bnupfEQ9ThzFW2g DhS574pWz8wZjTwBAvksm0r1WPVPsnhhrbfYBs/S/0Pb/+rz3+fDupsHMHZCmdS/Kk0BP9vZ6vwv zaelgIsZzK9X4LMw/S1MagU85X/t+ixO/6r1WV11TT1hJudpCmiA5b17ufZ/lvR/R8OYqTiDQcf+ oRs8YvTthM0Q+qvfCXE/Cj7R8xvTHLm2ZW5kc3RyZWFtCmVuZG9iagoxMjMgMCBvYmoKODMzCmVu ZG9iagoxMjcgMCBvYmoKPDwvTGVuZ3RoIDEyOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nNVWTXPTMBC9+1fsjXZwQpyUfnArtMN0SEsJLhwoB8VeO2JsyZXkljL8eFaynMSJm8IR ezJJ1vLbt2/fyr6D0TCCkT39d1IGr2ZHkOtgBO/pkwd3QeQWgP9KSngb06JjG4izoLkvguMIDk/G EJfB3oUwqASawZlimYGe42x6ft0Xp+O0zmttYDyKxvvxj2AygXga7NGF3wAzWRMyzDBBfo/wlYtU PsAXVtRI1/dfBFHUrn45eOak1eNxuzqefoH4scI+QgOI357RartuiiI3i37iA4gO/bJLmWL5BM0B nMLhwWDODdRC81xgCqIu56hCoIU8YYaLvFPL7sMsEJJaKRQGbvekIhRuOCtu9z0uyMzz2n0kClNu NLB7xgs2LxCkcOidcv4Kqil52NF4V/P+Q1G65fyjKt7VJ8PoCOCdSwHvFSOyM7yrUZuuOyld3yJn W07cBHy8ji8+Xp1ObWgIF9mKt8KObLquKqkMpqGrYhestuJlSpbA3MD6GiumDE94Ze8wEnJ3K1Hg gnKW2ETb9CQWg4em7rU6PFSTdj0dI8aQMsOAG/IcF4CceCpH9gp5vphTM28qkMpjrAXpPoQStWY5 6ibdvbMXtyw6pdqcCiuFNqv2UJtFzBFYmpIV6TcTj4A/ubY+fNIUHqet96aisK6ThChldUEJySuV FSuFSkkbtmgy62EXeixbt2o8puDy5nNM/zThppSFdiLW1guJFIaRywlwidYYziN9NszU2lVO9VDx ZAMHXzvhUmB5rjC3GjrVNGSkqn4UyUJJwX/RCErReqBWldQkcsenF2KrTZ5dCA8LFOumhBQ1V60N peI5F9tDXmFbtcaGrJ9jD+X7Swraa43u5BwnhpJF29jbPRzmw+29zAsUUv7+7Ym2C9d7j+OThyCk GPxCJZv8buA6jXIt7dFhaRDXuieHzw+pbgULt23gkfx0KPyBie+mdnos77znbIPL6bsP3kQaHZU1 qyWS9kxCWpnFibOpfiO72xts2A6sB/E2JDtxsb7D+O1+hbsUzWN2DZbIsirQkAlX81M89uiwHAfq 04b5PFQ7IF70TSXay2bBTMtePztC4Yq2nThrak+rnf7dO7jt8jKZ5Z3JopAPFivjWKT6TftEGfU8 SKKe2LgnNuk+Me1r2hgmcACv4RCO4BhO/iXmGT37ZvUXb14HB47UjJmCZxmQu1gxXCN+/rOizUHD JVPJAiahfR2cbJX37do2bvz6OyGex8EnOv8AQHYR4WVuZHN0cmVhbQplbmRvYmoKMTI4IDAgb2Jq CjkzOAplbmRvYmoKMTMyIDAgb2JqCjw8L0xlbmd0aCAxMzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJytVltP2zAUfs+vOG8Dre2alpWyiYdy0VStXFbC0DT24CZOMErs1HYKSP3x O3acXkbCEJujqo2P/Z3bd87pHLodH7rmcd9h5n2Y7kOivC58wU/izT3fHgD3FWZwFOChodkIYq+8 58PQh8FBD4LM2xlzTSWnun0iSayhZp1MTi/r9nGNiqRQGnpdv7cb3Hv9PgQTbwcFy2DyHYKnnMJh cHSC7xPKE30HhzC0F5cO4FjSiGkY81DSjPKV/uXuO8/3K7T37X98EG1nQ+sfq8mIZ2vpcP6zPY36 X60Pz/V6VbRWoa9WGzAHDsrlATaEQyeaUkXlgkYbohEM9toztK3giiUcZbzIZlSCpLnE41wznoC+ o1vpqlkkQg+Z4CSF0HqrQAuYUSDKAeMr4jips6hmPTAeiYcOXDEe0hVWSDgInj4ZxEQSpHQEsydn WAOSpCFlC/RFcCAOt2VtIHmespDM0kqBkzZj3e5QhjelvX42vQFR/pxOb253gSmIqGQmtLEU2ctm YVAjY1RsAawzHQjw5zOWnF1fBXB+ETRjhaRQ1OKUDpggC3Q5TsXDZ2BGBdoWCl4mpxlIhGEhVQtY lqdWOTHnVWmConojdX+NlUt0Rh5ZVmSwIGlBjQ2aMMMDZrJRsq4ZY15gWJh+6uAR13QOOv5wVUpT Oi+o0ttlsY6hE9tKwQAgeS4ug/HF+WhitjowjlfMIpKCKvJcSORUa4vmuh7wbPTD0NAUR5luRw3b RnMiNQtZjua3YMGIc5HAOWXJ3Qxpc51HRON1rAqStky0MJ7IRl0mMqKKoUmxI5jB44Z3wiFZwtSV G8ZVSMMscxVVENB4VMX2MuRShBSjj7WwZqeiWJyC23jYBAuJRZ8bumDVb1gMGZ4kSWUWhtRddUAR iwxRqyyjuy5uNyUtr5BPhTLRa1Xeln2F6Mr+KlDoe9k4kNmVuZU2W728MS+Gq7PKN0nvabhuE+tu gEmpScfo+GvlZOc1rHKeKosdixQLzngUM5pG6lNF7G4Ntf2avd52ezUTvAd92IOPMIB9HKkHL+29 dWhVQ6pxlJfmL1eDo2VjvGwYts/fbZVok0+D9Obh2jz8GgdfG7p1Qw/PG/LaLJnGgE1PYhnjXCm4 5RvhUcWjlemGD3t7Vv+U6JTFMaCEpJ0NX08fc6xa7JdEhnfQb5l/TP1naf55aWqoN/iFiKeB9w2f 3/K3kcJlbmRzdHJlYW0KZW5kb2JqCjEzMyAwIG9iago5MDUKZW5kb2JqCjEzNyAwIG9iago8PC9M ZW5ndGggMTM4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicvVbdU9swDH/PX6G3 tUfpmpbxsbs9wMp23GBjEHhZ92ASJfUuiTPboeOOP36Sk5T0g8KObcr1EsvyT7Is/dyfMOj7MOCn foeZ9/piDxLjDeAj/RLvp+c7A6hfYQZHARntsyKIvWqdD/s+7B4MIci8zkluUedot8daxBbWyPj0 +HydnuSwTEpjYTjwh93ghzcaQXDqdfxBv1p0rpVVoUrhDI0RCZruK284dDYNblbPgNAImIcqwggE DcFYLfMEVAzBXYHbp5gndrp9LdISYdIJTq8nXYLz/QYuVDktKUNr+hBMEWKpKTSyA5kTXNsbnF1d BnCDpL4VqYzcJIExjJFJLtIexxBhLHMKh9YbDK1UOfg+5Z5CslNJ8yosM8xt5Y9MVB6xwxqpcWJp 8iQiOxnLUDiYSFgB0mLWW+uEDrjG+KDSVM04D3aqDGHNFHuo0jUApSFT9MWqHmgsNBp25OzRuamB 2JkhpbBuqSgKrQothaVEEQpbVzuvNpOKO1Va3qloJ6fJn2So0rxdOE+KZ1X8NbrhGt1o4SxdkQ5h BDvwBnZhD/bh4E90dbhb2y98apz7qnouXYJ47IZ1UfN46XhXxnMcLmWuuZKXwX3qiprK+QC2nILL 1dlU4sa1kRvPgSadCiU4Gk+6rFEFu6LwuBZIdU89Us81YJPOfnv8APf38rRBLqigUMPJ+HGT/xrP GVFNtjGcfxDPpRXatdX8uNrs2qoTOsR+v//SuBb68zBNlzh30ql6nuvlBhOioJmkSnPkVnFpqdER gkZiCewRSy30KdNGPKeoCE2opduY4T2aAkNugrnDXgU9RRGhbvi28cOkIowhRo2IfYlJZ5ICzpVl DiVqS7mbMOrTuod7huil7kruFHc5LF4yhwaYoikkvldu1C1tQqwkYmHz2O5SFa9suM2dDqYhzuv5 XVKrHE0vkWQlHG3zsch8lVw3FDF+yGmdsFrePVcWlxEnVB/nSM04liaklOi7TUZf4nh+Wo8bwOH7 T5uMrgq6jfBpi6dwAtSZzMVqQh4124D4GWUyvVHs+2mL5+CM1YzD2tlx53khbCrjGJAu3bTdzMe/ CklXNZwJHU5h1ON/UCNYlm/nfL0M974T4nHgfaXnN+9xdKBlbmRzdHJlYW0KZW5kb2JqCjEzOCAw IG9iago4NDcKZW5kb2JqCjE0MiAwIG9iago8PC9MZW5ndGggMTQzIDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCniclVZhb9s2EP2uX3HflgCOFjnFmvWbG3udMbt2XTVAsQ4FTVEWV4lU SMqu//0eKdmOY7vbZCQOxHfv3rs7knmi2zihW//pvnkV/bx4TSsb3dI7/KyipygJAOq+eEVvU4Du /Ys0j9q4hO4T+uXXPqVVdDVWThgl3M3QsNzRmWc4Gc3PvcczaFaNddS/TfrX6d/R3R2lk+jqsJ6+ HbZ/vBdyVSy1oaHeKBo8/HH9U5Qk/4r+VGfMCWDPoX4XzLilYO7C+kSqb/RQMMM4LErrJLe0EE+N sP8rpFXb7we1SRLTXAgYkZbrtTBbmgpr2WqnMi3EBQBJS1YoR07TUqykIkZKbNr6Mms1l8xJreKj 2uz5ZnmO39WBy8CKNCLzfFxXdSmcIAd4ts9cG80REHfaxh5UQULIY2k6+Exy986HSkO+P0Y4BBei 2ZUAWjmzwnY8m0IYSHBeRYasppLK67hsvWCWnKwA0o2LadARXUAbwYVcA5wbXaFKNRotuaxZUMlC XlYawbItpHVckGfhiqafPqao7847WJBb5qAJ2dKgNhTgmboMEWLHtEsPnepQny4EJYNPtaMPpvd6 fYaO5MRVfBgiP+I6NAteKhRbcsKgM5RUVG1bYMA2dV1KsG6kK84Ut3c0J2iRNhnWMQ21rpsSGwfN yVlT7nOsWYnh7wHoUVJlknsUI+vd8V4nvdKZqG42MhMk1Foarbz/mMZ5R4Tqm0v6Tux3E9vzCCv2 DLs2NV2HfLxU0klWdjo7phxqWVliq7SHgiXsX7YspS0QuZYshAbNxyV+h5aosFgz/k04z1Sh4Jmw 3MglglEzK3joa5L0jiSkk0dKt7U4qnHQ1W7jsIv9zv06H40WX4fjjw+zx9HiM325alE4U75cxzRl Cp3VqAMYQ906W+0QlYwHHSA7CH1zZOPAMPQjMsaIBK43545QohsaZ+iWzH1v4eyIa5A7PyHIdGDd D17vxay3gxgkElNbms3T8ez9YHJ8PHlXINyGcdDmhfhZ7ZlQz/+oPZyFj8LYVvm51XYXt615sb6/ ESjcamjEjzBpYYQtdJmdgi7dA5TiDDOn+Cn7Lqumal0uTq4sD3lojPGn7A8gE7xVfHu6MPpeY0wx KL9ps2Emk2oVlJwiF8LqxvD95jlawpGALdGa+9CwUjqfq7u0k378/J45XGqvXoV1SC5lnhMmn5Xx M2aIwy2EYWGGF3TX8/8N3NHL58+5P2j793+BcZRGH/D5Bzr0j2plbmRzdHJlYW0KZW5kb2JqCjE0 MyAwIG9iago5MzQKZW5kb2JqCjE0NyAwIG9iago8PC9MZW5ndGggMTQ4IDAgUi9GaWx0ZXIgL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCnicjVZdc9o4FH3nV9zpS5MZSgNsP/eJNGQ3syTQ1O1MZ7OTEZaM 1dqSI8mh/Ps9koWDKWUXJoGxdI/OPffeIx7obDCkM/+On2nZe3n7hla2d0Z/4G/Ve+gNwwaKH2lJ 5wk2vfUPkqzXxA3p7ZBevxtRUvZOrpQTRgn34sKwzNGB18Vsujj0HK9Jvaqto9HZcHSafOuNx5TM eidYSHJBCyEMzbMM/6+FtWwlSFqyQjlabog1uBUzTqayYngqFRlhK62sIKeJnT7vDYdbxIB2IW2q H4XZbBEH9Bn7EZYKWbk+McXJ1mmK1awuqDLaf5Vq1SedBcQWq2FWNjh9cmAMGFlJT/D686ckkuG0 li4H352oyYe/IlQbn+qyKoTDUQGKt0yrnCEfnO7zHdC5Bpj/GgF2BLB0d2J0jXqEPErNRXl3Smtd F9yDKhKqWaRn0Mr6zLR6FoGsYw56TNQGCiyteKh9Ik+KRaaxAto0oj0KThDQ5dJucRrYRoKlQGLK Si4MNuJgYYw2jc4+zb3NEQIkS6lAByGWZLYVL4nPQ0RsiZxxBArV0hkAZDT6RSPFJFpyIRf0iudS K5kydCPjHJWzXnI87jSRNnLlCSB7rHZbqg8GK2Z4EWPXuUC42avmmm116sonmnYu68J1WdydJOcX qKI/UkGIyDKCxF17OesgujN16rp91+lWqaSTrEDUF3KbStAjK+o4Y66TNgTy7O4X0+nt/fzycnoL Ws3uQG4QZL7iEFNmoBcKxJljJJ0owwFte1QFS5G0bJKuWPpdOFLiB4Yv00Wh11j04402nC+Sq/nN ZEYXHuoqQm2BQgp+Zkoc2xxp66rSxtn3HTnmlV9Eol2Y9xFn5/WiKcIXYXxTdiTo7GqaEZIdgrha PP5Gk6Yuv1h/fWz9E5KpD678KTDrS8EcBdNFAY7vSnKckeuCH9o2k+o7fciZYSmwpEXbWe9LlMhS mCcBh+PBnnNtRy+i7k2Y37CdMhRX6XUhuLeN6LHBR3cCOiq3/en9IToiQoO3BmN7GUyttQ0B01oW 0ua+B9A/JnJqrPIIs/35/3n2d7qsO/WHBurYWRHoevLVT6Vj6Hz4YNvbTbmfpqWP0eBhhnATxKuI 2sQyJovaiOhNxBwiqpBBKwUIHtJqQJctSndsvL7oFq7pZp5sZyjA73PD1HORSRXmt7X7NMzeEL8q xg0vOAjXae0PuDttvOZ4GSJUbQE8v5l99flEFcTudXyw7L93m2mnjWJizPib+Rt4Ar4tvCwQW2yI G11VgqPlvPnE6/fne97fERgMgrL/12x3Ev0Pw+3MAMz3gOHee7Q9073GlPiu3HS99rn1Ke/bbbzk dgzXG+CrV+HYW+YKmWWEFVYMdnxi+qOSGAgcZdKcxn3/U21M+6+/F76Yo3f/AHGa9D7i/S/LfC7d ZW5kc3RyZWFtCmVuZG9iagoxNDggMCBvYmoKMTA2NAplbmRvYmoKMTUyIDAgb2JqCjw8L0xlbmd0 aCAxNTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1VmFv4kYQ/c6vGN2XEolw IUTX633jAm1Rk0ATp9KpVKeNPYZtba9vdx3Cv+8be01wICBAeGdn3ryZebs/6GI4ogt5h9847328 /5nWrndBv+Gz7v3ojWoDCj9xTl8jGH2WB1Haa/aN6POIPv1ySVHe688Lz7Zgfz61KvV04jW9mS1P PcdrUq0r5+nyYnR5Fv3bG48puun1sXCrikR5Y3c0VV7R3HOOpb/cl7OfeqNRa/X6Oqd5woXXqY6V 16aA2VuDB6985bBwednuvzOeyW+UxxdbJoXP3YIWy2i+uJvcUCKxdRubXMmxTjmh1Fjs0K4DJmfn 1JqHrxFGV0NaMlt6LOGJ6baxCNiiDXdWw37SjlTxiiE8HpBDfvS0I9UQWmJrJ743pItE8mfKTKwy ulE7uB+TShILLxRvVLFmNyDAlxRy9lbH7WMyBamALTcJ5+dbnTA9KafdkH6FPb+ovMwABQ61sEwm Fazz5fPVPghggMzgx5oK3UFbU2UJldbkpQf+U1kLeo/MvVfxBhRLjodgAGGSOYPYzf+mbC102Xqr XnRe5U3D3ItvyVFlWXCTsPO6qLsDxpNvZDnNOPaHnuhZqzcAbzsAg689zCbBVd+tzoad1ro2RYy5 0MX6bRmkADoVkkImKHisSvWUMfjslLQqErbOYxbED34kpa2y9V9pQFQcT/I6KVr1BT1YLq1mr+yu 5Y8lOe1ygBzUcdtaVU2K3fIUOzCTy2TUfdawH1yt+vLsnAtBm4Q1gABnYU+BR6uzmi3nKoSiD3es 15sn0zL6YQ9rTywwaRuatmHU0Vb7TQ224C3iYnvCGXtO4H3P5DD4um2A1JVMDECgqlbF/x1zTw+/ Lx5vpuR0hnnKdlQq61i4Da70ujCW68gn2mDYCfVOjBbU40NEMCjMFmStj33WKXa7bXL9x6GQiJv7 QIjlmPVz3QjHXt6MchO6LJHf6zAKkcEOnGMw8KSpjAPBB/VzQnEcA4aWppSu2ndri+qhKktjvcDR Igo52AyzJSqaWq4ry1gzO9pwZTXGLxZ9aLUBUFThcu1PCQLmXQQSolc3O4TmRDVapmXQ3xG7tt4x K5R5u2HpVdai91J6QNKlKvy+v4NiiTpKumAiQdPZXBfs9kcFmXp/N3E0HkzuFlHw5RqGjoDVTYOc unoxT0NtGv5kc6YxYvsxOCWaqz4P18NW+TrSsVfBMPOOO/5jFArqbhEBVXriA8UfHAxDfSymMg91 R8FOBVxHHQQREJiHgoSjo+095ZyJNeAcZNRQ/bERQSfdZoouKZGpgXpbxe+cG4MQFMcRtAOnNPld iZZVWVWfpI7920NSFOz7cja7//64nE6imehmbR59nULF67brXia69wDSbduVmYqRUMi8RFnZg5EX P0BHZpnZYlEObCjq/jjvXme66S5KiYY8ju883cuMXHfkzJ00LfXOnaix+nRgdbR+dGaeMrqurJW7 x6HR1VUdD/8ynaaEvFU2PNg1eym1FSFSNt7QeCBXvPHR9e/vpXTx+OIfeJxFvT/x/h8spUwhZW5k c3RyZWFtCmVuZG9iagoxNTMgMCBvYmoKMTE1NQplbmRvYmoKMTU3IDAgb2JqCjw8L0xlbmd0aCAx NTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1Vl1v20YQfOevWOSlNmDLppTm 602p1EKobCsKnZekME68pXQNyWPujlb07zt3JGWpYj5QoBIEAce92dnZ2ZW+0PUgpmv/br/TIrpa vqS1ja7pD3zW0ZcoDgHUfqUFvU0Q9MofJFnU3IvpVUwvXg8pKaKzWenYlOwuJ0Zkjnpek/l00XeO 17he19bR8Doenid/R6MRJfPo7DjmkubCcZnuzn+J4rg3YPq14tSxpN+12QojVbmmRBWMGyexS7a6 Ninb/oe5cOqRaa7Kz/SuFrlyPu9wGPLGvw5owWzovpLgROPf/qQbtlasu1TJhk8iiiaClCVR0t0i md3djufd8QUOpX9muXS0Oq5SFVXOBR6AlS4RU1eVNs7XNxc7pBmRkNIAiZwR6Wf/AHBX2lChJReX WyU7agU7o1IEalKlVKmnt92w2wBGHJFuS6Kt8BlTaGWzOs93LVBltD9iOXhSxpeuKQVHZ+rU/Qvw QIULQkIQUE6JHFc/kNtVTI8ir71CR9Vbdp6t98/DYjpdPtwvJuNk+uDhPp01V5K3k0/ng6D7TEIo lfnKIBYhsyDluOhag1yQucpFCqeoMhCpIBqylPzVXVCm81xv8XC1g4q7p1bhqvXhLdJxV7qm2DdH ctxV/iFqnHgeM/AIMG9ObHdJ7wFUBz/GL1qDJWwKVTb433BYT8iBjdCBMHeVgF1SVQmcottlW8aT yEbXGOCrYBdcttbjlcwyOGXF5No86DfNjv3YUjKcsnoM3jul1rn/5v594snJviB0dO/SJtwFN2XK FKFP7iC49V/TdI8IMJ21sJ1KPQwgTmY4QEvOVIkTZ2nDtVHW+cmAJ/jRy+fRWiCHNQKFmmRNoYfp ersQSjWcs7BMIs/3MrWbx59pP38SljOhvr4uNJshgHGumh60UABAj9R6s9LGdl5WJdCKhsoqpA6j q1Y55kuJkzzdOAtlwK0CPdTeuN8FZQOLAS3DnUCm5ef8UBci3UBEVGN4X6Gr8VsgvcQe4plUNtUQ bPesuTSgW023LXGa6O2+O4cwnsePd0tPi7+3XI73qj1dLsl0eTO7HfuR/8nt0q2Ddrb/63aZPEHt 10RTyP+3Z1727Jnv/Jr1udyH9+wbH47y4aYKHTuWHXqLbojkKbI2GGX4zQdUrn/IgPf8ecBbCper LCMILPLBQaH4N6CQnm6ESTc0uvB/L0Ynfz0+LnwRo/gvIE6T6B3e/wBnBM2cZW5kc3RyZWFtCmVu ZG9iagoxNTggMCBvYmoKOTIxCmVuZG9iagoxNjIgMCBvYmoKPDwvTGVuZ3RoIDE2MyAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJ1WTXPbNhC981fsrfKMQluSJ3Vyk20l1VSyVZVJ DnXGA5FLEjUJ0AAoWf++C/DDpMqmSajxaAws3u6+t3jUM1z4E7iwn/o7zL3z7a+QaO8CPtJf4j17 ExcA9VeYw3VAQVd2IYi96twEribw9t0UgtwbLYVBJdC8uVUsNjDw3K4Wm6F1euZlUmoD04vJ9Cz4 25vNIFh5I7tx8zvkqDVLEEKZFxka1GBSBINMRfIgQMbufyVLKuA8lxHmoOkIl8I/+8WbThusQBKE 0EaVoQEGG0QFAaqcC2YouJtr7CC54IazjM5/BnMskNAmkwZtz7KSQjTlMmCk6+5xs1hsH4PFdr28 mwfL+7tHi/kwqmKD69uHMx+C1AJZiGWEwvCYh1X+iBkG3FD5NiEhFxkLMaIyXDUFC58olcAXM4ZY Zpk8YFQj7Y7AxBHuNzbpfGUBKpa4pSynNFUKXRaFVEa/7xFzX9hNavTWVrCsK3BBo55Mb+BPAiq1 3Zhc+XCHPEl3UsGnAtYVc/WZeaV2wZThIS+YMMSTiKqiuscacYlBhbY2imBWHoGHHt8RatMolTIN O0SijMYhNBj5lLCLammvC7JEKnwuuWrZMm4QYq5yyqMwRL4nmjvnT+HaCWSC8tpOTA2FnBpSln/b mBu+scXnIrKyYqcbypRLWhEU1HZQwzR9jEG2YNVAn6LRHCikAkK0g18BZzKh7azFeiXqYYR+4o8p bl1mpASjS5YQcPFwBvjCtdHNdNHNPUj1dHJjUtdsRB3Wt2xAcUtwrNBJGGHMBa0Yy7lRx56CKZaK UvLQJcU9sVj1YHiO1KwPX1LSlA1Sz3XdXqsXExHNcxhSQFxm2dEOm7YUOvKqKAU6lWVGwVEET0Ie MozaGa1bsgx2ObN8O15iqfJqacc0WUKtAhdJpappL3L3OLHBXFF8lyHsOXudjPNKUiqUq29a0wAB w47Uc6Ee2Y0j3S2WH3+7vt8+ftoMGNH/WVDd33cYUTO16/kNzKOIZlRbjHGN0OOuimJ1VOPfndtB nZ/Ma9c2Tzzt4AQ2dnRcnc4Ja6OjulpP7JtbWxcR9drUT/oiGeNys79sGu8JcRr1thP1r/01e+F5 mVcJt3Tjh4JuSqXs3flm0IrWRXgc2lq8FM5s4INUB3qJWlECuoJDsVvUslQ0zsObGUmwR1hx8QQf WGikGiyYrJcb+EJDIA+vr5Ca6Mk7/7+8+0dfJl3b79gmwVxeulzEVsbjGGh8WeZ3iiRO6AWhSQAV pjAb258iMzh9/tpY5Nn0KyEuAu8P+vwDFZ/KrGVuZHN0cmVhbQplbmRvYmoKMTYzIDAgb2JqCjk3 MQplbmRvYmoKMTY3IDAgb2JqCjw8L0xlbmd0aCAxNjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJzFVttuGzcQfd+vmLfKgK3qgrRp3mTLSIVakuusGwRxYFC7syu2XHJDcqXo7zu8 SNpV5DZBHypBEMQdHp6Zc2aozzDoD2Hg3vE7q5IfH36G0iQDeEufMvmcDH0AxK+sguuUgl67hbRI wr4hvB7CT7+MIK2S3kxa1BLt1VSzwsKZ1/Tu9v7cOr0mTdkYC6PBcHSR/pmMx5DeJT16sF2jXaMG Bgvk5XqlNDzWMEdjWImwZQZMk2X0s2iE2EGtlfuBef/ih2Q02qOkCjIljdVNZk+gJje/QRXgLoGO Ai655UzQ1j/A7mqEDRMNLRtCHA73iAYtWOVTel7czt7+er18eH68f3ZwT72wJb2ePl30ISXQWY7S 8oJnzHIlIWeWAbdYEabnR2dxA7VgGebEwBOpWfYXnSLxi72EQgmhtvRwtfMP55MbmOS5JuZu92UE oiwtowxkeYhiMUoVfsmLIGMBAjle1QIrIujJRaStakTudshAC5jcUa3rWmlLNJb36Wy5mNzB1KUy o1QcDUPcqSq0K6KEHN50xFjW7hiqcHfrm059W68ruNGYcwvvuczVFt4Rz8YcIUeD/lHRqdrKvT0i h0nIuUaykUGZG1+H7o7oACepRpeiM54E1uGUo7FcBgWfeowiK2URpMoRlLNo1QhLEpORS62a+unC iSoVCCVL1JGORpat2UpgKP55HvPHd+leTFgpu27V9CUveR+QTDkxadujE9CHpeuno+8MUA8Jbpyo TONB2IA0n3yAFVmRgOhQ4AWtnvdLtIYvbtWnoncTc30xbydHqB4y+PlQm4zX3C2TW9nLGlFlCq4r 2smsV1OjwA2TNuL4lNeU2ApJRafThtIrtKpiixdKV6F8K2aiEs4bZJHQJxHoPANStdDomeRYcEkr lLhGq3ewxkZTNXnmegFwgwdSPiXLK1SN/bbx1D70Pw+n6fL94txoMryUEdHldZwzkbY7tiIvMKso vY6ZTLexfa923Xna01cdZ05PxqAPCO3dGZHHIxau4faqk1udYxfL4zTq0qNsNAVSWrGIruy90fB0 XrTMeTIzmCYleU3OenF0tJ1NRacZ5XLHTubHW4wcjtyZ8ezE+pcLzXd/8UJAMEjHxIGb67Y12+C+ DyIQEwJIKs3R7G+c074Ila5R+zEUBjuhFFR5mR2AjpfJxMCWh1n1Dyb+WrYIdHKVhNbKo4jnyt5S 9X9opu+462OCe2N++13vGuzVK0/lgVnBiwIojIl+6368/VJzaieYM52tYXzp/kWNv/qH9fHe+Ws8 /kSIt2nyO73/Bps4GQ9lbmRzdHJlYW0KZW5kb2JqCjE2OCAwIG9iago5NzQKZW5kb2JqCjE3MiAw IG9iago8PC9MZW5ndGggMTczIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicfVXb cuI4EH3nK7rmZZOqDBsgNTu7bySwCVWEMMSZeVi2poTdNtqxJUeSk/D3e+QLYCAxlSJYR3053X36 mS67Pbr0n/o7zDq/L/6gxHYu6RZ/See50ysBVH+FGV0HAH31L4K4U93r0dceffmzT0HWOZsox0ax +zwyInZ04hlNx/NT7/EMi6SwjvqXvf558F9nMKBg2jmrzj7T/fCGhlFk2FoaCSdIOs7Of+v0ei3Y oxOusBTtIfr9EtHvd2nGMlmvtKGnHAime1gTCQPkDQyr6HJhnAxlLpQjyyqy5NZ8dDWrrtLrmhU8 UcSOQ2dbEVmdMYVroYCTqjQjVaxNJpzUilbCMuEnCUrkC8yoxsfyzHCm4UXpqIkOr7MiRWQCJCVG F/nyvEuP3gW/iSxP2ZKOa3c+ZuHoVRdpRLnRWe5I1Ibey0QY/mtHFzWM3mzjT6X6BbQzMrQIkbtJ 96KqxQJ27PL8sBy4PRUbNjQgUZVOqqQhZHnmU5c+8IyVKympw7ZFnmvjQGtpc9cJgaYQKGeKEPm8 l8lFzbR0UqS4+p3cJmd6EWmB1wclYkdOl4X/ORtPbu+uHxY/n+ajYTBGhNWV4Hrkqf5bp6l+9Rl4 81YmqrYO4mpq/UEmFILRZlNRM0ETepRtczuJkLOMUc2yFVrQVoD7fb/t6hq1MzeMMXiUpyJs4tuF 0bplwQvy9YhchL/YlWS1PLZL0vQQTKNF1KYpDkf0MA8mD7Ph9MBDtyZjrlHvVcrv4ZqGaw06bTtn Mn+5ajI/aqx91Jc91NH5vXiTWZHt2vQU6KYwBvl+DJrivQo3p44WbHVhQj4ZwYJTEPnCNPXj860Q qXQnrdwYjiAkP6SK9GstZB/gbg0E6oPzBT8XbN2eAA66dMcQtxVjxg6l7+gEk+Llz9Fqg1E7UkZ+ YfTWDBBMZGQvWiWCKBpIpjcRcSwVmqXWv087P+WywIR9olgyWgzi5RGRtKH2xuvQ6qGGeHtBLPXh UDR0Jp1rGv/YQW2I4xgKjUqkm2rsS5GoIF4DhPLq7GWj1opyNAxDpvCvVNsZ15BtqDBbD0CK21VQ TsrsIaAVl9R1WzMarHdai1uFBSvgdo9U68OoFkm1V2rerVdOrVoU+2uK/apg6cOshh7rIvObwv/A ikByy3PvTGlKNVTXQD+zrFCl7qhkO6r7MTzePTxNRyS82lUrzLOUGLCkimwFG6jUestyQ6Hv1aur MjyMUCrjmECySLt7zTl+yyUmFVNpwjUNLvyyH9Dh88/cUzS4+hcWx0HnGz7/AwBNjZZlbmRzdHJl YW0KZW5kb2JqCjE3MyAwIG9iago5NjcKZW5kb2JqCjE3NyAwIG9iago8PC9MZW5ndGggMTc4IDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniclVZhc+I2EP3Or9hvDTPEF0h6vfYbIfTC HCE56mnnpnQywl6DGttyJPk4/n2fZDngXHKTmmHMWN6n3fd2n3iks2hIZ+4T7knRe7f8hTamd0Yf 8d30HntD/wKFW1LQZYyXPrgHcdZr4ob0YUjvfx1RXPROZqVlXbI9vdIis/TCdTWf3r30HNe43tTG 0uhsOOrH//bOzyme906wsDpJORN1buli1SeriL9VUjPtpN1Sqchis0wmpEqyWyatamTxrlApF2TY GKnK/k+94bDFW3OmEC5LaaWwstw0WYVXCcGFLLGA35VWCae1ZhMBYjRqIWJFiSqN1XViSdA1C23X LCwVABEbHvhMmh1yBP1Jdl8xfRV5jccGe9lOSijK5XB/N50u76+n42V8OR3HqLyJiC+vVv2IYmAa uSkDJHAyledqxymt925HYDq0QpSpsErvCTdB0oIIBJjfOjXgOqVZyqWVYM/XG+IXyjLgUA4wwZTA d3FLt3fx7HYxnj9DRRIaLyKbULyjKqg3uohoLssHmmyFFgmolcbKxNCSH2uG2jdNSJdclPmWIEeA KA9pPXGP8jvsesJLG0gKDeI41wGwrZWapgmdwZRsRblhX2GgxlScOLrcUic3lXmAHHlH9IcsE272 CjuEOGCJgFSy3GzXSg/AJCWoQ3MGsl0gS8c7+kozpE4R3/bj6oSjTTTwSwVUarGQ9qo/IOWCcrWB nK/FFZgjLCOlo/VVPwC5kZLNGGGMd0o/RP9PmqCBmw4rZGkOtUxqjeq6bX/lGmnpmF6dTK6WmG4/ KgdhBKUy87Tgd6Fq3ED0GgLvZIrph3Bt0+6chlA6afbJ9yQwG+hrTl3dc/wok/3zDRrlGwMJQCnn Yt+aidMT9Fp4TsKYM/es1TJt5tnTvlZ2G9HYkxNwnlM0nnw67lyXAVwsddkkqqhytp2WiQLMzC0V qMgrZfwwZprZxcEXZemjpEacxcRvuW43hJD8lT1lAUuQlQWj/SOaGVM76xM/1tN77O1i/sWndjOe BKRxmsIUTetD6Ct2wyJNgd8VQ/Gb8ReqDR+TXSBDBw5bk+LIr17MAHShHzKtMI/WUAWHLVn/0Ibf 0pnfOXPXh5+79JMzL6azj9eXt8v7+Wzx6X5yPV7eL6efnzl0qOd378qOXdt1bKedt5kng/YTMHvZ oLve3H21kzVkeRKk480duHHmXK/KRdJm9to5AXpQtnujEskD20HQ6shRO01JO1XnqYfGYVHuydRV pTQm77Uzo2XqTuHMXef86tkCxrqkBBs5sg6cYjTLcFSzM/lBcxQ1qmgOT42vZjH9C4J5Lz+U8vJV l433wztk1nFygEMXTD+68+BpryMdEsU8rn0rQwbDaNwU2awr0zTOocTWqo6uN5dYiG+yqIs3VAj7 9/aTh93aI0LaZqBheqdWnTa+B7yLC4+HSnJYMmE0RB4d4U39nzJDN0InWzofuD9y59/t+veds7/z n/8B4jTufcbnP6qGPw1lbmRzdHJlYW0KZW5kb2JqCjE3OCAwIG9iagoxMTIzCmVuZG9iagoxODIg MCBvYmoKPDwvTGVuZ3RoIDE4MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1W UXPiNhB+51fsW2GGowGuuWvfCNALc4SkxNc+lE5GyGuixpYcSW7Cv++uLAeckJszkyGRV5++/fbb VR7hbDCEM/7Eb1l0fl5/gp3rnMEX+tl1HjvDEADxSxZwkVDQZ15Isk69bwifh3D+6wiSotNdaI9W o/8wsyLzcOKZLec3p9bpmVS7ynkYnQ1HveTfzngMybLTfScY4D+RV7jpgdJQqDxXDqXRqQOjwd8j 5Eo/DHo/dUajADP6ZQBLWoLpvbBCEk3lvJIOJtOvcIXOiR1SNB+X0O7l4p3Qog4F5UBouL5JFter ybJZ7tNiSu8IaThs6DvUHrZ7KEyKhQNXlaWxXukdKA/eBLbWVHQO5OjDi6OlB22eIjFedZWUdBYY C5lQeWURTAYCLD5W6DymIO+FZoI6SMB/HicxiFh1lu8J0mR5e3n9bTkDEtYLAhT0W1ESSeKBPiLR 8QV6qySkwgvKCQvK/E83gIWHq2+3ycv2wF8UyK/B70skDR2vRqSYwyBwC+V1ELedPKF5yWlEiO8l E7hYzHKU/sUir/WJOORe0j6UoSYF90R1i6ihtIYrgOmRu1hPw3k6bytCF6elXUesI1b9cIjSyiuR t2zTiFQrwYYjzdkv3EJ3q/niy+XF9fpuuVh9vZteTtZ3jLrp1tHJxWzTa2r9u8lz89T4yqmdFnmA F+SeoC65Vnhj9zBjgReNwL+1MlykZGSVKSm8oiZrhbaYX02mMElTyz5tVawFNwkSl7mQDbMDjTd1 jm1SCvmAvh89czhRsSsLoldTezJVngZopIbcNy1HzfHSsK+8GpW6Mc6pbY7vxbFibVGmlbXc30GN taDOgA8kVUY2QW585kqlq6tiMa66Y2th2srl9BN4WMYn028VIZSkXj3zqOrb0tX1PjBbUrCW+2OQ H2a2mv/1A5wK8ayKqoA8nrTp0lSqdD2A0j6o7DjNZvCcfIgIuUthuun1AZ+ZDHXY69nej8P9u1DN 4I/3x+h8AHCLsrLK72FKLapStMEnrt3A7C9rvJEmh9TQ7NHGH0Yf2ahATk05GuKZCeLXoJsuDnaD lmCiIprULbFXKJoUsvuS/6JCtQ8TzlU0Digz4Wu/RuSYZ23nLR5sXkvD4laassn3oYWs0I59ToSY Hz4Lju/z3VM5PIzrWbK8ZUrO0Cw2hGIPqbH+9R3G8DQtDd8wlWfV6vEhTXmEFTyUGlkxreP79hPJ vpisJm8lr8UO80wGdVyJkuYKKRCt4njM8ebQlwQ1BJqdO5qip1Dq3VHpFDOlMUyujx8DE2rKXGUZ 0PAU+eDIKPPnUpHP4EpYeQ/jPv/nMX5jp79v+O4Yn/9DiPOk8wd9/gf3nck3ZW5kc3RyZWFtCmVu ZG9iagoxODMgMCBvYmoKMTAxOAplbmRvYmoKMTg3IDAgb2JqCjw8L0xlbmd0aCAxODggMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVNty2jAQffdX7FvDTEKxmSFp3mhg0kyTlFI3 L00fhL02amTJSDKEv+9K5mYC9GKPxzPayznaPbsz6LRD6Lh39U+K4P34EnITdOCWvjyYBaF3gNUv KeBjTE5X7iDOgjouhKsQeh8iiIvg7E5a1BLtxUCzzMKBZ3A/HB06p6df5ZWxEHXCqBX/CrpdiO+D MzIosoHEBWgsleFW6SVkSte5DM8lE+YcFtxOIeOZRZQwZ6JCA0mlNUorlq13QRiu8zHjgjBt02kU 7aCM0aCeM8uVBJWBrIoJai5zMCVL0GMOX0s6KigpEw0CLtkfyQ6YZXBnsVjzRZ5Pdwg3aG7I/zdh LsFOcQd1j1QDDndvlroQ7kLeYPYpyYy4Wn8tJoRKNgQYLFCIixepFhJKpe3m6s2bqaKoJK/j/hGg qISlSLKyNNVozGGIlJtEzVEvXfqVlKLLdgR1By2Vbs5xcQ1DV/k6/23FUxRc+j5sKT0qB8WdC1Um 3zh5YKyzaZ8NmEZgkvjxktm6X1vsLsA3rxV4Pnsg4izH5xYZnyBelkiEcm6s9lQa+G/kVLgxmSAk Gh1KrSTX6JXqqU6+7Xvq3BbniQmerk2O9HUDEOo+wAiRKrsuZCNDw+VLlqFeyf+tAfo3nw8Zv5ck MjxuORYXoy64XJfplPlAhkc3cBPlMI5bTsUNSNmnbKcxD9z4EzJtJ9TIvfN7Ll/gZso0S2inkjJ4 YkgjfjD+xrXmsW3qnQVOvRZGrceLlGOnzHqt7KgrUbQBaHNsdt7xLVErCCzJ1yus1/NuY2YFzzJA mlHR3tnwNHqcRhYemE6m0D13u74L+8+PEU0GdC9/UsZhHHyl9zebH+hLZW5kc3RyZWFtCmVuZG9i agoxODggMCBvYmoKNjQyCmVuZG9iagoxOTIgMCBvYmoKPDwvTGVuZ3RoIDE5MyAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1UTW/bMAy9+1fwthZY0zju1wbs4CVpFywZUs9oD8MO iswkWmXJleSk+fejbKet3RTYYQoCA+Qj+UQ98hH6vRD6/td8eR6cJpewskEfbui/Ch6DsAJA8+E5 fE0JdOUN6TKo40K4CuHi0wDSPDiaKIdGoTsZGbZ0cOCMpuP5ITuduFyV1sGgHw6O0z9BFEE6DY4G l72zJmzEHIOJwxwSXAnrDHNCK3v8IRgMKqxPAgq3YLDQVjhtdrDUphNtIfd1FgjcIHOY9eCOSZFV CEoWhvtkNZoZ/Nyq4Y/27gyVE0vBKx6tyD2kqnyHxtaA1645ooF0V2DHPouHEGeZQWs7nsl8c/a+ 6+Id14w9ibzM6/sndN+Of1gaQ/d41z8lk+K7jnX8VCCn3sG1NltmMqFWkIq8G5yg1aXh2CWVoKSm bRCmQj3AbUn9d90SPx1zZTfwGzLjFvRsUGltw+RpuqZbr7XMusR96uGaGUZEDelFcAvx8HvF03S7 YDATDu6FyvT2cOkGcmOYcoddCT6WaF1LLBMHgjQkrSZVVm5qmlvTBdwayVQJeUcAqWsdAdfKMaHA Foyj129LWUiNN3QBwkjI/JsJr9LeS1GamPNGefco5cmD0lsFc232rGtKHTaT+Ee8Z4HAYPsSWlAo qDJfkGD349TixHWel6qZgzaTi4bJrJTUf0Zz11bpP3HJn4NZHXyYRiYs1xukbuaEYSt83ZWo34O4 KFBl4gli72gWTOQ3YD2NU9yghFkdDNdSbyuaHuExM53R7hnhRtC7kLIdSdHCaF+19eyJLkl0cODU WeC5zAgtN6J4s0K+/IdDCc/Pq4Q02FIsl4DUQ9l7RYcGWVBLaU0Yvoboo9+/0RvSv+aeanT1mzKO 0+CWfn8BEK6vPWVuZHN0cmVhbQplbmRvYmoKMTkzIDAgb2JqCjY3MQplbmRvYmoKMTk3IDAgb2Jq Cjw8L0xlbmd0aCAxOTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdVV1v00AQ fL9fsW+0UuzGdqGtRJFAiRBSS9Ng8QDi4Xpeu4f81bt1gf569mI7cZRUCaXigbGik3x7452ZW+UO xn4AY/d0qyrE0fwEMivG8J5/mbgTwaIAukUV8C7molP3Ik5Fey6A0wBenYUQF+LgQ0loSiRvYmRK sAWTi+ls23vG2yZrLEE4DsLD+LuIIogvxAFvvPZazBANTLRV1T2aX14Pd/aySrAAXWrSktBC0lcd vlhQwLJ6QXKVpmi8Fd5wxbxquHlIkFCRBQm1qW5yLEZgsUwsEwVB3xHjxxF8rErvAU0Fn0hSY3nz 80rN6jtcOijQZaKVJF1mfWu7QbcIaExlfD4ThoMudqH1RSqFNWtKpc4bgyMwaEka2hC1C0tbnTkK rV1v6C+DWiW+f1ydtC6kgetbpHFkXx6Ly21uTQlsozaV7oGlflBVUed8rRLHcXy84Ih47vyw92OC 91ohL+3dG9ydWBfIStc+3kl/NG5euWGZOUKrjK5JV+WaH+fPgGdLnrN70mWUkDXSJEBs0VMnY8AA +LPWPBh+u/Wn3fQjtWtG9rDqnzr1/05a8LIdtbmkXKcpIIHM/cG5aRs4XEqjbiEaub+eaIP968xN UnT2jSmnsbjm5ze3WMYxZW5kc3RyZWFtCmVuZG9iagoxOTggMCBvYmoKNDgwCmVuZG9iagoyMDIg MCBvYmoKPDwvTGVuZ3RoIDIwMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nN1V 32+bMBB+56+4t7VSQgO0ayd1kzYl2ialW5agvUx7cMxBPAFObJMuUv/4nfkRiJpFROpedgiM7OPz d9/dmQ2MXA9G9qpHnjlX81tItDOCj3QnzsbxSgeoB57Bh5Cc7uxEGDvVdx7cefD6jQ9h5lx8zg2q HM1wrFhs4IiNp5PZsXmy90VSaAP+yPMvw19OEEA4dS4CIugGAHNZEDbMkB5f45ieU6nN5SvH90s/ 2LscsQcZYWZH1JolCGPUXIm1ETInBM9rEN6+gB1Quh9WVtIeC83lFtVu2FjLTeTCCGZQQ9R4DUAb pow+YNjDGCQFUxEYkaFyD+jAfudWx3ri6an6uhZR2iUNbMtEypYiFWZHSD0ZVCHZ/TUQHMi8k7fB ufEorHRolYG1kpxS6b6Y1k1sf9fH2rtWnwgNcuKki6XGTYG5OTesTp5F2TYsTXdAL5nILbn+cpsV kiK4FbLQA2Cc45qY2dkcH/vDMK0lJ12oKaj0MI90J2v9YR6vFoaZQpMU3ymySHCCzBNSijc5q1u7 H94+k8Bltk5J98hiVAfDdXd9Ue3wP58JZ9fpiT7uInxC6rAlMtNi1G73p93OBDstk+X9BUWyWkoF C8oL5UL/Cx57/Uq/kHoO5rg50C9sGtGuFFj+am5uyhzOmUlFHAMaYKnbKanJ77Wg0woemOIrCAb2 XxY8K7wfM1tu16OfhDgJnW90/QFE89ftZW5kc3RyZWFtCmVuZG9iagoyMDMgMCBvYmoKNTQxCmVu ZG9iagoyMDcgMCBvYmoKPDwvTGVuZ3RoIDIwOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nOVV32/TMBB+919xb2xSmzVJGUMCpI1WgNikEuUN8eAl19Rb47Q+V+Oh4m/nnDhr15Yt lfbGZ0WWfOfvfvqyhEEQwsAtv2elOEveQUFiAF/4K8RShLUC+C0r4SplpQt3kE5Fcy+EixDO30eQ luLkm7ZoNNr+yMiphQMYXY8nh84Zl6tiRRaiQRidpncijiG9Fics+ND3mCAaSNGUkCC1h3131x0q LS06yaLShKdvRBTVDDGHGLwFSKoVewcjtJhZAglfURp7i9KCVSWylO84e17xAG6qHEu3I5EskLko M2phVaX5bhi2Hn98BWwC2EpBnYFHvx9T4B2H57U+tWoA6/XLZB5/ttdrG9qkrAN8XTZlS7lsBvD3 Qhmk3o7fzyD3LVAqIqULmLWMFHgj3bmsvEeCvHrQIOdz0KiK2W1lgLhFuC2oO5PUOdi2jwnsDMEl 7ggCoipT0nVj8KR7YOf5NC9lUy7W2JEluFwh2e62m5fxj2QcW+g2dz2XBKbK7nX1MMe8aNLS3aun Ue2/qJ2oLz9/354q+1JnuR4n523E/+k0Wa+9Ukcqj2NnyRFmhsM6ukTauZpOAS13YLBletxMCbiR JptB3HP/mXivJD8nrhDD8BczjlPxg9dfFmG0emVuZHN0cmVhbQplbmRvYmoKMjA4IDAgb2JqCjQ3 OQplbmRvYmoKMjEyIDAgb2JqCjw8L0xlbmd0aCAyMTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJzVVU1vm0AQve+vmFttyaYGnMaV0khJ7H6oTuW63JocNjDgbYC1d9dyD/nxHQwE U0NjR+khs0IrDcNj5s3b2RUMLBsG2Sp2P2Fv56cQaTaAT/REbMXsbQAUm5/ApUdBo8zhhSz/zoaR De/eO+AlrPMlNahSNP2x4qGBBhtPJ7MmP9nFOlprA87AdrreL+a64E1ZpyX4L7uWASbwGbkyd8gN eCJBBfh7KRTqXvcNs+0j0AI06BsNidBapBEsSlxt5X8iwAOhDL9HDYHcpMDjGFIU0eJOKtBI0DLV hOQ4j6md9XObIWXvoUpEyg0Wzn4WUX8Dc1ytUZvD85nLNbWoLa1jiSqr6IFZIEH596ncxBhEBE6e w9Oql1UnpYkSuLj6unWfN5BC7wjh5GSL4JLArdO9mJtOqGSSd/OmC1O5JbH6a8FTg+VSo51q5xHC GLWvxNIQDzX6PryA1YmAh4cn5JHn9kIaqU6TodOkgbxHnyRTZqGBay19wTOerKYGt5R1vpPRnkp2 Dk2LPvpVyzSmgW7WynBYaWXUppU8idciln9OknZSj1dLMXov/7dKzp4ajY3qL+t45hApLiEShgPw rRzeP5boi1D4j239GMuNrmbOnJtYhCGgoelq7RQ6yS8kuObKX4Dbyy47d4+On7MMc+jcEuLEY99p /QGsi+EXZW5kc3RyZWFtCmVuZG9iagoyMTMgMCBvYmoKNTEwCmVuZG9iagoyMTcgMCBvYmoKPDwv TGVuZ3RoIDIxOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1VTU/CQBC976+Y m5BA7QdRTNQELTFGMEjqyXio26Gs0g+6W/HAj3cKBYpUgwESD86m2aSZeTPv7dt2DLpmgJ6tfOcB O+6fgi+ZDjf0+GzMjFkC5BsP4MqhpGb2whmweZ0BTQNOzkxwAla5DRUmIaq6nbgDBSVhd9q9svcU rdRPpQJTN8yq88osC5wOq1i6ZtKI0I08DOAehT98iRJ4jKETSVU9YqY5yyOAfpRS+zLoeTHtKKXr I9goeSJiJaKQEAxjgXCxh1gbCabTehbFueuFWM4mMfRkkR7BVL4RqpScEgFKEgCiEFrXd4vy8/qO /TfrCX1Zf7mS3eUcYyVBDRHCPH1N3C1C0vnMz2Ql4SYDz1VYZPDVG11UieCyrLm2vnKSu7RoNFY2 NZdi2KiQkxh2Go8EJ7CitPLPu/agrplO4fCu2SL2cm8S3OHm5hp4uVm8DbPUfiuFct+QgKJJOFM0 TvBdRKmsLXTefrb5gUyWo2jr8v5/Fn5u0WzOWvRdNRKDAaACd6QVKLU/YkHega6b8CFYtey3Z20Q f+pl975hPRNi22EPtD4BNNnaDWVuZHN0cmVhbQplbmRvYmoKMjE4IDAgb2JqCjQzMQplbmRvYmoK MjIyIDAgb2JqCjw8L0xlbmd0aCAyMjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0K eJztVl1P2zAUffevOG+AREO+YExikzpaIbQWlSrbC+LBxDepEU2K7TL49zgmLYlaBNV4WKUdK0oU 3Xt87vW5Su7hewH8atX3dMoOxl+Qa+bjzF45u2eBC0B9S6f4kdig4+pFkrGXvADHAY6+hkimbPe8 MKQKMp2e4pnBGvQG/dG69xbdeT7XBqEfhHvJLYsiJAO2G/le6EXABcl8clMq/Jrt46LEgD+RQoSu EIq0Jr23w8LQpViucTm3StbtMiwFTd2DzeI5oUc6VXJmZFlYiiBYUHz7BLQ04aTj0KgEnQaW4jQV QjcLtjSOYDW/e/pzmf/9tW6epjQzGmZCKOrwVnEfgG2pfulJo4T3USvojkcamRV5PnqIITMIymRB wttURs0nlHwg25TegvTIki768j4au79Ws3oeghtqnkd9IMuIIRklU72uBq+9aml/s0VzAOLWAOCP NBPXWTcKVTc2dP8Wmd8Vu6lrKuM75yWD320dWzRDb3l+Iwnb7vzDN5wPXoj/zl/F0vmL/lQjoP+J GYhjlzbm5k5mGciA33mNyP7jTNpvOYZcpRNE+9WvQLTCdzWqji+Ory1jP2GXdj0D+oQMSWVuZHN0 cmVhbQplbmRvYmoKMjIzIDAgb2JqCjQ1MQplbmRvYmoKMjI3IDAgb2JqCjw8L0xlbmd0aCAyMjgg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytVNtum0AQfecrRnlpImFq7NwqtZHi S3pJ4lBC+xLlYQ0DbL3sJssSmr/vQHCAxo0cqYMMXjhz5szs7NzD0HFhWF3NM8ys9/4RJLk1hM/0 S6x7y60B0DzCDCYBgY6rF0FsPfm5cOzC4YcRBJm1+1Ua1BLNYKZZbGCDzS7m3qb3ZKdFUuQGRkN3 tBf8ssZjCC6sXfrwcVDbAnmSLpWGH3cRMzhYW+V7qSLM4BlxiUbzMN97Z7numqUxp38RpAk0Hjoj 5xBakmvMc64kXBdhSH8JORqtyXxVUKabsnhSQk9yYQnCDPNQ8ztDTD05n/6DteKryM8F8ZCkXcUx 6kFrJ61qVX3KgT0wLtiSC24ee8lBl+cLMm2WyEzL1Av7cnOgE7VTk00hul6n0/Ou1rVactuyB57D bLHnb6XsKN/CnnqAS244MeZgUgRKJeOSlv+IPlOl7FSuF31TxWp8W7OTFxXbxtRbwE33vJ7WRpn9 Lnx9Y//Kq1eHputOw5VUpcAowQyl6Z/MgESxwqSKOrxUhYhA8BXpVMBat1o6l7EoUIaElxGEStLM WBbVQe0PDhXDNNU8hyuRo7QhwFDBRClj02hYcpLMchu+MSxpWJwzmdjwk680y2hRCBt8Hq6aZAP2 KJQmsEpllWmEggALFDm5eqqslxNVDhZMUlCsuCpxX1BKLpOGxVdJgk6b9ULpjBn+gOAjnewqpbyB 3vhn04ODo+NbmKDWj0Tu2DCP6LbjeZ6aQ8lNClONETdwJlRZh2vG545NLPv7dQyfGcHjGNAAE06n K+a/77imZrhkOkxhbFfze/yid268ahbuH9wS4zywvtP1B/VIoDRlbmRzdHJlYW0KZW5kb2JqCjIy OCAwIG9iago2MzIKZW5kb2JqCjIzMiAwIG9iago8PC9MZW5ndGggMjMzIDAgUi9GaWx0ZXIgL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCnictVTJcptAEL3zFV262K4ihEUSVk5Gix3HsksRpHJw+TCCFhqb zT1DFP19eiRSibwcPVPUwMzj9XtNN8/gOh64ZnZrWlqflyHkynLhiq/cera8PQC6JS1hnDDo3Gwk a+vwngfnHgxHPiSldXpdaaQK9acpibWGN8Z0Plu8tc8javNWafBdzz9LHq0ggGRunR5BlpcTGAzC cxsucUWtoJ2Bu87ZieX7f+H3jPI9b/QAYxJZhWRD7NjQu8EdbGvKFKxrglYhyMowKtA1XFeZTIVG ZmIXDCiFlr8QlrhGwipFZU4M+zSZxw+8r9KaCmHDjLlnme1Abyq0yEmUkJCoVFOThrnYIUGMaUtS 73o2k3jeC1/GVD/ohzZEDcmCHblD46hLQNTqTU0nCqIsI1Rqr+Sf21gLdiF0IdfrI/aJZIWdaC90 4SdychOhSsZPib11ZzE/f6sV2jCJAEYDL+h3Jz/iqLub3QpZfAFFhzgXqeF20ro8kjKuYYxEu4+W sapXJsw7Kq4Ic/gqiKSqq4+WkhNuTKh3tMQbsWWu9kVO7lBHTdMxhYHrwY3UMCHEJ1jWIrNh3Moi k1UOfofiekNB6YZrS4oqLxAWgp5suJuAH4bu6LXA8vDJjALnkRVccF+Kpnmlccr6dwWb1ty7243c 98AHJe2gKVOHWEdJGw73EbtKBtQgCue/1p/9biSXP9zusxDYpvGDV/+Q+4XIEfrDB2acJdZ3nn8A l2FC0mVuZHN0cmVhbQplbmRvYmoKMjMzIDAgb2JqCjU1NQplbmRvYmoKNCAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgOSAwIFIKL0ZvbnQgMTAgMCBS Cj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE0IDAgUgovRm9udCAxNSAwIFIKPj4KL0NvbnRl bnRzIDEyIDAgUgo+PgplbmRvYmoKMTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRXh0R1N0YXRlIDE5IDAgUgovRm9udCAyMCAwIFIKPj4KL0NvbnRlbnRzIDE3IDAg Ugo+PgplbmRvYmoKMjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0K L1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov RXh0R1N0YXRlIDI0IDAgUgovRm9udCAyNSAwIFIKPj4KL0NvbnRlbnRzIDIyIDAgUgo+PgplbmRv YmoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDI5IDAgUgovRm9udCAzMCAwIFIKPj4KL0NvbnRlbnRzIDI3IDAgUgo+PgplbmRvYmoKMzEgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDM0IDAgUgov Rm9udCAzNSAwIFIKPj4KL0NvbnRlbnRzIDMyIDAgUgo+PgplbmRvYmoKMzYgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDM5IDAgUgovRm9udCA0MCAw IFIKPj4KL0NvbnRlbnRzIDM3IDAgUgo+PgplbmRvYmoKNDEgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ0IDAgUgovRm9udCA0NSAwIFIKPj4KL0Nv bnRlbnRzIDQyIDAgUgo+PgplbmRvYmoKNDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw IDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGIC9UZXh0XQovRXh0R1N0YXRlIDQ5IDAgUgovRm9udCA1MCAwIFIKPj4KL0NvbnRlbnRzIDQ3 IDAgUgo+PgplbmRvYmoKNTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5 Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0 XQovRXh0R1N0YXRlIDU0IDAgUgovRm9udCA1NSAwIFIKPj4KL0NvbnRlbnRzIDUyIDAgUgo+Pgpl bmRvYmoKNTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0 ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0 YXRlIDU5IDAgUgovRm9udCA2MCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUgo+PgplbmRvYmoKNjEg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDY0IDAg UgovRm9udCA2NSAwIFIKPj4KL0NvbnRlbnRzIDYyIDAgUgo+PgplbmRvYmoKNjYgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDY5IDAgUgovRm9udCA3 MCAwIFIKPj4KL0NvbnRlbnRzIDY3IDAgUgo+PgplbmRvYmoKNzEgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc0IDAgUgovRm9udCA3NSAwIFIKPj4K L0NvbnRlbnRzIDcyIDAgUgo+PgplbmRvYmoKNzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc5IDAgUgovRm9udCA4MCAwIFIKPj4KL0NvbnRlbnRz IDc3IDAgUgo+PgplbmRvYmoKODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDg0IDAgUgovRm9udCA4NSAwIFIKPj4KL0NvbnRlbnRzIDgyIDAgUgo+ PgplbmRvYmoKODYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDg5IDAgUgovRm9udCA5MCAwIFIKPj4KL0NvbnRlbnRzIDg3IDAgUgo+PgplbmRvYmoK OTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk0 IDAgUgovRm9udCA5NSAwIFIKPj4KL0NvbnRlbnRzIDkyIDAgUgo+PgplbmRvYmoKOTYgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk5IDAgUgovRm9u dCAxMDAgMCBSCj4+Ci9Db250ZW50cyA5NyAwIFIKPj4KZW5kb2JqCjEwMSAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTA0IDAgUgovRm9udCAxMDUg MCBSCj4+Ci9Db250ZW50cyAxMDIgMCBSCj4+CmVuZG9iagoxMDYgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEwOSAwIFIKL0ZvbnQgMTEwIDAgUgo+ PgovQ29udGVudHMgMTA3IDAgUgo+PgplbmRvYmoKMTExIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMTQgMCBSCi9Gb250IDExNSAwIFIKPj4KL0Nv bnRlbnRzIDExMiAwIFIKPj4KZW5kb2JqCjExNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE5IDAgUgovRm9udCAxMjAgMCBSCj4+Ci9Db250ZW50 cyAxMTcgMCBSCj4+CmVuZG9iagoxMjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRXh0R1N0YXRlIDEyNCAwIFIKL0ZvbnQgMTI1IDAgUgo+PgovQ29udGVudHMgMTIy IDAgUgo+PgplbmRvYmoKMTI2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3 OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSAxMjkgMCBSCi9Gb250IDEzMCAwIFIKPj4KL0NvbnRlbnRzIDEyNyAwIFIK Pj4KZW5kb2JqCjEzMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9F eHRHU3RhdGUgMTM0IDAgUgovRm9udCAxMzUgMCBSCj4+Ci9Db250ZW50cyAxMzIgMCBSCj4+CmVu ZG9iagoxMzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0 ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0 YXRlIDEzOSAwIFIKL0ZvbnQgMTQwIDAgUgo+PgovQ29udGVudHMgMTM3IDAgUgo+PgplbmRvYmoK MTQxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAx NDQgMCBSCi9Gb250IDE0NSAwIFIKPj4KL0NvbnRlbnRzIDE0MiAwIFIKPj4KZW5kb2JqCjE0NiAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQ5IDAg UgovRm9udCAxNTAgMCBSCj4+Ci9Db250ZW50cyAxNDcgMCBSCj4+CmVuZG9iagoxNTEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE1NCAwIFIKL0Zv bnQgMTU1IDAgUgo+PgovQ29udGVudHMgMTUyIDAgUgo+PgplbmRvYmoKMTU2IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNTkgMCBSCi9Gb250IDE2 MCAwIFIKPj4KL0NvbnRlbnRzIDE1NyAwIFIKPj4KZW5kb2JqCjE2MSAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTY0IDAgUgovRm9udCAxNjUgMCBS Cj4+Ci9Db250ZW50cyAxNjIgMCBSCj4+CmVuZG9iagoxNjYgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE2OSAwIFIKL0ZvbnQgMTcwIDAgUgo+Pgov Q29udGVudHMgMTY3IDAgUgo+PgplbmRvYmoKMTcxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNzQgMCBSCi9Gb250IDE3NSAwIFIKPj4KL0NvbnRl bnRzIDE3MiAwIFIKPj4KZW5kb2JqCjE3NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAg MCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTc5IDAgUgovRm9udCAxODAgMCBSCj4+Ci9Db250ZW50cyAx NzcgMCBSCj4+CmVuZG9iagoxODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDE4NCAwIFIKL0ZvbnQgMTg1IDAgUgo+PgovQ29udGVudHMgMTgyIDAg Ugo+PgplbmRvYmoKMTg2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAxODkgMCBSCi9Gb250IDE5MCAwIFIKPj4KL0NvbnRlbnRzIDE4NyAwIFIKPj4K ZW5kb2JqCjE5MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgMTk0IDAgUgovRm9udCAxOTUgMCBSCj4+Ci9Db250ZW50cyAxOTIgMCBSCj4+CmVuZG9i agoxOTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDE5OSAwIFIKL0ZvbnQgMjAwIDAgUgo+PgovQ29udGVudHMgMTk3IDAgUgo+PgplbmRvYmoKMjAx IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMDQg MCBSCi9Gb250IDIwNSAwIFIKPj4KL0NvbnRlbnRzIDIwMiAwIFIKPj4KZW5kb2JqCjIwNiAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjA5IDAgUgov Rm9udCAyMTAgMCBSCj4+Ci9Db250ZW50cyAyMDcgMCBSCj4+CmVuZG9iagoyMTEgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIxNCAwIFIKL0ZvbnQg MjE1IDAgUgo+PgovQ29udGVudHMgMjEyIDAgUgo+PgplbmRvYmoKMjE2IDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMTkgMCBSCi9Gb250IDIyMCAw IFIKPj4KL0NvbnRlbnRzIDIxNyAwIFIKPj4KZW5kb2JqCjIyMSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjI0IDAgUgovRm9udCAyMjUgMCBSCj4+ Ci9Db250ZW50cyAyMjIgMCBSCj4+CmVuZG9iagoyMjYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIyOSAwIFIKL0ZvbnQgMjMwIDAgUgo+PgovQ29u dGVudHMgMjI3IDAgUgo+PgplbmRvYmoKMjMxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMzQgMCBSCi9Gb250IDIzNSAwIFIKPj4KL0NvbnRlbnRz IDIzMiAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIK MTEgMCBSCjE2IDAgUgoyMSAwIFIKMjYgMCBSCjMxIDAgUgozNiAwIFIKNDEgMCBSCjQ2IDAgUgo1 MSAwIFIKNTYgMCBSCjYxIDAgUgo2NiAwIFIKNzEgMCBSCjc2IDAgUgo4MSAwIFIKODYgMCBSCjkx IDAgUgo5NiAwIFIKMTAxIDAgUgoxMDYgMCBSCjExMSAwIFIKMTE2IDAgUgoxMjEgMCBSCjEyNiAw IFIKMTMxIDAgUgoxMzYgMCBSCjE0MSAwIFIKMTQ2IDAgUgoxNTEgMCBSCjE1NiAwIFIKMTYxIDAg UgoxNjYgMCBSCjE3MSAwIFIKMTc2IDAgUgoxODEgMCBSCjE4NiAwIFIKMTkxIDAgUgoxOTYgMCBS CjIwMSAwIFIKMjA2IDAgUgoyMTEgMCBSCjIxNiAwIFIKMjIxIDAgUgoyMjYgMCBSCjIzMSAwIFIK XSAvQ291bnQgNDYKPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAw IFIKL01ldGFkYXRhIDIzNyAwIFIKPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUK L09QTSAxPj5lbmRvYmoKOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9S OAo4IDAgUj4+CmVuZG9iagoxNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNSAwIG9iago8 PC9SOAo4IDAgUj4+CmVuZG9iagoxOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyMCAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iagoyNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNSAw IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoyOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoz MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagozNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i agozNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagozOSAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iago0MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago0NCAwIG9iago8PC9SNwo3IDAgUj4+ CmVuZG9iago0NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago0OSAwIG9iago8PC9SNwo3IDAg Uj4+CmVuZG9iago1MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago1NCAwIG9iago8PC9SNwo3 IDAgUj4+CmVuZG9iago1NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9S Nwo3IDAgUj4+CmVuZG9iago2MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago2NCAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iago2NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago2OSAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iago3MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3NCAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago3NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3 OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago4MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i ago4NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago4NSAwIG9iago8PC9SOAo4IDAgUj4+CmVu ZG9iago4OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago5MCAwIG9iago8PC9SOAo4IDAgUj4+ CmVuZG9iago5NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago5NSAwIG9iago8PC9SOAo4IDAg Uj4+CmVuZG9iago5OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMDAgMCBvYmoKPDwvUjgK OCAwIFI+PgplbmRvYmoKMTA0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwNSAwIG9iago8 PC9SOAo4IDAgUj4+CmVuZG9iagoxMDkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTEwIDAg b2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjExNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagox MTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k b2JqCjEyMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMjQgMCBvYmoKPDwvUjcKNyAwIFI+ PgplbmRvYmoKMTI1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjEyOSAwIG9iago8PC9SNwo3 IDAgUj4+CmVuZG9iagoxMzAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTM0IDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjEzNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMzkgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTQwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE0 NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNDUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRv YmoKMTQ5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1MCAwIG9iago8PC9SOAo4IDAgUj4+ CmVuZG9iagoxNTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTU1IDAgb2JqCjw8L1I4Cjgg MCBSPj4KZW5kb2JqCjE1OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNjAgMCBvYmoKPDwv UjgKOCAwIFI+PgplbmRvYmoKMTY0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE2NSAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTcw IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE3NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i agoxNzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTc5IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjE4MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxODQgMCBvYmoKPDwvUjcKNyAw IFI+PgplbmRvYmoKMTg1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE4OSAwIG9iago8PC9S Nwo3IDAgUj4+CmVuZG9iagoxOTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTk0IDAgb2Jq Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE5NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxOTkg MCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjAwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2Jq CjIwNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyMDUgMCBvYmoKPDwvUjgKOCAwIFI+Pgpl bmRvYmoKMjA5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjIxMCAwIG9iago8PC9SOAo4IDAg Uj4+CmVuZG9iagoyMTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjE1IDAgb2JqCjw8L1I4 CjggMCBSPj4KZW5kb2JqCjIxOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyMjAgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKMjI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjIyNSAw IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoyMjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK MjMwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjIzNCAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iagoyMzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9D b3VyaWVyL1R5cGUvRm9udAovRW5jb2RpbmcgMjM2IDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2Jq CjIzNiAwIG9iago8PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxMjYvdGlsZGVdPj4KZW5k b2JqCjIzNyAwIG9iago8PC9UeXBlL01ldGFkYXRhCi9TdWJ0eXBlL1hNTC9MZW5ndGggMTM1Mz4+ c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlk Jz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0n YWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdvcmsg MS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4KPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzYzNDJhNTQ1LTJiMDYtMTFlZC0wMDAwLTE5YWMzZWNi ZjU3JyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNl cj0nR1BMIEdob3N0c2NyaXB0IDkuMDQnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzYz NDJhNTQ1LTJiMDYtMTFlZC0wMDAwLTE5YWMzZWNiZjU3JyB4bWxuczp4bXA9J2h0dHA6Ly9ucy5h ZG9iZS5jb20veGFwLzEuMC8nPjx4bXA6TW9kaWZ5RGF0ZT4yMDEyLTA4LTMwVDE3OjI5OjU0LTA0 OjAwPC94bXA6TW9kaWZ5RGF0ZT4KPHhtcDpDcmVhdGVEYXRlPjIwMTItMDgtMzBUMTc6Mjk6NTQt MDQ6MDA8L3htcDpDcmVhdGVEYXRlPgo8eG1wOkNyZWF0b3JUb29sPkdOVSBlbnNjcmlwdCAxLjYu NS4xPC94bXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSc2MzQyYTU0NS0yYjA2LTExZWQtMDAwMC0xOWFjM2VjYmY1NycgeG1sbnM6eGFw TU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1 aWQ6NjM0MmE1NDUtMmIwNi0xMWVkLTAwMDAtMTlhYzNlY2JmNTcyMDEyLTA4LTMwVDE3OjI5OjU0 LTA0OjAwJy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSc2MzQyYTU0NS0yYjA2LTExZWQt MDAwMC0xOWFjM2VjYmY1NycgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8x LjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6 bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+RW5zY3JpcHQgT3V0cHV0PC9yZGY6bGk+PC9yZGY6QWx0 PjwvZGM6dGl0bGU+PC9yZGY6RGVzY3JpcHRpb24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJl YW0KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDQpCi9DcmVh dGlvbkRhdGUoRDoyMDEyMDgzMDE3Mjk1NC0wNCcwMCcpCi9Nb2REYXRlKEQ6MjAxMjA4MzAxNzI5 NTQtMDQnMDAnKQovVGl0bGUoRW5zY3JpcHQgT3V0cHV0KQovQ3JlYXRvcihHTlUgZW5zY3JpcHQg MS42LjUuMSk+PmVuZG9iagp4cmVmCjAgMjM4CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA1NDQ1 NyAwMDAwMCBuIAowMDAwMDU4OTQ4IDAwMDAwIG4gCjAwMDAwNTQwNTUgMDAwMDAgbiAKMDAwMDA0 NjQ5NyAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDExNDkgMDAwMDAgbiAKMDAw MDA1NDUyMyAwMDAwMCBuIAowMDAwMDU3Mzc4IDAwMDAwIG4gCjAwMDAwNTQ1NjQgMDAwMDAgbiAK MDAwMDA1NDU5MyAwMDAwMCBuIAowMDAwMDQ2NjU2IDAwMDAwIG4gCjAwMDAwMDExNjkgMDAwMDAg biAKMDAwMDAwMjI5OCAwMDAwMCBuIAowMDAwMDU0NjIzIDAwMDAwIG4gCjAwMDAwNTQ2NTMgMDAw MDAgbiAKMDAwMDA0NjgxOCAwMDAwMCBuIAowMDAwMDAyMzE5IDAwMDAwIG4gCjAwMDAwMDMzNDcg MDAwMDAgbiAKMDAwMDA1NDY4MyAwMDAwMCBuIAowMDAwMDU0NzEzIDAwMDAwIG4gCjAwMDAwNDY5 ODAgMDAwMDAgbiAKMDAwMDAwMzM2NyAwMDAwMCBuIAowMDAwMDA1MTA4IDAwMDAwIG4gCjAwMDAw NTQ3NDMgMDAwMDAgbiAKMDAwMDA1NDc3MyAwMDAwMCBuIAowMDAwMDQ3MTQyIDAwMDAwIG4gCjAw MDAwMDUxMjkgMDAwMDAgbiAKMDAwMDAwNjQzNCAwMDAwMCBuIAowMDAwMDU0ODAzIDAwMDAwIG4g CjAwMDAwNTQ4MzMgMDAwMDAgbiAKMDAwMDA0NzMwNCAwMDAwMCBuIAowMDAwMDA2NDU1IDAwMDAw IG4gCjAwMDAwMDc1MDQgMDAwMDAgbiAKMDAwMDA1NDg2MyAwMDAwMCBuIAowMDAwMDU0ODkzIDAw MDAwIG4gCjAwMDAwNDc0NjYgMDAwMDAgbiAKMDAwMDAwNzUyNCAwMDAwMCBuIAowMDAwMDA4OTk1 IDAwMDAwIG4gCjAwMDAwNTQ5MjMgMDAwMDAgbiAKMDAwMDA1NDk1MyAwMDAwMCBuIAowMDAwMDQ3 NjI4IDAwMDAwIG4gCjAwMDAwMDkwMTYgMDAwMDAgbiAKMDAwMDAxMDM5NSAwMDAwMCBuIAowMDAw MDU0OTgzIDAwMDAwIG4gCjAwMDAwNTUwMTMgMDAwMDAgbiAKMDAwMDA0Nzc5MCAwMDAwMCBuIAow MDAwMDEwNDE2IDAwMDAwIG4gCjAwMDAwMTE3ODEgMDAwMDAgbiAKMDAwMDA1NTA0MyAwMDAwMCBu IAowMDAwMDU1MDczIDAwMDAwIG4gCjAwMDAwNDc5NTIgMDAwMDAgbiAKMDAwMDAxMTgwMiAwMDAw MCBuIAowMDAwMDEzMTczIDAwMDAwIG4gCjAwMDAwNTUxMDMgMDAwMDAgbiAKMDAwMDA1NTEzMyAw MDAwMCBuIAowMDAwMDQ4MTE0IDAwMDAwIG4gCjAwMDAwMTMxOTQgMDAwMDAgbiAKMDAwMDAxNDY2 NyAwMDAwMCBuIAowMDAwMDU1MTYzIDAwMDAwIG4gCjAwMDAwNTUxOTMgMDAwMDAgbiAKMDAwMDA0 ODI3NiAwMDAwMCBuIAowMDAwMDE0Njg4IDAwMDAwIG4gCjAwMDAwMTU2NjUgMDAwMDAgbiAKMDAw MDA1NTIyMyAwMDAwMCBuIAowMDAwMDU1MjUzIDAwMDAwIG4gCjAwMDAwNDg0MzggMDAwMDAgbiAK MDAwMDAxNTY4NSAwMDAwMCBuIAowMDAwMDE2NzAzIDAwMDAwIG4gCjAwMDAwNTUyODMgMDAwMDAg biAKMDAwMDA1NTMxMyAwMDAwMCBuIAowMDAwMDQ4NjAwIDAwMDAwIG4gCjAwMDAwMTY3MjMgMDAw MDAgbiAKMDAwMDAxNzY0NSAwMDAwMCBuIAowMDAwMDU1MzQzIDAwMDAwIG4gCjAwMDAwNTUzNzMg MDAwMDAgbiAKMDAwMDA0ODc2MiAwMDAwMCBuIAowMDAwMDE3NjY1IDAwMDAwIG4gCjAwMDAwMTg1 ODcgMDAwMDAgbiAKMDAwMDA1NTQwMyAwMDAwMCBuIAowMDAwMDU1NDMzIDAwMDAwIG4gCjAwMDAw NDg5MjQgMDAwMDAgbiAKMDAwMDAxODYwNyAwMDAwMCBuIAowMDAwMDE5NjI0IDAwMDAwIG4gCjAw MDAwNTU0NjMgMDAwMDAgbiAKMDAwMDA1NTQ5MyAwMDAwMCBuIAowMDAwMDQ5MDg2IDAwMDAwIG4g CjAwMDAwMTk2NDQgMDAwMDAgbiAKMDAwMDAyMDQ0NiAwMDAwMCBuIAowMDAwMDU1NTIzIDAwMDAw IG4gCjAwMDAwNTU1NTMgMDAwMDAgbiAKMDAwMDA0OTI0OCAwMDAwMCBuIAowMDAwMDIwNDY2IDAw MDAwIG4gCjAwMDAwMjE0MjYgMDAwMDAgbiAKMDAwMDA1NTU4MyAwMDAwMCBuIAowMDAwMDU1NjEz IDAwMDAwIG4gCjAwMDAwNDk0MTAgMDAwMDAgbiAKMDAwMDAyMTQ0NiAwMDAwMCBuIAowMDAwMDIy MjEzIDAwMDAwIG4gCjAwMDAwNTU2NDMgMDAwMDAgbiAKMDAwMDA1NTY3MyAwMDAwMCBuIAowMDAw MDQ5NTczIDAwMDAwIG4gCjAwMDAwMjIyMzMgMDAwMDAgbiAKMDAwMDAyMzI1MiAwMDAwMCBuIAow MDAwMDU1NzA0IDAwMDAwIG4gCjAwMDAwNTU3MzUgMDAwMDAgbiAKMDAwMDA0OTczOSAwMDAwMCBu IAowMDAwMDIzMjczIDAwMDAwIG4gCjAwMDAwMjQyMDYgMDAwMDAgbiAKMDAwMDA1NTc2NiAwMDAw MCBuIAowMDAwMDU1Nzk3IDAwMDAwIG4gCjAwMDAwNDk5MDUgMDAwMDAgbiAKMDAwMDAyNDIyNyAw MDAwMCBuIAowMDAwMDI1MDgyIDAwMDAwIG4gCjAwMDAwNTU4MjggMDAwMDAgbiAKMDAwMDA1NTg1 OSAwMDAwMCBuIAowMDAwMDUwMDcxIDAwMDAwIG4gCjAwMDAwMjUxMDMgMDAwMDAgbiAKMDAwMDAy NjI0NCAwMDAwMCBuIAowMDAwMDU1ODkwIDAwMDAwIG4gCjAwMDAwNTU5MjEgMDAwMDAgbiAKMDAw MDA1MDIzNyAwMDAwMCBuIAowMDAwMDI2MjY2IDAwMDAwIG4gCjAwMDAwMjcxNzMgMDAwMDAgbiAK MDAwMDA1NTk1MiAwMDAwMCBuIAowMDAwMDU1OTgzIDAwMDAwIG4gCjAwMDAwNTA0MDMgMDAwMDAg biAKMDAwMDAyNzE5NCAwMDAwMCBuIAowMDAwMDI4MjA2IDAwMDAwIG4gCjAwMDAwNTYwMTQgMDAw MDAgbiAKMDAwMDA1NjA0NSAwMDAwMCBuIAowMDAwMDUwNTY5IDAwMDAwIG4gCjAwMDAwMjgyMjcg MDAwMDAgbiAKMDAwMDAyOTIwNiAwMDAwMCBuIAowMDAwMDU2MDc2IDAwMDAwIG4gCjAwMDAwNTYx MDcgMDAwMDAgbiAKMDAwMDA1MDczNSAwMDAwMCBuIAowMDAwMDI5MjI3IDAwMDAwIG4gCjAwMDAw MzAxNDggMDAwMDAgbiAKMDAwMDA1NjEzOCAwMDAwMCBuIAowMDAwMDU2MTY5IDAwMDAwIG4gCjAw MDAwNTA5MDEgMDAwMDAgbiAKMDAwMDAzMDE2OSAwMDAwMCBuIAowMDAwMDMxMTc3IDAwMDAwIG4g CjAwMDAwNTYyMDAgMDAwMDAgbiAKMDAwMDA1NjIzMSAwMDAwMCBuIAowMDAwMDUxMDY3IDAwMDAw IG4gCjAwMDAwMzExOTggMDAwMDAgbiAKMDAwMDAzMjMzNiAwMDAwMCBuIAowMDAwMDU2MjYyIDAw MDAwIG4gCjAwMDAwNTYyOTMgMDAwMDAgbiAKMDAwMDA1MTIzMyAwMDAwMCBuIAowMDAwMDMyMzU4 IDAwMDAwIG4gCjAwMDAwMzM1ODcgMDAwMDAgbiAKMDAwMDA1NjMyNCAwMDAwMCBuIAowMDAwMDU2 MzU1IDAwMDAwIG4gCjAwMDAwNTEzOTkgMDAwMDAgbiAKMDAwMDAzMzYwOSAwMDAwMCBuIAowMDAw MDM0NjA0IDAwMDAwIG4gCjAwMDAwNTYzODYgMDAwMDAgbiAKMDAwMDA1NjQxNyAwMDAwMCBuIAow MDAwMDUxNTY1IDAwMDAwIG4gCjAwMDAwMzQ2MjUgMDAwMDAgbiAKMDAwMDAzNTY3MCAwMDAwMCBu IAowMDAwMDU2NDQ4IDAwMDAwIG4gCjAwMDAwNTY0NzkgMDAwMDAgbiAKMDAwMDA1MTczMSAwMDAw MCBuIAowMDAwMDM1NjkxIDAwMDAwIG4gCjAwMDAwMzY3MzkgMDAwMDAgbiAKMDAwMDA1NjUxMCAw MDAwMCBuIAowMDAwMDU2NTQxIDAwMDAwIG4gCjAwMDAwNTE4OTcgMDAwMDAgbiAKMDAwMDAzNjc2 MCAwMDAwMCBuIAowMDAwMDM3ODAxIDAwMDAwIG4gCjAwMDAwNTY1NzIgMDAwMDAgbiAKMDAwMDA1 NjYwMyAwMDAwMCBuIAowMDAwMDUyMDYzIDAwMDAwIG4gCjAwMDAwMzc4MjIgMDAwMDAgbiAKMDAw MDAzOTAxOSAwMDAwMCBuIAowMDAwMDU2NjM0IDAwMDAwIG4gCjAwMDAwNTY2NjUgMDAwMDAgbiAK MDAwMDA1MjIyOSAwMDAwMCBuIAowMDAwMDM5MDQxIDAwMDAwIG4gCjAwMDAwNDAxMzMgMDAwMDAg biAKMDAwMDA1NjY5NiAwMDAwMCBuIAowMDAwMDU2NzI3IDAwMDAwIG4gCjAwMDAwNTIzOTUgMDAw MDAgbiAKMDAwMDA0MDE1NSAwMDAwMCBuIAowMDAwMDQwODcxIDAwMDAwIG4gCjAwMDAwNTY3NTgg MDAwMDAgbiAKMDAwMDA1Njc4OSAwMDAwMCBuIAowMDAwMDUyNTYxIDAwMDAwIG4gCjAwMDAwNDA4 OTIgMDAwMDAgbiAKMDAwMDA0MTYzNyAwMDAwMCBuIAowMDAwMDU2ODIwIDAwMDAwIG4gCjAwMDAw NTY4NTEgMDAwMDAgbiAKMDAwMDA1MjcyNyAwMDAwMCBuIAowMDAwMDQxNjU4IDAwMDAwIG4gCjAw MDAwNDIyMTIgMDAwMDAgbiAKMDAwMDA1Njg4MiAwMDAwMCBuIAowMDAwMDU2OTEzIDAwMDAwIG4g CjAwMDAwNTI4OTMgMDAwMDAgbiAKMDAwMDA0MjIzMyAwMDAwMCBuIAowMDAwMDQyODQ4IDAwMDAw IG4gCjAwMDAwNTY5NDQgMDAwMDAgbiAKMDAwMDA1Njk3NSAwMDAwMCBuIAowMDAwMDUzMDU5IDAw MDAwIG4gCjAwMDAwNDI4NjkgMDAwMDAgbiAKMDAwMDA0MzQyMiAwMDAwMCBuIAowMDAwMDU3MDA2 IDAwMDAwIG4gCjAwMDAwNTcwMzcgMDAwMDAgbiAKMDAwMDA1MzIyNSAwMDAwMCBuIAowMDAwMDQz NDQzIDAwMDAwIG4gCjAwMDAwNDQwMjcgMDAwMDAgbiAKMDAwMDA1NzA2OCAwMDAwMCBuIAowMDAw MDU3MDk5IDAwMDAwIG4gCjAwMDAwNTMzOTEgMDAwMDAgbiAKMDAwMDA0NDA0OCAwMDAwMCBuIAow MDAwMDQ0NTUzIDAwMDAwIG4gCjAwMDAwNTcxMzAgMDAwMDAgbiAKMDAwMDA1NzE2MSAwMDAwMCBu IAowMDAwMDUzNTU3IDAwMDAwIG4gCjAwMDAwNDQ1NzQgMDAwMDAgbiAKMDAwMDA0NTA5OSAwMDAw MCBuIAowMDAwMDU3MTkyIDAwMDAwIG4gCjAwMDAwNTcyMjMgMDAwMDAgbiAKMDAwMDA1MzcyMyAw MDAwMCBuIAowMDAwMDQ1MTIwIDAwMDAwIG4gCjAwMDAwNDU4MjYgMDAwMDAgbiAKMDAwMDA1NzI1 NCAwMDAwMCBuIAowMDAwMDU3Mjg1IDAwMDAwIG4gCjAwMDAwNTM4ODkgMDAwMDAgbiAKMDAwMDA0 NTg0NyAwMDAwMCBuIAowMDAwMDQ2NDc2IDAwMDAwIG4gCjAwMDAwNTczMTYgMDAwMDAgbiAKMDAw MDA1NzM0NyAwMDAwMCBuIAowMDAwMDU3NDU3IDAwMDAwIG4gCjAwMDAwNTc1MTcgMDAwMDAgbiAK dHJhaWxlcgo8PCAvU2l6ZSAyMzggL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lEIFs8MUIwRjc2 MDIyNzg0M0IyMjEzRjE3OUVGODE1MEVFRUE+PDFCMEY3NjAyMjc4NDNCMjIxM0YxNzlFRjgxNTBF RUVBPl0KPj4Kc3RhcnR4cmVmCjU5MTI2CiUlRU9GCgoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBH aG9zdHNjcmlwdCA5LjA0KQovQ3JlYXRpb25EYXRlKEQ6MjAxMjA4MzAxNzI5NTQtMDQnMDAnKS9U aXRsZShFbnNjcmlwdCBPdXRwdXQpCi9DcmVhdG9yKEdOVSBlbnNjcmlwdCAxLjYuNS4xKS9Nb2RE YXRlKEQ6MjAxMjEwMDMxMzMyMjkrMDInMDAnKT4+CmVuZG9iagoyMzggMCBvYmoKWzMxNzEgMyA2 NDA0MiA2NDAzNiA1OTEyNiA2NDAzMCA2NDA0MiA2NDAzNiA1OTEyNiA2NDAzMCA1OTEyNiA8MUJE REJCRTI4NTUyRjQ1QTY0RTM0NzNEQTE0RUM5RDE+IDEgMCAwIDAgMF0KZW5kb2JqCjEgMCBvYmoK PDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDIzNyAwIFIKL1BpZWNlSW5m byAyMzkgMCBSPj4KZW5kb2JqCjIzOSAwIG9iago8PAovZ3JkX0dvb2RSZWFkZXJfSW5jcmVtZW50 YWxVcGRhdGU8PC9MYXN0TW9kaWZpZWQoRDoyMDEyMTAwMzEzMzIyOSswMicwMCcpL1ByaXZhdGUg MjM4IDAgUj4+Cj4+CmVuZG9iagoyNDEgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9y bS9Gb3JtVHlwZSAxL0JCb3hbODEuMDAwIDYyMy41MDAgMjczLjAwMCA2MzQuMDUwXS9NYXRyaXhb MSAwIDAgMSAtODEuMDAwIC02MjMuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3Vy Y2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3Rh dGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJn CjgxLjAwMCA2MjMuNTAwIG0KMjczLjAwMCA2MjMuNTAwIGwKMjczLjAwMCA2MzQuMDUwIGwKODEu MDAwIDYzNC4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMjQyIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbODEuMDAwIDYyMy41MDAgMjczLjAwMCA2MzQu MDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzgxLjAwMCA2MzQuMDUwIDI3My4w MDAgNjM0LjA1MCA4MS4wMDAgNjIzLjUwMCAyNzMuMDAwIDYyMy41MDBdL0FQPDwvTiAyNDEgMCBS ID4+L00oRDoyMDEyMTAwMzEzMzIyOSswMicwMCcpL1AgNCAwIFI+PgplbmRvYmoKMjQzIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzI0My4wMDAgNjI5LjA1MCAyNzMu MDAwIDY1OS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyNDQg MCBSL0NvbnRlbnRzKE5vdyBJIGFtIG5pdHBpY2tpbmc6IEkgYmVsaWV2ZSB0aGF0IHRoZSBwcm9w ZXIgdGVybSBoZXJlIGlzICJQcm9wb3NlZCBTdGFuZGFyZCIpL00oRDoyMDEyMTAwMzEzMzIyOSsw MicwMCcpL1AgNCAwIFI+PgplbmRvYmoKMjQ0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Q b3B1cC9GIDI4L1JlY3RbMjc4LjAwMCA1NDcuMDUwIDUyOC4wMDAgNjU5LjA1MF0vUGFyZW50IDI0 MyAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA5IDAgUgovRm9udCAxMCAwIFIKPj4KL0NvbnRlbnRzIDUg MCBSL0Fubm90cyAyNDAgMCBSPj4KZW5kb2JqCjI0MCAwIG9iagpbMjQyIDAgUiAyNDMgMCBSIDI0 NCAwIFJdCmVuZG9iagp4cmVmCjAgMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNjQzNDUgMDAw MDAgbiAKMDAwMDA2NDA0MyAwMDAwMCBuIAo0IDEKMDAwMDA2NTUxOSAwMDAwMCBuIAoyMzggNwow MDAwMDY0MjIwIDAwMDAwIG4gCjAwMDAwNjQ0MjkgMDAwMDAgbiAKMDAwMDA2NTY5MiAwMDAwMCBu IAowMDAwMDY0NTQ0IDAwMDAwIG4gCjAwMDAwNjQ5MDIgMDAwMDAgbiAKMDAwMDA2NTE0MiAwMDAw MCBuIAowMDAwMDY1NDAzIDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSAyNDUvUHJldiA1OTEyNi9S b290IDEgMCBSL0luZm8gMiAwIFIvSURbPDFCMEY3NjAyMjc4NDNCMjIxM0YxNzlFRjgxNTBFRUVB Pjw3RTRFNDI2M0Y3RDY4MTFBQkNDODE5QzkwQzY0OUI0NT5dPj4Kc3RhcnR4cmVmCjY1NzM1CiUl RU9GCgoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA5LjA0KQovQ3JlYXRpb25E YXRlKEQ6MjAxMjA4MzAxNzI5NTQtMDQnMDAnKS9UaXRsZShFbnNjcmlwdCBPdXRwdXQpCi9DcmVh dG9yKEdOVSBlbnNjcmlwdCAxLjYuNS4xKS9Nb2REYXRlKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAn KT4+CmVuZG9iagoyMzggMCBvYmoKWzMxNzEgMyA2NDA0MiA2NDAzNiA1OTEyNiA2NDAzMCA2NDA0 MiA2NDAzNiA1OTEyNiA2NDAzMCA2NTczNSA8QUYyMTk3QkM5QUVFOERCQjNFQjA1RUVEMUM4QkZF NjU+IDEgMCAwIDAgMF0KZW5kb2JqCjI0NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvU3Ry aWtlT3V0L0YgNC9SZWN0WzI0OS4wMDAgNDU4LjUwMCAzMDMuMDAwIDQ2OS4wNTBdL0NbMS4wMDAg MC4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMjQ5LjAwMCA0NjkuMDUwIDMwMy4wMDAgNDY5LjA1MCAy NDkuMDAwIDQ1OC41MDAgMzAzLjAwMCA0NTguNTAwXS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMx NjI5MzQrMDInMDAnKS9QIDQgMCBSPj4KZW5kb2JqCjI0NiAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvU3RyaWtlT3V0L0YgNC9SZWN0WzMwMy4wMDAgNDU4LjUwMCAzMzkuMDAwIDQ2OS4wNTBd L0NbMS4wMDAgMC4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzAzLjAwMCA0NjkuMDUwIDMzOS4wMDAg NDY5LjA1MCAzMDMuMDAwIDQ1OC41MDAgMzM5LjAwMCA0NTguNTAwXS9UKFRDbGF1c2VuKS9NKEQ6 MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQgMCBSPj4KZW5kb2JqCjI0NyAwIG9iago8PC9UeXBl L1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs5OS4wMDAgNDAzLjUwMCAxNTMu MDAwIDQxNC4wNTBdL01hdHJpeFsxIDAgMCAxIC05OS4wMDAgLTQwMy41MDBdL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9N dWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA0Pj5zdHJlYW0KcQovUjAgZ3MK MS4wMDAgMS4wMDAgMC4wMDAgcmcKOTkuMDAwIDQwMy41MDAgbQoxNTMuMDAwIDQwMy41MDAgbAox NTMuMDAwIDQxNC4wNTAgbAo5OS4wMDAgNDE0LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoy NDggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs5OS4wMDAg NDAzLjUwMCAxNTMuMDAwIDQxNC4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNb OTkuMDAwIDQxNC4wNTAgMTUzLjAwMCA0MTQuMDUwIDk5LjAwMCA0MDMuNTAwIDE1My4wMDAgNDAz LjUwMF0vQVA8PC9OIDI0NyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAy JzAwJykvUCA0IDAgUj4+CmVuZG9iagoyNDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1Rl eHQvRiA0L1JlY3RbMTExLjAwMCA0MDkuMDUwIDE0MS4wMDAgNDM5LjA1MF0vTmFtZS9Db21tZW50 L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI1MCAwIFIvQ29udGVudHMoSSBhbSBub3Qgc3Vy ZSBJIHdvdWxkIHNheSAibmVjZXNzYXJ5IiAtIG1heWJlICJyZWNvbW1lbmRlZCIgPykvVChUQ2xh dXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA0IDAgUj4+CmVuZG9iagoyNTAgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxNDYuMDAwIDMyNy4wNTAg Mzk2LjAwMCA0MzkuMDUwXS9QYXJlbnQgMjQ5IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjI0MCAw IG9iagpbMjQyIDAgUiAyNDMgMCBSIDI0NCAwIFIgMjQ1IDAgUiAyNDYgMCBSIDI0OCAwIFIgMjQ5 IDAgUiAyNTAgMCBSXQplbmRvYmoKMjUyIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zv cm0vRm9ybVR5cGUgMS9CQm94Wzk5LjAwMCA2NDUuNTAwIDE5NS4wMDAgNjU2LjA1MF0vTWF0cml4 WzEgMCAwIDEgLTk5LjAwMCAtNjQ1LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291 cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0 YXRlPj4+Pj4+L0xlbmd0aCAxMDQ+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCBy Zwo5OS4wMDAgNjQ1LjUwMCBtCjE5NS4wMDAgNjQ1LjUwMCBsCjE5NS4wMDAgNjU2LjA1MCBsCjk5 LjAwMCA2NTYuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjI1MyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0Wzk5LjAwMCA2NDUuNTAwIDE5NS4wMDAgNjU2 LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s5OS4wMDAgNjU2LjA1MCAxOTUu MDAwIDY1Ni4wNTAgOTkuMDAwIDY0NS41MDAgMTk1LjAwMCA2NDUuNTAwXS9BUDw8L04gMjUyIDAg UiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDIxIDAgUj4+CmVu ZG9iagoyNTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDI1NSAw IFIvUmVjdFsxNjIuMDAwIDY1MS4wNTAgMTkyLjAwMCA2ODEuMDUwXS9OYW1lL0NvbW1lbnQvQ1sx LjAwMCAxLjAwMCAwLjAwMF0vQ29udGVudHMoVGhlIGFic3RyYWN0IHNwb2tlIG9ubHkgYWJvdXQg d2lyZWxlc3MuIFNob3VsZCBhYnN0cmFjdCBiZSBleHRlbmRlZCwgb3Igc2hvdWxkIHRoZSBjYWJs ZS9EU0wgZXhhbXBsZXMgZnJvbSBpbnRvIGJlIHJlbW92ZWQ/KS9UKFRDbGF1c2VuKS9NKEQ6MjAx MjEwMDMxNjI5MzQrMDInMDAnKS9QIDIxIDAgUj4+CmVuZG9iagoyNTUgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxOTcuMDAwIDU2OS4wNTAgNDQ3LjAwMCA2ODEu MDUwXS9QYXJlbnQgMjU0IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjI1NiAwIG9iago8PC9UeXBl L1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsyODUuMDAwIDYzNC41MDAgNDgz LjAwMCA2NDUuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMjg1LjAwMCAtNjM0LjUwMF0vR3JvdXA8PC9T L1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JN L011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBn cwoxLjAwMCAxLjAwMCAwLjAwMCByZwoyODUuMDAwIDYzNC41MDAgbQo0ODMuMDAwIDYzNC41MDAg bAo0ODMuMDAwIDY0NS4wNTAgbAoyODUuMDAwIDY0NS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRv YmoKMjU3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMjg1 LjAwMCA2MzQuNTAwIDQ4My4wMDAgNjQ1LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBv aW50c1syODUuMDAwIDY0NS4wNTAgNDgzLjAwMCA2NDUuMDUwIDI4NS4wMDAgNjM0LjUwMCA0ODMu MDAwIDYzNC41MDBdL0FQPDwvTiAyNTYgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2 MjkzNCswMicwMCcpL1AgMjEgMCBSPj4KZW5kb2JqCjI1OCAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvVGV4dC9GIDQvUmVjdFs0NDQuMDAwIDY0MC4wNTAgNDc0LjAwMCA2NzAuMDUwXS9OYW1l L0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMjU5IDAgUi9Db250ZW50cyhUaGUg YWJzdHJhY3Qgc3Bva2Ugb25seSBhYm91dCB3aXJlbGVzcy4gU2hvdWxkIGFic3RyYWN0IGJlIGV4 dGVuZGVkLCBvciBzaG91bGQgdGhlIGNhYmxlL0RTTCBleGFtcGxlcyBmcm9tIGludG8gYmUgcmVt b3ZlZD8pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMjEgMCBSPj4K ZW5kb2JqCjI1OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzQ3 OS4wMDAgNTU4LjA1MCA3MjkuMDAwIDY3MC4wNTBdL1BhcmVudCAyNTggMCBSL09wZW4gZmFsc2U+ PgplbmRvYmoKMjYwIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUg MS9CQm94WzQyOS4wMDAgNjAxLjUwMCA0ODkuMDAwIDYxMi4wNTBdL01hdHJpeFsxIDAgMCAxIC00 MjkuMDAwIC02MDEuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0 R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4v TGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjQyOS4wMDAg NjAxLjUwMCBtCjQ4OS4wMDAgNjAxLjUwMCBsCjQ4OS4wMDAgNjEyLjA1MCBsCjQyOS4wMDAgNjEy LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoyNjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs0MjkuMDAwIDYwMS41MDAgNDg5LjAwMCA2MTIuMDUwXS9D WzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzQyOS4wMDAgNjEyLjA1MCA0ODkuMDAwIDYx Mi4wNTAgNDI5LjAwMCA2MDEuNTAwIDQ4OS4wMDAgNjAxLjUwMF0vQVA8PC9OIDI2MCAwIFIgPj4v VChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAyMSAwIFI+PgplbmRvYmoK MjYyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAyNjMgMCBSL1Jl Y3RbNDQ0LjAwMCA2MDcuMDUwIDQ3NC4wMDAgNjM3LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAg MS4wMDAgMC4wMDBdL0NvbnRlbnRzKEFzIHRoaXMgaXMgaW4gaW50cm9kdWN0aW9uLCBwZXJoYXBz IGFkZCBzb21ldGhpbmcgYWJvdXQgd2h5IHRoaXMgaXMgXChkaWZmZXJlbnQgZGlzdGFuY2VzLCBw aHlzaWNhbCBvYnN0YWNsZXMgZXRjXCk/IEkga25vdyB0aGF0IHRoZSBzdWJzZXF1ZW50IGV4YW1w bGUgaWxsdXN0cmF0ZXMgdGhpcywgYnV0IHRoZSBwcmV2aW91cyBzZW50ZW5jZXMgcHJvdmlkZSAi YWJzdHJhY3QgcmVhc29ucyI/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAn KS9QIDIxIDAgUj4+CmVuZG9iagoyNjMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVw L0YgMjgvUmVjdFs0NzkuMDAwIDUyNS4wNTAgNzI5LjAwMCA2MzcuMDUwXS9QYXJlbnQgMjYyIDAg Ui9PcGVuIGZhbHNlPj4KZW5kb2JqCjI2NCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9G b3JtL0Zvcm1UeXBlIDEvQkJveFsxNzcuMDAwIDM4MS41MDAgMjAxLjAwMCAzOTIuMDUwXS9NYXRy aXhbMSAwIDAgMSAtMTc3LjAwMCAtMzgxLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jl c291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0 R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAw MCByZwoxNzcuMDAwIDM4MS41MDAgbQoyMDEuMDAwIDM4MS41MDAgbAoyMDEuMDAwIDM5Mi4wNTAg bAoxNzcuMDAwIDM5Mi4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMjY1IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMTc3LjAwMCAzODEuNTAwIDIwMS4w MDAgMzkyLjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxNzcuMDAwIDM5Mi4w NTAgMjAxLjAwMCAzOTIuMDUwIDE3Ny4wMDAgMzgxLjUwMCAyMDEuMDAwIDM4MS41MDBdL0FQPDwv TiAyNjQgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMjEg MCBSPj4KZW5kb2JqCjI2NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVj dFsxODMuMDAwIDM4Ny4wNTAgMjEzLjAwMCA0MTcuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAx LjAwMCAwLjAwMF0vUG9wdXAgMjY3IDAgUi9Db250ZW50cyhUaGUgUkZDIGVkaXRvciB1c2VzOlxu XG4JIi4uLmJsYWggYmxhaCwgZS5nLiwgYmxhaCBibGFoIlxuXG5hbmRcbgkiLi4uYmxhaCBibGFo LCBpLmUuLCBibGFoIGJsYWgiXG5cblJlY29tbWVuZCBtYWtpbmcgdGhlaXIgbGlmZSBlYXNpZXIg XChhbmQgcmVkdWNpbmcgdGhlaXIgcHJvY2Vzc2luZyB0aW1lXCkgYnkganVzdCBkb2luZyB0aGlz IGZyb20gdGhlIHN0YXJ0IDtcKSkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAw JykvUCAyMSAwIFI+PgplbmRvYmoKMjY3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1 cC9GIDI4L1JlY3RbMjE4LjAwMCAzMDUuMDUwIDQ2OC4wMDAgNDE3LjA1MF0vUGFyZW50IDI2NiAw IFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyNjggMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv Rm9ybS9Gb3JtVHlwZSAxL0JCb3hbNDM1LjAwMCAzNDguNTAwIDQ0Ny4wMDAgMzU5LjA1MF0vTWF0 cml4WzEgMCAwIDEgLTQzNS4wMDAgLTM0OC41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9S ZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4 dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4w MDAgcmcKNDM1LjAwMCAzNDguNTAwIG0KNDQ3LjAwMCAzNDguNTAwIGwKNDQ3LjAwMCAzNTkuMDUw IGwKNDM1LjAwMCAzNTkuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjI2OSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzQzNS4wMDAgMzQ4LjUwMCA0NDcu MDAwIDM1OS4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbNDM1LjAwMCAzNTku MDUwIDQ0Ny4wMDAgMzU5LjA1MCA0MzUuMDAwIDM0OC41MDAgNDQ3LjAwMCAzNDguNTAwXS9BUDw8 L04gMjY4IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDIx IDAgUj4+CmVuZG9iagoyNzAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1Jl Y3RbNDIzLjAwMCAzNTQuMDUwIDQ1My4wMDAgMzg0LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAg MS4wMDAgMC4wMDBdL1BvcHVwIDI3MSAwIFIvQ29udGVudHMoc3VnZ2VzdDpcbgkiZXhjbHVzaXZl bHkgZGV0ZWN0ZWQgIGJ5IHdheSBvZiBhIikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0 KzAyJzAwJykvUCAyMSAwIFI+PgplbmRvYmoKMjcxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9Qb3B1cC9GIDI4L1JlY3RbNDU4LjAwMCAyNzIuMDUwIDcwOC4wMDAgMzg0LjA1MF0vUGFyZW50 IDI3MCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyNzIgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1 YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbNDQxLjAwMCAyNDkuNTAwIDQ2NS4wMDAgMjYwLjA1 MF0vTWF0cml4WzEgMCAwIDEgLTQ0MS4wMDAgLTI0OS41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVu Y3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9U eXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4w MDAgMC4wMDAgcmcKNDQxLjAwMCAyNDkuNTAwIG0KNDY1LjAwMCAyNDkuNTAwIGwKNDY1LjAwMCAy NjAuMDUwIGwKNDQxLjAwMCAyNjAuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjI3MyAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzQ0MS4wMDAgMjQ5LjUw MCA0NjUuMDAwIDI2MC4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbNDQxLjAw MCAyNjAuMDUwIDQ2NS4wMDAgMjYwLjA1MCA0NDEuMDAwIDI0OS41MDAgNDY1LjAwMCAyNDkuNTAw XS9BUDw8L04gMjcyIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAn KS9QIDIxIDAgUj4+CmVuZG9iagoyNzQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQv RiA0L1JlY3RbNDQ3LjAwMCAyNTUuMDUwIDQ3Ny4wMDAgMjg1LjA1MF0vTmFtZS9Db21tZW50L0Nb MS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI3NSAwIFIvQ29udGVudHMoZS5nLiwpL1QoVENsYXVz ZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMjEgMCBSPj4KZW5kb2JqCjI3NSAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzQ4Mi4wMDAgMTczLjA1MCA3 MzIuMDAwIDI4NS4wNTBdL1BhcmVudCAyNzQgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMjEgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDI0IDAgUgov Rm9udCAyNSAwIFIKPj4KL0NvbnRlbnRzIDIyIDAgUi9Bbm5vdHMgMjUxIDAgUj4+CmVuZG9iagoy NTEgMCBvYmoKWzI1MyAwIFIgMjU0IDAgUiAyNTUgMCBSIDI1NyAwIFIgMjU4IDAgUiAyNTkgMCBS IDI2MSAwIFIgMjYyIDAgUiAyNjMgMCBSIDI2NSAwIFIgMjY2IDAgUiAyNjcgMCBSIDI2OSAwIFIg MjcwIDAgUiAyNzEgMCBSIDI3MyAwIFIgMjc0IDAgUiAyNzUgMCBSXQplbmRvYmoKMjc3IDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzQ0MS4wMDAgNjE4LjA1MCA0NzEu MDAwIDY0OC4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyNzgg MCBSL0NvbnRlbnRzKHN1Z2dlc3QgYWRkaW5nOlxuCSJpcyBhIHNpZ25hbGluZyBwcm90b2NvbCB0 aGF0IikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAyNiAwIFI+Pgpl bmRvYmoKMjc4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNDc2 LjAwMCA1MzYuMDUwIDcyNi4wMDAgNjQ4LjA1MF0vUGFyZW50IDI3NyAwIFIvT3BlbiBmYWxzZT4+ CmVuZG9iagoyNzkgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAx L0JCb3hbMzc1LjAwMCA2MTIuNTAwIDQ1My4wMDAgNjIzLjA1MF0vTWF0cml4WzEgMCAwIDEgLTM3 NS4wMDAgLTYxMi41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRH U3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9M ZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzc1LjAwMCA2 MTIuNTAwIG0KNDUzLjAwMCA2MTIuNTAwIGwKNDUzLjAwMCA2MjMuMDUwIGwKMzc1LjAwMCA2MjMu MDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjI4MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzM3NS4wMDAgNjEyLjUwMCA0NTMuMDAwIDYyMy4wNTBdL0Nb MS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzc1LjAwMCA2MjMuMDUwIDQ1My4wMDAgNjIz LjA1MCAzNzUuMDAwIDYxMi41MDAgNDUzLjAwMCA2MTIuNTAwXS9BUDw8L04gMjc5IDAgUiA+Pi9U KFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDI2IDAgUj4+CmVuZG9iagoy ODEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzcyLjAwMCA2MTgu MDUwIDQwMi4wMDAgNjQ4LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1Bv cHVwIDI4MiAwIFIvQ29udGVudHMoQXMgRExFUCBpcyAiRGF0YSBMaW5rIEV4Y2hhbmdlIFByb3Rv Y29sIiwgc2F5aW5nICJETEVQIFByb3RvY29sIiBpcyByZWR1bmRhbnQ6IGV4cGFuZGVkIGl0IGJl Y29tZXMgIkRhdGEgTGluayBFeGNoYW5nZSBQcm90b2NvbCBQcm90b2NvbCIuXG5cblN1Z2dlc3Qg c2F5aW5nICJETEVQIGlzIGEgLi4uLiIgaW5zdGVhZCBvZiAidGhlIERMRVAgcHJvdG9jb2wgaXMg YSAuLi4uIikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAyNiAwIFI+ PgplbmRvYmoKMjgyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3Rb NDA3LjAwMCA1MzYuMDUwIDY1Ny4wMDAgNjQ4LjA1MF0vUGFyZW50IDI4MSAwIFIvT3BlbiBmYWxz ZT4+CmVuZG9iagoyODMgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlw ZSAxL0JCb3hbMzAzLjAwMCAyNjAuNTAwIDM3NS4wMDAgMjcxLjA1MF0vTWF0cml4WzEgMCAwIDEg LTMwMy4wMDAgLTI2MC41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9F eHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+ Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzAzLjAw MCAyNjAuNTAwIG0KMzc1LjAwMCAyNjAuNTAwIGwKMzc1LjAwMCAyNzEuMDUwIGwKMzAzLjAwMCAy NzEuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjI4NCAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzMwMy4wMDAgMjYwLjUwMCAzNzUuMDAwIDI3MS4wNTBd L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzAzLjAwMCAyNzEuMDUwIDM3NS4wMDAg MjcxLjA1MCAzMDMuMDAwIDI2MC41MDAgMzc1LjAwMCAyNjAuNTAwXS9BUDw8L04gMjgzIDAgUiA+ Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDI2IDAgUj4+CmVuZG9i agoyODUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzAwLjAwMCAy NjYuMDUwIDMzMC4wMDAgMjk2LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBd L1BvcHVwIDI4NiAwIFIvQ29udGVudHMoQXMgRExFUCBpcyAiRGF0YSBMaW5rIEV4Y2hhbmdlIFBy b3RvY29sIiwgc2F5aW5nICJETEVQIFByb3RvY29sIiBpcyByZWR1bmRhbnQ6IGV4cGFuZGVkIGl0 IGJlY29tZXMgIkRhdGEgTGluayBFeGNoYW5nZSBQcm90b2NvbCBQcm90b2NvbCIuXG5cblN1Z2dl c3Qgc2F5aW5nICJETEVQIGlzIGEgLi4uLiIgaW5zdGVhZCBvZiAidGhlIERMRVAgcHJvdG9jb2wg aXMgYSAuLi4uIikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAyNiAw IFI+PgplbmRvYmoKMjg2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1Jl Y3RbMzM1LjAwMCAxODQuMDUwIDU4NS4wMDAgMjk2LjA1MF0vUGFyZW50IDI4NSAwIFIvT3BlbiBm YWxzZT4+CmVuZG9iagoyODcgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3Jt VHlwZSAxL0JCb3hbMjY3LjAwMCA0NTguNTAwIDI5MS4wMDAgNDY5LjA1MF0vTWF0cml4WzEgMCAw IDEgLTI2Ny4wMDAgLTQ1OC41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8 PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+ Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMjY3 LjAwMCA0NTguNTAwIG0KMjkxLjAwMCA0NTguNTAwIGwKMjkxLjAwMCA0NjkuMDUwIGwKMjY3LjAw MCA0NjkuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjI4OCAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzI2Ny4wMDAgNDU4LjUwMCAyOTEuMDAwIDQ2OS4w NTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMjY3LjAwMCA0NjkuMDUwIDI5MS4w MDAgNDY5LjA1MCAyNjcuMDAwIDQ1OC41MDAgMjkxLjAwMCA0NTguNTAwXS9BUDw8L04gMjg3IDAg UiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDI2IDAgUj4+CmVu ZG9iagoyODkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMjY0LjAw MCA0NjQuMDUwIDI5NC4wMDAgNDk0LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4w MDBdL1BvcHVwIDI5MCAwIFIvQ29udGVudHMoVGhlIFJGQyBlZGl0b3IgdXNlczpcblxuCSIuLi5i bGFoIGJsYWgsIGUuZy4sIGJsYWggYmxhaCJcblxuYW5kXG4JIi4uLmJsYWggYmxhaCwgaS5lLiwg YmxhaCBibGFoIlxuXG5SZWNvbW1lbmQgbWFraW5nIHRoZWlyIGxpZmUgZWFzaWVyIFwoYW5kIHJl ZHVjaW5nIHRoZWlyIHByb2Nlc3NpbmcgdGltZVwpIGJ5IGp1c3QgZG9pbmcgdGhpcyBmcm9tIHRo ZSBzdGFydCA7XCkpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMjYg MCBSPj4KZW5kb2JqCjI5MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9S ZWN0WzI5OS4wMDAgMzgyLjA1MCA1NDkuMDAwIDQ5NC4wNTBdL1BhcmVudCAyODkgMCBSL09wZW4g ZmFsc2U+PgplbmRvYmoKMjkyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9S ZWN0WzgxLjAwMCAxNjcuMDUwIDExMS4wMDAgMTk3LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAg MS4wMDAgMC4wMDBdL1BvcHVwIDI5MyAwIFIvQ29udGVudHMoWW91IHNob3VsZCBtYWtlIGl0IHN1 Y2ggdGhhdCBmaWd1cmVzIGRvIG5vdCBzcGxpdCBhY3Jvc3MgdHdvIHBhZ2VzLiBJbiB4bWwsIGFk ZCBhIDx2c3BhY2UgYmxhbmtMaW5lcz0iOTk5Ii8+IGJlZm9yZSB0aGlzIGZpZ3VyZSBcKGJ1dCBJ IHRoaW5rIHlvdSB1c2UgbnJvZmYgLSBJIGZvcmdldCBob3cgb25lIGRvZXMgdGhlcmU/XCkpL1Qo VENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMjYgMCBSPj4KZW5kb2JqCjI5 MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzExNi4wMDAgODUu MDUwIDM2Ni4wMDAgMTk3LjA1MF0vUGFyZW50IDI5MiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoy OTQgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMzAz LjAwMCAyMzguNTAwIDM3NS4wMDAgMjQ5LjA1MF0vTWF0cml4WzEgMCAwIDEgLTMwMy4wMDAgLTIz OC41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9S MDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2 Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzAzLjAwMCAyMzguNTAwIG0K Mzc1LjAwMCAyMzguNTAwIGwKMzc1LjAwMCAyNDkuMDUwIGwKMzAzLjAwMCAyNDkuMDUwIGwKZgpR CgplbmRzdHJlYW0KZW5kb2JqCjI5NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxp Z2h0L0YgNC9SZWN0WzMwMy4wMDAgMjM4LjUwMCAzNzUuMDAwIDI0OS4wNTBdL0NbMS4wMDAgMS4w MDAgMC4wMDBdL1F1YWRQb2ludHNbMzAzLjAwMCAyNDkuMDUwIDM3NS4wMDAgMjQ5LjA1MCAzMDMu MDAwIDIzOC41MDAgMzc1LjAwMCAyMzguNTAwXS9BUDw8L04gMjk0IDAgUiA+Pi9UKFRDbGF1c2Vu KS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDI2IDAgUj4+CmVuZG9iagoyOTggMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzI0LjAwMCAyNDQuMDUwIDM1NC4w MDAgMjc0LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI5OSAw IFIvQ29udGVudHMoQXQgdGhpcyBwb2ludCwgdGhlIG5vdGlvbiBvZiAic2Vzc2lvbiIgaXNuJ3Qg aW50cm9kdWNlZCB5ZXQsIHNvIHRoaXMgaXMgY29uZnVzaW5nLikvVChUQ2xhdXNlbikvTShEOjIw MTIxMDAzMTYyOTM0KzAyJzAwJykvUCAyNiAwIFI+PgplbmRvYmoKMjk5IDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzU5LjAwMCAxNjIuMDUwIDYwOS4wMDAgMjc0 LjA1MF0vUGFyZW50IDI5OCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyNiAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjkgMCBSCi9Gb250IDMwIDAg Ugo+PgovQ29udGVudHMgMjcgMCBSL0Fubm90cyAyNzYgMCBSPj4KZW5kb2JqCjI3NiAwIG9iagpb Mjc3IDAgUiAyNzggMCBSIDI4MCAwIFIgMjgxIDAgUiAyODIgMCBSIDI4NCAwIFIgMjg1IDAgUiAy ODYgMCBSIDI4OCAwIFIgMjg5IDAgUiAyOTAgMCBSIDI5MiAwIFIgMjkzIDAgUiAyOTUgMCBSIDI5 OCAwIFIgMjk5IDAgUl0KZW5kb2JqCjMwMiAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9G b3JtL0Zvcm1UeXBlIDEvQkJveFs5OS4wMDAgMzQ4LjUwMCAxNDEuMDAwIDM1OS4wNTBdL01hdHJp eFsxIDAgMCAxIC05OS4wMDAgLTM0OC41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNv dXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdT dGF0ZT4+Pj4+Pi9MZW5ndGggMTA0Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAg cmcKOTkuMDAwIDM0OC41MDAgbQoxNDEuMDAwIDM0OC41MDAgbAoxNDEuMDAwIDM1OS4wNTAgbAo5 OS4wMDAgMzU5LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagozMDMgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs5OS4wMDAgMzQ4LjUwMCAxNDEuMDAwIDM1 OS4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbOTkuMDAwIDM1OS4wNTAgMTQx LjAwMCAzNTkuMDUwIDk5LjAwMCAzNDguNTAwIDE0MS4wMDAgMzQ4LjUwMF0vQVA8PC9OIDMwMiAw IFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAzMSAwIFI+Pgpl bmRvYmoKMzA0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzEwNS4w MDAgMzU0LjA1MCAxMzUuMDAwIDM4NC4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAu MDAwXS9Qb3B1cCAzMDcgMCBSL0NvbnRlbnRzKERvIHlvdSBtZWFuICJjaGFuZ2VkIGNoYXJhY3Rl cmlzdGljcyIsIG9yIGRvIHlvdSBtZWFuICJ0aGUgc2V0IG9mIGludGVyZmFjZXMsIGZvcm1pbmcg dGhlIGxpbmssIGhhcyBjaGFuZ2VkIG1lbWJlcnMiPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAz MTYyOTM0KzAyJzAwJykvUCAzMSAwIFI+PgplbmRvYmoKMzA3IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTQwLjAwMCAyNzIuMDUwIDM5MC4wMDAgMzg0LjA1MF0v UGFyZW50IDMwNCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMDggMCBvYmoKPDwvVHlwZS9YT2Jq ZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMTk1LjAwMCAxOTQuNTAwIDIxOS4wMDAg MjA1LjA1MF0vTWF0cml4WzEgMCAwIDEgLTE5NS4wMDAgLTE5NC41MDBdL0dyb3VwPDwvUy9UcmFu c3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0 aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4w MDAgMS4wMDAgMC4wMDAgcmcKMTk1LjAwMCAxOTQuNTAwIG0KMjE5LjAwMCAxOTQuNTAwIGwKMjE5 LjAwMCAyMDUuMDUwIGwKMTk1LjAwMCAyMDUuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjMw OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzE5NS4wMDAg MTk0LjUwMCAyMTkuMDAwIDIwNS4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNb MTk1LjAwMCAyMDUuMDUwIDIxOS4wMDAgMjA1LjA1MCAxOTUuMDAwIDE5NC41MDAgMjE5LjAwMCAx OTQuNTAwXS9BUDw8L04gMzA4IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQr MDInMDAnKS9QIDMxIDAgUj4+CmVuZG9iagozMTAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L1RleHQvRiA0L1BvcHVwIDMxMSAwIFIvUmVjdFsxOTIuMDAwIDIwMC4wNTAgMjIyLjAwMCAyMzAu MDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29udGVudHMoWW91IGhhdmUg bm90IHlldCBkZWZpbmVkIFJGQzIxMTkgcmVxdWlyZW1lbnRzIGxhbmd1YWdlLiBJbiBnZW5lcmFs LCBJIHRoaW5rIHRoYXQgaW50cm9kdWN0aW9ucyBhcmUgbm9uLW5vcm1hdGl2ZSwgYW5kIHNvIHVz ZSBvZiAyMTE5LWxhbmd1YWdlIHRoZXJlaW4gaXMgbm90IHJlY29tbWVuZGVkLiBTdWdnZXN0ICJh cmUgZXhwZWN0ZWQgdG8iIGZvciBNVVNUIGFuZCAiY2FuIiBmb3IgTUFZIGluIHRoZSBpbnRyb2R1 Y3Rpb24/XG5cbkFuZCwgb2YgY291cnNlLCBtYWtlIHN1cmUgdGhhdCB0aGVzZSBub3JtYXRpdmUg cmVxdWlyZW1lbnRzIGFyZSBjYWxsZWQgb3V0IGluIHRoZSBub3JtYXRpdmUgcGFydHMgb2YgdGhl IHNwZWNpZmljYXRpb24uKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9Q IDMxIDAgUj4+CmVuZG9iagozMTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0Yg MjgvUmVjdFsyMjcuMDAwIDExOC4wNTAgNDc3LjAwMCAyMzAuMDUwXS9QYXJlbnQgMzEwIDAgUi9P cGVuIGZhbHNlPj4KZW5kb2JqCjMxMiAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3Jt L0Zvcm1UeXBlIDEvQkJveFs0ODkuMDAwIDE4My41MDAgNTA3LjAwMCAxOTQuMDUwXS9NYXRyaXhb MSAwIDAgMSAtNDg5LjAwMCAtMTgzLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291 cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0 YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCBy Zwo0ODkuMDAwIDE4My41MDAgbQo1MDcuMDAwIDE4My41MDAgbAo1MDcuMDAwIDE5NC4wNTAgbAo0 ODkuMDAwIDE5NC4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzEzIDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbNDg5LjAwMCAxODMuNTAwIDUwNy4wMDAg MTk0LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s0ODkuMDAwIDE5NC4wNTAg NTA3LjAwMCAxOTQuMDUwIDQ4OS4wMDAgMTgzLjUwMCA1MDcuMDAwIDE4My41MDBdL0FQPDwvTiAz MTIgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMzEgMCBS Pj4KZW5kb2JqCjMxNCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs0 ODMuMDAwIDE4OS4wNTAgNTEzLjAwMCAyMTkuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAw MCAwLjAwMF0vUG9wdXAgMzE2IDAgUi9Db250ZW50cyhZb3UgaGF2ZSBub3QgeWV0IGRlZmluZWQg UkZDMjExOSByZXF1aXJlbWVudHMgbGFuZ3VhZ2UuIEluIGdlbmVyYWwsIEkgdGhpbmsgdGhhdCBp bnRyb2R1Y3Rpb25zIGFyZSBub24tbm9ybWF0aXZlLCBhbmQgc28gdXNlIG9mIDIxMTktbGFuZ3Vh Z2UgdGhlcmVpbiBpcyBub3QgcmVjb21tZW5kZWQuIFN1Z2dlc3QgImFyZSBleHBlY3RlZCB0byIg Zm9yIE1VU1QgYW5kICJjYW4iIGZvciBNQVkgaW4gdGhlIGludHJvZHVjdGlvbj9cblxuQW5kLCBv ZiBjb3Vyc2UsIG1ha2Ugc3VyZSB0aGF0IHRoZXNlIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgYXJl IGNhbGxlZCBvdXQgaW4gdGhlIG5vcm1hdGl2ZSBwYXJ0cyBvZiB0aGUgc3BlY2lmaWNhdGlvbi4p L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMzEgMCBSPj4KZW5kb2Jq CjMxNiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzUxOC4wMDAg MTA3LjA1MCA3NjguMDAwIDIxOS4wNTBdL1BhcmVudCAzMTQgMCBSL09wZW4gZmFsc2U+PgplbmRv YmoKMzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDM0IDAgUgovRm9udCAzNSAwIFIKPj4KL0NvbnRlbnRzIDMyIDAgUi9Bbm5vdHMgMzAwIDAgUj4+ CmVuZG9iagozMDAgMCBvYmoKWzMwMyAwIFIgMzA0IDAgUiAzMDcgMCBSIDMwOSAwIFIgMzEwIDAg UiAzMTEgMCBSIDMxMyAwIFIgMzE0IDAgUiAzMTYgMCBSXQplbmRvYmoKMzE4IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAzMTkgMCBSL1JlY3RbMzAzLjAwMCAzNjUu MDUwIDMzMy4wMDAgMzk1LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0Nv bnRlbnRzKFRoZXJlIGlzIGFuIFJGQzIxMTkgZXJyYXRhLCB0aGF0IHN0aXB1bGF0ZXMgdGhhdCBh bHNvICJOT1QgUkVDT01NRU5ERUQiIGJlIGluY2x1ZGVkIGluIHRoaXMgcGFyYWdyYXBoLlxuXG5T ZWUgaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9MjExOSkv VChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAzNiAwIFI+PgplbmRvYmoK MzE5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzM4LjAwMCAy ODMuMDUwIDU4OC4wMDAgMzk1LjA1MF0vUGFyZW50IDMxOCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9i agozMjAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hb MzkzLjAwMCA2NTYuNTAwIDQxNy4wMDAgNjY3LjA1MF0vTWF0cml4WzEgMCAwIDEgLTM5My4wMDAg LTY1Ni41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8 PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGgg MTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzkzLjAwMCA2NTYuNTAw IG0KNDE3LjAwMCA2NTYuNTAwIGwKNDE3LjAwMCA2NjcuMDUwIGwKMzkzLjAwMCA2NjcuMDUwIGwK ZgpRCgplbmRzdHJlYW0KZW5kb2JqCjMyMSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGln aGxpZ2h0L0YgNC9SZWN0WzM5My4wMDAgNjU2LjUwMCA0MTcuMDAwIDY2Ny4wNTBdL0NbMS4wMDAg MS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzkzLjAwMCA2NjcuMDUwIDQxNy4wMDAgNjY3LjA1MCAz OTMuMDAwIDY1Ni41MDAgNDE3LjAwMCA2NTYuNTAwXS9BUDw8L04gMzIwIDAgUiA+Pi9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDM2IDAgUj4+CmVuZG9iagozMjIgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDMyMyAwIFIvUmVjdFszOTAu MDAwIDY2Mi4wNTAgNDIwLjAwMCA2OTIuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAw LjAwMF0vQ29udGVudHMoWW91IGhhdmUgbm90IHlldCBkZWZpbmVkIFJGQzIxMTkgcmVxdWlyZW1l bnRzIGxhbmd1YWdlLiBJbiBnZW5lcmFsLCBJIHRoaW5rIHRoYXQgaW50cm9kdWN0aW9ucyBhcmUg bm9uLW5vcm1hdGl2ZSwgYW5kIHNvIHVzZSBvZiAyMTE5LWxhbmd1YWdlIHRoZXJlaW4gaXMgbm90 IHJlY29tbWVuZGVkLiBTdWdnZXN0ICJhcmUgZXhwZWN0ZWQgdG8iIGZvciBNVVNUIGFuZCAiY2Fu IiBmb3IgTUFZIGluIHRoZSBpbnRyb2R1Y3Rpb24/XG5cbkFuZCwgb2YgY291cnNlLCBtYWtlIHN1 cmUgdGhhdCB0aGVzZSBub3JtYXRpdmUgcmVxdWlyZW1lbnRzIGFyZSBjYWxsZWQgb3V0IGluIHRo ZSBub3JtYXRpdmUgcGFydHMgb2YgdGhlIHNwZWNpZmljYXRpb24uKS9UKFRDbGF1c2VuKS9NKEQ6 MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDM2IDAgUj4+CmVuZG9iagozMjMgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0MjUuMDAwIDU4MC4wNTAgNjc1LjAwMCA2 OTIuMDUwXS9QYXJlbnQgMzIyIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjMyNCAwIG9iago8PC9U eXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs0NDEuMDAwIDYyMy41MDAg NDY1LjAwMCA2MzQuMDUwXS9NYXRyaXhbMSAwIDAgMSAtNDQxLjAwMCAtNjIzLjUwMF0vR3JvdXA8 PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNl L0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9S MCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwo0NDEuMDAwIDYyMy41MDAgbQo0NjUuMDAwIDYyMy41 MDAgbAo0NjUuMDAwIDYzNC4wNTAgbAo0NDEuMDAwIDYzNC4wNTAgbApmClEKCmVuZHN0cmVhbQpl bmRvYmoKMzI1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3Rb NDQxLjAwMCA2MjMuNTAwIDQ2NS4wMDAgNjM0LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVh ZFBvaW50c1s0NDEuMDAwIDYzNC4wNTAgNDY1LjAwMCA2MzQuMDUwIDQ0MS4wMDAgNjIzLjUwMCA0 NjUuMDAwIDYyMy41MDBdL0FQPDwvTiAzMjQgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAw MzE2MjkzNCswMicwMCcpL1AgMzYgMCBSPj4KZW5kb2JqCjMyNiAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs0MzguMDAwIDYyOS4wNTAgNDY4LjAwMCA2NTkuMDUwXS9O YW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzI3IDAgUi9Db250ZW50cyhZ b3UgaGF2ZSBub3QgeWV0IGRlZmluZWQgUkZDMjExOSByZXF1aXJlbWVudHMgbGFuZ3VhZ2UuIElu IGdlbmVyYWwsIEkgdGhpbmsgdGhhdCBpbnRyb2R1Y3Rpb25zIGFyZSBub24tbm9ybWF0aXZlLCBh bmQgc28gdXNlIG9mIDIxMTktbGFuZ3VhZ2UgdGhlcmVpbiBpcyBub3QgcmVjb21tZW5kZWQuIFN1 Z2dlc3QgImFyZSBleHBlY3RlZCB0byIgZm9yIE1VU1QgYW5kICJjYW4iIGZvciBNQVkgaW4gdGhl IGludHJvZHVjdGlvbj9cblxuQW5kLCBvZiBjb3Vyc2UsIG1ha2Ugc3VyZSB0aGF0IHRoZXNlIG5v cm1hdGl2ZSByZXF1aXJlbWVudHMgYXJlIGNhbGxlZCBvdXQgaW4gdGhlIG5vcm1hdGl2ZSBwYXJ0 cyBvZiB0aGUgc3BlY2lmaWNhdGlvbi4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCsw MicwMCcpL1AgMzYgMCBSPj4KZW5kb2JqCjMyNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv UG9wdXAvRiAyOC9SZWN0WzQ3My4wMDAgNTQ3LjA1MCA3MjMuMDAwIDY1OS4wNTBdL1BhcmVudCAz MjYgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMzI4IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzExMS4wMDAgMzkyLjUwMCAxODMuMDAwIDQwMy4wNTBd L01hdHJpeFsxIDAgMCAxIC0xMTEuMDAwIC0zOTIuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5 Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlw ZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAw IDAuMDAwIHJnCjExMS4wMDAgMzkyLjUwMCBtCjE4My4wMDAgMzkyLjUwMCBsCjE4My4wMDAgNDAz LjA1MCBsCjExMS4wMDAgNDAzLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagozMjkgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsxMTEuMDAwIDM5Mi41MDAg MTgzLjAwMCA0MDMuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzExMS4wMDAg NDAzLjA1MCAxODMuMDAwIDQwMy4wNTAgMTExLjAwMCAzOTIuNTAwIDE4My4wMDAgMzkyLjUwMF0v QVA8PC9OIDMyOCAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykv UCAzNiAwIFI+PgplbmRvYmoKMzMxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0Yg NC9SZWN0WzEzMi4wMDAgMzk4LjA1MCAxNjIuMDAwIDQyOC4wNTBdL05hbWUvQ29tbWVudC9DWzEu MDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzMzIgMCBSL0NvbnRlbnRzKEkgd291bGQgcmVjb21tZW5k IHRoYXQgc2VjdGlvbiAxLjEgYmUgcHJvbW90ZWQgdG8gYSB0b3AtbGV2ZWwgc2VjdGlvbiAyLCBh bmQgdGl0bGVkICJUZXJtaW5vbG9neSIuXG5cbkkgd291bGQsIHRoZW4sIGFsc28gcmVjb21tZW5k IGFjdHVhbGx5IGRlZmluaW5nIHRoZSB0ZXJtaW5vbG9neSB1c2VkIFwoc2Vzc2lvbiwgcGVlciwg Li4uLlwpIGluIHRoYXQgc2VjdGlvbi5cblxuRExFUCBpbnRyb2R1Y2VzIGFuZCB1c2VzIGEgd2hv bGUgc2xldyBvZiB0ZXJtaW5vbG9neSwgYW5kIEkga25vdyB0aGF0IGl0IHdvdWxkIGhhdmUgaGVs cGVkIG1lIGdyZWF0bHkgaGFkIHRoZXJlIGJlZW4gYSBzaW5nbGUgY2VudHJhbCBwbGFjZSBmb3Ig bWUgdG8gZ28gbG9vayB0aGF0IHVwIGFzIEkgcmVhZCB0aGUgZG9jdW1lbnQuIEFzIGl0IGlzLCBJ IGhhZCB0byBzZWFyY2ggdGhyb3VnaCB0byBmaW5kIFwoYXQgdGltZXMsIHBhcnRpYWxcKSBkZWZp bml0aW9ucyBvZiBhIGdpdmVuIHRlcm0uXG5cbkkgYmVsaWV2ZSB0aGF0IGNvbXBsZXRlbHkgZGVm aW5pbmcgaW4gYSBjZW50cmFsIHBsYWNlLCBhbmQgdGhlbiBjb25zaXN0ZW50bHkgdXNpbmcgdGhy b3VnaCB0aGUgZG9jdW1lbnQsIHRoZSB0ZXJtaW5vbG9neSBpcyBhIGdyZWF0IGhlbHAgZm9yIHRo ZSByZWFkZXIsIGFuZCBpcyBhIGdvb2Qgd2F5IGFsc28gdG8gZW5zdXJlIHRoYXQgb25lIGlzIGNv bnNpc3RlbnQgYW5kIGNvcnJlY3Qgd2hlbiB3cml0aW5nIHRoZSBzcGVjLikvVChUQ2xhdXNlbikv TShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAzNiAwIFI+PgplbmRvYmoKMzMyIDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTY3LjAwMCAzMTYuMDUwIDQxNy4w MDAgNDI4LjA1MF0vUGFyZW50IDMzMSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMzMgMCBvYmoK PDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbOTkuMDAwIDIzOC41 MDAgMTIzLjAwMCAyNDkuMDUwXS9NYXRyaXhbMSAwIDAgMSAtOTkuMDAwIC0yMzguNTAwXS9Hcm91 cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFs c2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEK L1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjk5LjAwMCAyMzguNTAwIG0KMTIzLjAwMCAyMzgu NTAwIGwKMTIzLjAwMCAyNDkuMDUwIGwKOTkuMDAwIDI0OS4wNTAgbApmClEKCmVuZHN0cmVhbQpl bmRvYmoKMzM1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3Rb OTkuMDAwIDIzOC41MDAgMTIzLjAwMCAyNDkuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFk UG9pbnRzWzk5LjAwMCAyNDkuMDUwIDEyMy4wMDAgMjQ5LjA1MCA5OS4wMDAgMjM4LjUwMCAxMjMu MDAwIDIzOC41MDBdL0FQPDwvTiAzMzMgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2 MjkzNCswMicwMCcpL1AgMzYgMCBSPj4KZW5kb2JqCjMzNiAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvVGV4dC9GIDQvUG9wdXAgMzM3IDAgUi9SZWN0Wzk2LjAwMCAyNDQuMDUwIDEyNi4wMDAg Mjc0LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKFN1Z2dl c3Q6XG5cbiJUbyBicmVhayB0aGlzIHJhY2UgY29uZGl0aW9uIHdoZW4gaXQgb2NjdXJzLCAuLi4u IlxuXG5TbyBhcyB0byByZW5kZXIgY3J5c3RhbCBjbGVhciB0aGF0IERMRVAgZG9lcyBhY3R1YWxs eSByZWNvdmVyLlxuXG5TaG91bGQgaXQgbm90IGJlIHN0YXRlZCBob3cgYSByb3V0ZXIgZGlzY292 ZXJzIHRoYXQgYSByYWNlIGNvbmRpdGlvbiBpcyBoYXBwZW5pbmc/XG5cbkV2ZW4gbW9yZXNvLCBp cyB0aGlzIHJlYWxseSBhbiAiQXNzdW1wdGlvbiIgXChhcyB0aGUgc2VjdGlvbiBoZWFkaW5nIHN0 YXRlc1wpPyBJIHdvdWxkIHRoaW5rIHRoYXQgaXQgaXMgYW4gaW50ZWdyYWwgcGFydCBvZiB0aGUg RExFUCBkZXNpZ24/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDM2 IDAgUj4+CmVuZG9iagozMzcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgv UmVjdFsxMzEuMDAwIDE2Mi4wNTAgMzgxLjAwMCAyNzQuMDUwXS9QYXJlbnQgMzM2IDAgUi9PcGVu IGZhbHNlPj4KZW5kb2JqCjMzOSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zv cm1UeXBlIDEvQkJveFs5OS4wMDAgMjA1LjUwMCAzNTEuMDAwIDIxNi4wNTBdL01hdHJpeFsxIDAg MCAxIC05OS4wMDAgLTIwNS41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8 PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+ Pj4+Pi9MZW5ndGggMTA0Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKOTku MDAwIDIwNS41MDAgbQozNTEuMDAwIDIwNS41MDAgbAozNTEuMDAwIDIxNi4wNTAgbAo5OS4wMDAg MjE2LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagozNDAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs5OS4wMDAgMjA1LjUwMCAzNTEuMDAwIDIxNi4wNTBd L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbOTkuMDAwIDIxNi4wNTAgMzUxLjAwMCAy MTYuMDUwIDk5LjAwMCAyMDUuNTAwIDM1MS4wMDAgMjA1LjUwMF0vQVA8PC9OIDMzOSAwIFIgPj4v VChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAzNiAwIFI+PgplbmRvYmoK MzQxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAzNDIgMCBSL1Jl Y3RbMjEwLjAwMCAyMTEuMDUwIDI0MC4wMDAgMjQxLjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAg MS4wMDAgMC4wMDBdL0NvbnRlbnRzKFRoaXMgaXMgbm90IHJlYWxseSBhbiBhc3N1bXB0aW9uIGVp dGhlci4gSSB0aGluayB0aGF0IHRoaXMgc2VjdGlvbiBzaG91bGQgYmUgYmV0dGVyIHRpdGxlZCAi RGVzaWduIFByaW5jaXBsZXMiIG9yIHNvbWV0aGluZywgYXMgdGhlcmUncyBub3RoaW5nIG11Y2gg XCh0d28gZXhjZXB0aW9ucywgc2VlIGNvbW1lbnQgbGF0ZXJcKSBpbiB0aGUgc2VjdGlvbiB0aGF0 IGFjdHVhbGx5IGFyZSBhc3N1bXB0aW9ucyBhcyBzdWNoLikvVChUQ2xhdXNlbikvTShEOjIwMTIx MDAzMTYyOTM0KzAyJzAwJykvUCAzNiAwIFI+PgplbmRvYmoKMzQyIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjQ1LjAwMCAxMjkuMDUwIDQ5NS4wMDAgMjQxLjA1 MF0vUGFyZW50IDM0MSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozNDQgMCBvYmoKPDwvVHlwZS9Y T2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMjMxLjAwMCAxOTQuNTAwIDM1Ny4w MDAgMjA1LjA1MF0vTWF0cml4WzEgMCAwIDEgLTIzMS4wMDAgLTE5NC41MDBdL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9N dWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MK MS4wMDAgMS4wMDAgMC4wMDAgcmcKMjMxLjAwMCAxOTQuNTAwIG0KMzU3LjAwMCAxOTQuNTAwIGwK MzU3LjAwMCAyMDUuMDUwIGwKMjMxLjAwMCAyMDUuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2Jq CjM0NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzIzMS4w MDAgMTk0LjUwMCAzNTcuMDAwIDIwNS4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2lu dHNbMjMxLjAwMCAyMDUuMDUwIDM1Ny4wMDAgMjA1LjA1MCAyMzEuMDAwIDE5NC41MDAgMzU3LjAw MCAxOTQuNTAwXS9BUDw8L04gMzQ0IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5 MzQrMDInMDAnKS9QIDM2IDAgUj4+CmVuZG9iagozNDYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL1RleHQvRiA0L1JlY3RbMzIxLjAwMCAyMDAuMDUwIDM1MS4wMDAgMjMwLjA1MF0vTmFtZS9D b21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDM0NyAwIFIvQ29udGVudHMod2hpY2gg ZGlzY292ZXJ5IHByb2Nlc3M/XG4iVGhlIGRpc2NvdmVyeSBwcm9jZXNzLCBzcGVjaWZpZWQgaW4g c2VjdGlvbiBYWCIgP1xuT3IsIGFuIGV4dGVybmFsIHByb2Nlc3MgaW4gYW5vdGhlciBzcGVjP1xu T3IsIGEgbm9uLXNwZWNpZmllZCBwcm9jZXNzPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYy OTM0KzAyJzAwJykvUCAzNiAwIFI+PgplbmRvYmoKMzQ3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzU2LjAwMCAxMTguMDUwIDYwNi4wMDAgMjMwLjA1MF0vUGFy ZW50IDM0NiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMzkgMCBSCi9Gb250IDQwIDAgUgo+PgovQ29u dGVudHMgMzcgMCBSL0Fubm90cyAzMTcgMCBSPj4KZW5kb2JqCjMxNyAwIG9iagpbMzE4IDAgUiAz MTkgMCBSIDMyMSAwIFIgMzIyIDAgUiAzMjMgMCBSIDMyNSAwIFIgMzI2IDAgUiAzMjcgMCBSIDMy OSAwIFIgMzMxIDAgUiAzMzIgMCBSIDMzNSAwIFIgMzM2IDAgUiAzMzcgMCBSIDM0MCAwIFIgMzQx IDAgUiAzNDIgMCBSIDM0NSAwIFIgMzQ2IDAgUiAzNDcgMCBSXQplbmRvYmoKMzUwIDAgb2JqCjw8 L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzM1Ny4wMDAgMzcwLjUw MCAzODEuMDAwIDM4MS4wNTBdL01hdHJpeFsxIDAgMCAxIC0zNTcuMDAwIC0zNzAuNTAwXS9Hcm91 cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFs c2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEK L1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjM1Ny4wMDAgMzcwLjUwMCBtCjM4MS4wMDAgMzcw LjUwMCBsCjM4MS4wMDAgMzgxLjA1MCBsCjM1Ny4wMDAgMzgxLjA1MCBsCmYKUQoKZW5kc3RyZWFt CmVuZG9iagozNTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVj dFszNTcuMDAwIDM3MC41MDAgMzgxLjAwMCAzODEuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9R dWFkUG9pbnRzWzM1Ny4wMDAgMzgxLjA1MCAzODEuMDAwIDM4MS4wNTAgMzU3LjAwMCAzNzAuNTAw IDM4MS4wMDAgMzcwLjUwMF0vQVA8PC9OIDM1MCAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIx MDAzMTYyOTM0KzAyJzAwJykvUCA0MSAwIFI+PgplbmRvYmoKMzUzIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzM1NC4wMDAgMzc2LjA1MCAzODQuMDAwIDQwNi4wNTBd L05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyOTcgMCBSL0NvbnRlbnRz KFRoZSBSRkMgZWRpdG9yIHVzZXM6XG5cbgkiLi4uYmxhaCBibGFoLCBlLmcuLCBibGFoIGJsYWgi XG5cbmFuZFxuCSIuLi5ibGFoIGJsYWgsIGkuZS4sIGJsYWggYmxhaCJcblxuUmVjb21tZW5kIG1h a2luZyB0aGVpciBsaWZlIGVhc2llciBcKGFuZCByZWR1Y2luZyB0aGVpciBwcm9jZXNzaW5nIHRp bWVcKSBieSBqdXN0IGRvaW5nIHRoaXMgZnJvbSB0aGUgc3RhcnQgO1wpKS9UKFRDbGF1c2VuKS9N KEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQxIDAgUj4+CmVuZG9iagoyOTcgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszODkuMDAwIDI5NC4wNTAgNjM5LjAw MCA0MDYuMDUwXS9QYXJlbnQgMzUzIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjM1NCAwIG9iago8 PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs4MS4wMDAgNjAxLjUw MCA1MTMuMDAwIDY2Ny4wNTBdL01hdHJpeFsxIDAgMCAxIC04MS4wMDAgLTYwMS41MDBdL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxz ZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggNDY0Pj5zdHJlYW0KcQov UjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKOTkuMDAwIDY1Ni41MDAgbQo1MTMuMDAwIDY1Ni41 MDAgbAo1MTMuMDAwIDY2Ny4wNTAgbAo5OS4wMDAgNjY3LjA1MCBsCmYKODEuMDAwIDY0NS41MDAg bQo0ODkuMDAwIDY0NS41MDAgbAo0ODkuMDAwIDY1Ni4wNTAgbAo4MS4wMDAgNjU2LjA1MCBsCmYK ODEuMDAwIDYzNC41MDAgbQo1MDcuMDAwIDYzNC41MDAgbAo1MDcuMDAwIDY0NS4wNTAgbAo4MS4w MDAgNjQ1LjA1MCBsCmYKODEuMDAwIDYyMy41MDAgbQo1MTMuMDAwIDYyMy41MDAgbAo1MTMuMDAw IDYzNC4wNTAgbAo4MS4wMDAgNjM0LjA1MCBsCmYKODEuMDAwIDYxMi41MDAgbQo1MDcuMDAwIDYx Mi41MDAgbAo1MDcuMDAwIDYyMy4wNTAgbAo4MS4wMDAgNjIzLjA1MCBsCmYKODEuMDAwIDYwMS41 MDAgbQoyMTkuMDAwIDYwMS41MDAgbAoyMTkuMDAwIDYxMi4wNTAgbAo4MS4wMDAgNjEyLjA1MCBs CmYKUQoKZW5kc3RyZWFtCmVuZG9iagozNTUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hp Z2hsaWdodC9GIDQvUmVjdFs4MS4wMDAgNjAxLjUwMCA1MTMuMDAwIDY2Ny4wNTBdL0NbMS4wMDAg MS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbOTkuMDAwIDY2Ny4wNTAgNTEzLjAwMCA2NjcuMDUwIDk5 LjAwMCA2NTYuNTAwIDUxMy4wMDAgNjU2LjUwMCA4MS4wMDAgNjU2LjA1MCA0ODkuMDAwIDY1Ni4w NTAgODEuMDAwIDY0NS41MDAgNDg5LjAwMCA2NDUuNTAwIDgxLjAwMCA2NDUuMDUwIDUwNy4wMDAg NjQ1LjA1MCA4MS4wMDAgNjM0LjUwMCA1MDcuMDAwIDYzNC41MDAgODEuMDAwIDYzNC4wNTAgNTEz LjAwMCA2MzQuMDUwIDgxLjAwMCA2MjMuNTAwIDUxMy4wMDAgNjIzLjUwMCA4MS4wMDAgNjIzLjA1 MCA1MDcuMDAwIDYyMy4wNTAgODEuMDAwIDYxMi41MDAgNTA3LjAwMCA2MTIuNTAwIDgxLjAwMCA2 MTIuMDUwIDIxOS4wMDAgNjEyLjA1MCA4MS4wMDAgNjAxLjUwMCAyMTkuMDAwIDYwMS41MDBdL0FQ PDwvTiAzNTQgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1Ag NDEgMCBSPj4KZW5kb2JqCjM1NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQv UG9wdXAgMzU4IDAgUi9SZWN0WzI4Mi4wMDAgNjYyLjA1MCAzMTIuMDAwIDY5Mi4wNTBdL05hbWUv Q29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhUaGlzIHBhcmFncmFwaCBpcyB0 aGUgb25lIG9mIHRoZSB0d28gd2hpY2ggY29udGFpbiByZWFsIGFzc3VtcHRpb24sIGFuZCBzbyBv bmUgb2YgdGhlIHBhcmFncmFwaHMgdGhhdCwgZnJvbSB0aGlzIHNlY3Rpb24sIHdvdWxkIGZpdCB0 aGUgc2VjdGlvbiBoZWFkZXIgIkFzc3VtcHRpb25zIikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAz MTYyOTM0KzAyJzAwJykvUCA0MSAwIFI+PgplbmRvYmoKMzU4IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzE3LjAwMCA1ODAuMDUwIDU2Ny4wMDAgNjkyLjA1MF0v UGFyZW50IDM1NiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozNTkgMCBvYmoKPDwvVHlwZS9YT2Jq ZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbOTkuMDAwIDU3OS41MDAgNDE3LjAwMCA1 OTAuMDUwXS9NYXRyaXhbMSAwIDAgMSAtOTkuMDAwIC01NzkuNTAwXS9Hcm91cDw8L1MvVHJhbnNw YXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlw bHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEKL1IwIGdzCjEuMDAw IDEuMDAwIDAuMDAwIHJnCjk5LjAwMCA1NzkuNTAwIG0KNDE3LjAwMCA1NzkuNTAwIGwKNDE3LjAw MCA1OTAuMDUwIGwKOTkuMDAwIDU5MC4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzYwIDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbOTkuMDAwIDU3OS41 MDAgNDE3LjAwMCA1OTAuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzk5LjAw MCA1OTAuMDUwIDQxNy4wMDAgNTkwLjA1MCA5OS4wMDAgNTc5LjUwMCA0MTcuMDAwIDU3OS41MDBd L0FQPDwvTiAzNTkgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcp L1AgNDEgMCBSPj4KZW5kb2JqCjM2MSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9G IDQvUG9wdXAgMzYyIDAgUi9SZWN0WzM3Mi4wMDAgNTg1LjA1MCA0MDIuMDAwIDYxNS4wNTBdL05h bWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhBbmQgdGhpcyBpcyBhIHRl cm1pbm9sb2d5IGRlZmluaXRpb24uIEFnYWluLCBJIHN0cm9uZ2x5IHN1Z2dlc3QgbWFraW5nIGEg cHJvcGVyICJUZXJtaW5vbG9neSIgc2VjdGlvbiwgY2VudHJhbGl6aW5nIHN1Y2guXG5cbkFsc28g b24gdGhpcyBwb2ludC4gSW4gTUFORVQsIHdlIGhhdmUgYSAtIGJ5IG5vdyAtIHdlbGwgZXN0YWJs aXNoZWQgdXNlIG9mIHRoZSB3b3JkICJuZWlnaGJvciIsIGV2ZW4gYSBwcm90b2NvbCB0aGF0IGhh cyB0aGUgd29yZCAiTmVpZ2hib3IiIGluIGl0cyB0aXRsZSBzcGVjaWZpZWQgYXMgUkZDNjEzMC4g SSB3b25kZXIgaWYgaXQgd291bGQgbm90IGJlaG92ZSB1cyB0byBjb21lIHVwIHdpdGggYSBkaWZm ZXJlbnQgdGVybSBoZXJlLCBzbyBhcyB0byBhdm9pZCBjb25mdXNpb24/IEZvciBleGFtcGxlLCBJ IGNhbiBlYXNpbHkgaW1hZ2luZSBhIHN5c3RlbSB1c2luZyBib3RoIERMRVAgYW5kIE5IRFAsIGlu IHdoaWNoIGNhc2UgIm5laWdoYm9yIiBtYXkgcmVmZXIgdG8gZGlzdGluY3RseSBkaWZmZXJlbnQg Y29uY2VwdHMuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQxIDAg Uj4+CmVuZG9iagozNjIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVj dFs0MDcuMDAwIDUwMy4wNTAgNjU3LjAwMCA2MTUuMDUwXS9QYXJlbnQgMzYxIDAgUi9PcGVuIGZh bHNlPj4KZW5kb2JqCjM2MyAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1U eXBlIDEvQkJveFs4MS4wMDAgNTEzLjUwMCA0NzcuMDAwIDUzNS4wNTBdL01hdHJpeFsxIDAgMCAx IC04MS4wMDAgLTUxMy41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9F eHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+ Pi9MZW5ndGggMTc4Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKNDY1LjAw MCA1MjQuNTAwIG0KNDc3LjAwMCA1MjQuNTAwIGwKNDc3LjAwMCA1MzUuMDUwIGwKNDY1LjAwMCA1 MzUuMDUwIGwKZgo4MS4wMDAgNTEzLjUwMCBtCjE5NS4wMDAgNTEzLjUwMCBsCjE5NS4wMDAgNTI0 LjA1MCBsCjgxLjAwMCA1MjQuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjM2NCAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzgxLjAwMCA1MTMuNTAwIDQ3 Ny4wMDAgNTM1LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s0NjUuMDAwIDUz NS4wNTAgNDc3LjAwMCA1MzUuMDUwIDQ2NS4wMDAgNTI0LjUwMCA0NzcuMDAwIDUyNC41MDAgODEu MDAwIDUyNC4wNTAgMTk1LjAwMCA1MjQuMDUwIDgxLjAwMCA1MTMuNTAwIDE5NS4wMDAgNTEzLjUw MF0vQVA8PC9OIDM2MyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAw JykvUCA0MSAwIFI+PgplbmRvYmoKMzY1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0 L0YgNC9Qb3B1cCAzNjcgMCBSL1JlY3RbMTQ4LjQ1MyA1MjEuMjg0IDE3OC40NTMgNTUxLjI4NF0v TmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKEkgbGlrZSBkZWZpbmlu ZyBhIHByb3RvY29sIGFzIHNvbWV0aGluZyBvcGVyYXRpbmcgb24gaW5mb3JtYXRpb24gYmFzZXMh XG5cblRoYXQgc2FpZCwgSSBhbHNvIHRoaW5rIHRoYXQgZGVmaW5pbmcgdGhlIGluZm9ybWF0aW9u IGJhc2VzIGluIGEgc2VwYXJhdGUgc2VjdGlvbiBpcyBhIGdyZWF0IGhlbHA6IGl0IGFsbG93cyB0 aGUgaW1wbGVtZW50ZXIgdG8gY29uc2lkZXIgd2hhdCBkYXRhIHN0cnVjdHVyZXMgYW5kIGRhdGEg c3RvcmFnZSBpcyByZXF1aXJlZCBmb3IgbWFraW5nIHRoZSBwcm90b2NvbCB3b3JrIC0gYW5kLCBh bGxvd3Mgc3BlY2lmeWluZyB0aGUgcHJvdG9jb2wgb3BlcmF0aW9ucyBcKG1lc3NhZ2UgcHJvY2Vz c2luZ1wpIGFzIG9wZXJhdGlvbnMgb24gdGhlc2UgaW5mb3JtYXRpb24gYmFzZXMuXG5cbkkgd291 bGQgc3VnZ2VzdCB0aGF0IGEgc2VjdGlvbiBiZSBhZGRlZCB0byB0aGUgc3BlY2lmaWNhdGlvbiwg ZW50aXRsZWQgIkluZm9ybWF0aW9uIEJhc2VzIiwgaW4gd2hpY2ggdGhlIGRpZmZlcmVudCBpbmZv cm1hdGlvbiBzZXRzLCBhbmQgdGhlaXIgY29udGVudCwgYmUgc3BlY2lmaWVkLiBUaGlzIHNob3Vs ZCBjb21lIGJlZm9yZSB0aGUgYWN0dWFsIGRpc2N1c3Npb24gYW5kIGRlc2NyaXB0aW9uIG9mIHBy b3RvY29sIG9wZXJhdGlvbnMuXG5cbkkgd291bGQgZ3Vlc3MgdGhhdCBpdCBhbHNvIHdvdWxkIHJl bmRlciBkZXNjcmliaW5nIFwoYW5kIHVuZGVyc3RhbmRpbmcgdGhlIGRlc2NyaXB0aW9uIG9mXCkg dGhlIHByb3RvY29sIG1lc3NhZ2UgcHJvY2Vzc2luZyBhbiBhd2Z1bCBsb3QgZWFzaWVyLikvVChU Q2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA0MSAwIFI+PgplbmRvYmoKMzY3 IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjk5LjAwMCA0NDgu MDUwIDU0OS4wMDAgNTYwLjA1MF0vUGFyZW50IDM2NSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoz NjggMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMTA1 LjAwMCA0OTEuNTAwIDE1OS4wMDAgNTAyLjA1MF0vTWF0cml4WzEgMCAwIDEgLTEwNS4wMDAgLTQ5 MS41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9S MDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2 Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMTA1LjAwMCA0OTEuNTAwIG0K MTU5LjAwMCA0OTEuNTAwIGwKMTU5LjAwMCA1MDIuMDUwIGwKMTA1LjAwMCA1MDIuMDUwIGwKZgpR CgplbmRzdHJlYW0KZW5kb2JqCjM2OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxp Z2h0L0YgNC9SZWN0WzEwNS4wMDAgNDkxLjUwMCAxNTkuMDAwIDUwMi4wNTBdL0NbMS4wMDAgMS4w MDAgMC4wMDBdL1F1YWRQb2ludHNbMTA1LjAwMCA1MDIuMDUwIDE1OS4wMDAgNTAyLjA1MCAxMDUu MDAwIDQ5MS41MDAgMTU5LjAwMCA0OTEuNTAwXS9BUDw8L04gMzY4IDAgUiA+Pi9UKFRDbGF1c2Vu KS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQxIDAgUj4+CmVuZG9iagozNzAgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMTE3LjAwMCA0OTcuMDUwIDE0Ny4w MDAgNTI3LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDM3MiAw IFIvQ29udGVudHMoYWZmZWN0aW5nPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAy JzAwJykvUCA0MSAwIFI+PgplbmRvYmoKMzcyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Q b3B1cC9GIDI4L1JlY3RbMTUyLjAwMCA0MTUuMDUwIDQwMi4wMDAgNTI3LjA1MF0vUGFyZW50IDM3 MCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozNzMgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5 cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbOTkuMDAwIDM3MC41MDAgMTcxLjAwMCAzODEuMDUwXS9N YXRyaXhbMSAwIDAgMSAtOTkuMDAwIC0zNzAuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4v UmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9F eHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAu MDAwIHJnCjk5LjAwMCAzNzAuNTAwIG0KMTcxLjAwMCAzNzAuNTAwIGwKMTcxLjAwMCAzODEuMDUw IGwKOTkuMDAwIDM4MS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzc0IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbOTkuMDAwIDM3MC41MDAgMTcxLjAw MCAzODEuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzk5LjAwMCAzODEuMDUw IDE3MS4wMDAgMzgxLjA1MCA5OS4wMDAgMzcwLjUwMCAxNzEuMDAwIDM3MC41MDBdL0FQPDwvTiAz NzMgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNDEgMCBS Pj4KZW5kb2JqCjM3NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsx MzUuMDAwIDM3Ni4wNTAgMTY1LjAwMCA0MDYuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAw MCAwLjAwMF0vUG9wdXAgMzc2IDAgUi9Db250ZW50cyhUaGlzIHdvdWxkIGJlIHRoZSBzZWNvbmQg b2YgdGhlIG9ubHkgdHdvIHNlY3Rpb25zIGNvbnRhaW5pbmcgYWN0dWFsIGFzc3VtcHRpb25zKS9U KFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQxIDAgUj4+CmVuZG9iagoz NzYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxNzAuMDAwIDI5 NC4wNTAgNDIwLjAwMCA0MDYuMDUwXS9QYXJlbnQgMzc1IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2Jq CjM3NyAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsx OTUuMDAwIDI5My41MDAgMzM5LjAwMCAzMDQuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMTk1LjAwMCAt MjkzLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8 L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAx MDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoxOTUuMDAwIDI5My41MDAg bQozMzkuMDAwIDI5My41MDAgbAozMzkuMDAwIDMwNC4wNTAgbAoxOTUuMDAwIDMwNC4wNTAgbApm ClEKCmVuZHN0cmVhbQplbmRvYmoKMzc4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdo bGlnaHQvRiA0L1JlY3RbMTk1LjAwMCAyOTMuNTAwIDMzOS4wMDAgMzA0LjA1MF0vQ1sxLjAwMCAx LjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxOTUuMDAwIDMwNC4wNTAgMzM5LjAwMCAzMDQuMDUwIDE5 NS4wMDAgMjkzLjUwMCAzMzkuMDAwIDI5My41MDBdL0FQPDwvTiAzNzcgMCBSID4+L1QoVENsYXVz ZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNDEgMCBSPj4KZW5kb2JqCjM3OSAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMzgwIDAgUi9SZWN0WzI1Mi4w MDAgMjk5LjA1MCAyODIuMDAwIDMyOS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAu MDAwXS9Db250ZW50cyhOZWVkIHRvIHNwZWNpZnkgaG93IHRvIHByb3Blcmx5IGlkZW50aWZ5IHRo YXQsIGUuZy4sIHNlcSMgNSB0aGVuIG1heSBiZSBjb25zaWRlcmVkIGJpZ2dlciB0aGFuIHNlcSMg NjU1MzAgLS0gaS5lLiwgcm9sbC1vdmVyIGJlaGF2aW9yIC0tIGlmIGFueSBzb3J0IG9mIG9yZGVy aW5nIGlzIHJlcXVpcmVkLlxuXG5JZiBub3QsIHRoZW4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhp cyBiZSBwcmVmaXhlZCBieSAiRExFUCB1c2VzIHNlcXVlbmNlIG51bWJlcnMgb25seSBmb3IgY29y cmVsYXRpbmcgYSByZXNwb25zZSB0byBhIHJlcXVlc3QsIGFuZCBub3QgZm9yIGZyZXNobmVzcyBp bmZvcm1hdGlvbiwgaS5lLiwgdHdvIHNlcXVlbmNlIG51bWJlcnMgZm9yIHRoZSBzYW1lIGRlc3Rp bmF0aW9uIGFyZSBuZXZlciBjb21wYXJlZCBmb3IgYW55dGhpbmcgb3RoZXIgdGhhbiBlcXVhbGl0 eSIuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQxIDAgUj4+CmVu ZG9iagozODAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyODcu MDAwIDIxNy4wNTAgNTM3LjAwMCAzMjkuMDUwXS9QYXJlbnQgMzc5IDAgUi9PcGVuIGZhbHNlPj4K ZW5kb2JqCjM4MSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEv QkJveFs4MS4wMDAgMjE2LjUwMCA0ODkuMDAwIDIzOC4wNTBdL01hdHJpeFsxIDAgMCAxIC04MS4w MDAgLTIxNi41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3Rh dGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5n dGggMTc4Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMTc3LjAwMCAyMjcu NTAwIG0KNDg5LjAwMCAyMjcuNTAwIGwKNDg5LjAwMCAyMzguMDUwIGwKMTc3LjAwMCAyMzguMDUw IGwKZgo4MS4wMDAgMjE2LjUwMCBtCjM1MS4wMDAgMjE2LjUwMCBsCjM1MS4wMDAgMjI3LjA1MCBs CjgxLjAwMCAyMjcuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjM4MiAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzgxLjAwMCAyMTYuNTAwIDQ4OS4wMDAg MjM4LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxNzcuMDAwIDIzOC4wNTAg NDg5LjAwMCAyMzguMDUwIDE3Ny4wMDAgMjI3LjUwMCA0ODkuMDAwIDIyNy41MDAgODEuMDAwIDIy Ny4wNTAgMzUxLjAwMCAyMjcuMDUwIDgxLjAwMCAyMTYuNTAwIDM1MS4wMDAgMjE2LjUwMF0vQVA8 PC9OIDM4MSAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA0 MSAwIFI+PgplbmRvYmoKMzgzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9S ZWN0WzMwMC4wMDAgMjIyLjA1MCAzMzAuMDAwIDI1Mi4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAw IDEuMDAwIDAuMDAwXS9Qb3B1cCAzODQgMCBSL0NvbnRlbnRzKFRoaXMgbmVlZHMgdG8gYmUgbW9y ZSBleHBsaWNpdDpcbiJETEVQIHJ1bm5pbmcgb3ZlciBvdGhlciB0cmFuc3BvcnQgbWVjaGFuaXNt cyBNVVNUIGJlIGRvY3VtZW50ZWQgc2VwYXJhdGVseSwgYW5kIHN1Y2ggc3BlY2lmaWNhdGlvbnMg TVVTVCByZWdpc3RlciBvciBzcGVjaWZ5IGFwcHJvcHJpYXRlIGNvZGUgcG9pbnRzIHRvIHVzZSIp L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNDEgMCBSPj4KZW5kb2Jq CjM4NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzMzNS4wMDAg MTQwLjA1MCA1ODUuMDAwIDI1Mi4wNTBdL1BhcmVudCAzODMgMCBSL09wZW4gZmFsc2U+PgplbmRv YmoKMzg1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAzODYgMCBS L1JlY3RbMTA1LjAwMCAxODkuMDUwIDEzNS4wMDAgMjE5LjA1MF0vTmFtZS9Db21tZW50L0NbMS4w MDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKFR3byBjb21tZW50cyBoZXJlLlxuXG4xXCkJU3VnZ2Vz dCB0ZXJtaW5nIGl0ICJDcmVkaXQgV2luZG93cyIgb3Igc29tZXRoaW5nLCBzbyBhcyB0byBhdm9p ZCBjb25mdXNpb25zIG9mIHRoZSBzb3J0ICJJIHdvdWxkIGxpa2UgdG8gY3JlZGl0IFhYWCB3aXRo IGhhdmluZyBjb21lIHVwIHdpdGggdGhlIGVmZmljaWVudCBhbGdvcml0aG0gdXNlZCB0byBtYWtl IHdoaXBwZWQgY3JlYW0iLlxuXG4yXCkJVGhpcyBcKGFuZCBmb2xsb3dpbmcsIGFuZCBwYXJ0IG9m IHRoZSBwcmV2aW91c1wpIHNlY3Rpb25zIHJlYWxseSByZWFkIGFzIHdoYXQgd2UgdHlwaWNhbGx5 IHNlZSBkZXNjcmliZWQgaW4gYSAiUHJvdG9jb2wgT3ZlcnZpZXcgYW5kIEZ1bmN0aW9uaW5nIiBz ZWN0aW9uLlxuXG5JIHdvdWxkIHRoZXJlZm9yZSBzdWdnZXN0IHRoYXQgYSBzZWN0aW9uIDIgYmUg IlRlcm1pbm9sb2d5Iiwgc2VjdGlvbiAzIGJlICJBc3N1bXB0aW9ucyIgXChjb250YWluaW5nIHRo ZSB0d28gcGFyYWdyYXBocyBwb2ludGVkIG91dCBpbiB0aGUgYWJvdmVcKSBhbmQgYSBuZXcgc2Vj dGlvbiA0IGFkZGVkIHRpdGxlZCAiUHJvdG9jb2wgT3ZlcnZpZXcgYW5kIEZ1bmN0aW9uaW5nIi5c blxuSW4gc2VjdGlvbiA0LCB0aGUgcmVtYWluZGVyIG9mIFNlY3Rpb24gMiwgcGx1cyB0aGlzIHNl Y3Rpb24gIkNyZWRpdHMiLCBhbmQgdGhlIGZvbGxvd2luZyAiTWV0cmljcyIgYW5kICJOb3JtYWwg U2Vzc2lvbiBGbG93IiBiZSBpbmNsdWRlZCBhcyBzdWJzZWN0aW9ucyB0byB0aGlzIHByb3Bvc2Vk IHNlY3Rpb24gNC5cblxuSSB3b3VsZCBldmVuIHN1Z2dlc3QgdGhhdCAiTWFuZGF0b3J5IFNpZ25h bHMgYW5kIERhdGEgSXRlbXMiIGFsc28gYmUgaW5jbHVkZWQgaW4gdGhpcyBwcm9wb3NlZCBzZWN0 aW9uIDQsIGFzICJTaWduYWxpbmcgT3ZlcnZpZXciIGFuZCAiSW5mb3JtYXRpb24gQmFzZSBPdmVy dmlldyIuIFRoZSBsYXR0ZXIgd291bGQgZXZlbiwgaW4gcGFydCwgYWNjb21tb2RhdGUgbXkgcHJl dmlvdXMgY29tbWVudCBhcyB0byBtYWtpbmcgIkluZm9ybWF0aW9uIEJhc2VzIiBhcHBlYXIgbW9y ZSBjbGVhcmx5LlxuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQx IDAgUj4+CmVuZG9iagozODYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgv UmVjdFsxNDAuMDAwIDEwNy4wNTAgMzkwLjAwMCAyMTkuMDUwXS9QYXJlbnQgMzg1IDAgUi9PcGVu IGZhbHNlPj4KZW5kb2JqCjM4NyAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zv cm1UeXBlIDEvQkJveFs5OS4wMDAgMTYxLjUwMCAxMjMuMDAwIDE3Mi4wNTBdL01hdHJpeFsxIDAg MCAxIC05OS4wMDAgLTE2MS41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8 PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+ Pj4+Pi9MZW5ndGggMTA0Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKOTku MDAwIDE2MS41MDAgbQoxMjMuMDAwIDE2MS41MDAgbAoxMjMuMDAwIDE3Mi4wNTAgbAo5OS4wMDAg MTcyLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagozODggMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs5OS4wMDAgMTYxLjUwMCAxMjMuMDAwIDE3Mi4wNTBd L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbOTkuMDAwIDE3Mi4wNTAgMTIzLjAwMCAx NzIuMDUwIDk5LjAwMCAxNjEuNTAwIDEyMy4wMDAgMTYxLjUwMF0vQVA8PC9OIDM4NyAwIFIgPj4v VChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA0MSAwIFI+PgplbmRvYmoK Mzg5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0Wzk2LjAwMCAxNjcu MDUwIDEyNi4wMDAgMTk3LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1Bv cHVwIDM5MCAwIFIvQ29udGVudHMoT24gdG8gdGhlIGNyZWRpdCB3aW5kb3dpbmcuIFdoZW4gSSBz cG9rZSB3aXRoIFN0YW4gUmF0bGlmZiBpbiBWYW5jb3V2ZXIsIEkgZGlkbid0IGZ1bGx5IHVuZGVy c3RhbmQgd2hhdCB0aGlzIHdhcyByZWFsbHkgdXNlZnVsIGZvciwgYW5kIGFsbW9zdCBjb25zaWRl cmVkIGl0IGFzICJ1c2VsZXNzIi4gQWZ0ZXIgdGFsa2luZyB3aXRoIFN0YW4sIHdoZXJlaW4gaGUg cGF0aWVudGx5IGV4cGxhaW5lZCBpdHMgdXNlIGluIGEgZmV3IGVsb3F1ZW50IHBocmFzZXMsIEkg Z290IGNvbnZpbmNlZCB0aGF0IGl0IHByb2JhYmx5IHdhcyBub3QganVzdCBhIGdvb2QgaWRlYSwg aXQgd2FzIGFjdHVhbGx5IHJlcXVpcmVkIGluIGNlcnRhaW4gaW1wb3J0YW50IGNhc2VzIDtcKVxu XG5JIHdvdWxkIHJlY29tbWVuZCBhZGRpbmcgdGhvc2UgZWxvcXVlbnQgZXhwbGFuYXRvcnkgcGhy YXNlcyB0byB0aGUgYmVnaW5uaW5nIG9mIHRoaXMgc2VjdGlvbiwgYXMgbW90aXZhdGlvbiBmb3Ig d2h5IHRoaXMgZnVuY3Rpb25hbGl0eSBpcyBpbmNsdWRlZCBpbiBETEVQLlxuKS9UKFRDbGF1c2Vu KS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQxIDAgUj4+CmVuZG9iagozOTAgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxMzEuMDAwIDg1LjA1MCAzODEu MDAwIDE5Ny4wNTBdL1BhcmVudCAzODkgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNDEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ0IDAgUgovRm9u dCA0NSAwIFIKPj4KL0NvbnRlbnRzIDQyIDAgUi9Bbm5vdHMgMzQ5IDAgUj4+CmVuZG9iagozNDkg MCBvYmoKWzM1MSAwIFIgMzUzIDAgUiAyOTcgMCBSIDM1NSAwIFIgMzU2IDAgUiAzNTggMCBSIDM2 MCAwIFIgMzYxIDAgUiAzNjIgMCBSIDM2NCAwIFIgMzY1IDAgUiAzNjcgMCBSIDM2OSAwIFIgMzcw IDAgUiAzNzIgMCBSIDM3NCAwIFIgMzc1IDAgUiAzNzYgMCBSIDM3OCAwIFIgMzc5IDAgUiAzODAg MCBSIDM4MiAwIFIgMzgzIDAgUiAzODQgMCBSIDM4NSAwIFIgMzg2IDAgUiAzODggMCBSIDM4OSAw IFIgMzkwIDAgUl0KZW5kb2JqCjM5MiAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3Jt L0Zvcm1UeXBlIDEvQkJveFszNTEuMDAwIDQxNC41MDAgMzc1LjAwMCA0MjUuMDUwXS9NYXRyaXhb MSAwIDAgMSAtMzUxLjAwMCAtNDE0LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291 cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0 YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCBy ZwozNTEuMDAwIDQxNC41MDAgbQozNzUuMDAwIDQxNC41MDAgbAozNzUuMDAwIDQyNS4wNTAgbAoz NTEuMDAwIDQyNS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzkzIDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMzUxLjAwMCA0MTQuNTAwIDM3NS4wMDAg NDI1LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1szNTEuMDAwIDQyNS4wNTAg Mzc1LjAwMCA0MjUuMDUwIDM1MS4wMDAgNDE0LjUwMCAzNzUuMDAwIDQxNC41MDBdL0FQPDwvTiAz OTIgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNDYgMCBS Pj4KZW5kb2JqCjM5NCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBl IDEvQkJveFszNTcuMDAwIDQxNC41MDAgMzY5LjAwMCA0MjUuMDUwXS9NYXRyaXhbMSAwIDAgMSAt MzU3LjAwMCAtNDE0LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4 dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+ L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwozNTcuMDAw IDQxNC41MDAgbQozNjkuMDAwIDQxNC41MDAgbAozNjkuMDAwIDQyNS4wNTAgbAozNTcuMDAwIDQy NS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzk1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMzU3LjAwMCA0MTQuNTAwIDM2OS4wMDAgNDI1LjA1MF0v Q1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1szNTcuMDAwIDQyNS4wNTAgMzY5LjAwMCA0 MjUuMDUwIDM1Ny4wMDAgNDE0LjUwMCAzNjkuMDAwIDQxNC41MDBdL0FQPDwvTiAzOTQgMCBSID4+ L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNDYgMCBSPj4KZW5kb2Jq CjM5NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFszNDUuMDAwIDQy MC4wNTAgMzc1LjAwMCA0NTAuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0v UG9wdXAgMzA1IDAgUi9Db250ZW50cyhUaGUgUkZDIGVkaXRvciB1c2VzOlxuXG4JIi4uLmJsYWgg YmxhaCwgZS5nLiwgYmxhaCBibGFoIlxuXG5hbmRcbgkiLi4uYmxhaCBibGFoLCBpLmUuLCBibGFo IGJsYWgiXG5cblJlY29tbWVuZCBtYWtpbmcgdGhlaXIgbGlmZSBlYXNpZXIgXChhbmQgcmVkdWNp bmcgdGhlaXIgcHJvY2Vzc2luZyB0aW1lXCkgYnkganVzdCBkb2luZyB0aGlzIGZyb20gdGhlIHN0 YXJ0IDtcKSkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA0NiAwIFI+ PgplbmRvYmoKMzA1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3Rb MzgwLjAwMCAzMzguMDUwIDYzMC4wMDAgNDUwLjA1MF0vUGFyZW50IDM5NiAwIFIvT3BlbiBmYWxz ZT4+CmVuZG9iagozOTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVw IDM5OCAwIFIvUmVjdFs4MS4wMDAgNTA4LjA1MCAxMTEuMDAwIDUzOC4wNTBdL05hbWUvQ29tbWVu dC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhJIHRoaW5rIHRoYXQgbXkgY29tbWVudCBo ZXJlIHJlZmVycyB0byBGaWd1cmUgMS5cblxuRmlndXJlIDEgZXhwbGFpbnMgdGhhdCBETEVQIHJ1 bnMgYmV0d2VlbiBhIHJvdXRlciBhbmQgaXRzIG1vZGVtLCBpLmUuLCAibG9jYWxseSIgXCh3cnQu IHRoZSByZXN0IG9mIHRoZSBuZXR3b3JrXCkuIFxuXG5UaGUgY3JlZGl0IHdpbmRvd2luZywgYXMg ZGVzY3JpYmVkIGluIHRoaXMgcGFyYWdyYXBoLCBzZWVtcyB0byByZWxhdGUgdG8gdGhlICJyZW1v dGUgbm9kZSIuIFRoaXMgaXMgYSBsaXR0bGUgaW4gY29uZmxpY3Qgd2l0aCAyIHBhcmFncmFwaHMg dXAgZnJvbSBoZXJlLCBhdCBsZWFzdCBpdCBpcyBjb25mdXNpbmcuXG5cbk15IHVuZGVyc3RhbmRp bmcgXChpZ25vcmluZyB3aGF0IFN0YW4gc2FpZCBpbiBWYW5jb3V2ZXIsIGJ1dCBqdXN0IHJlYWRp bmcgYW5kIHRoaW5raW5nIGhhcmQgYWJvdXQgdGhpcyBzZWN0aW9uXCkgaXMgdGhhdDpcblxuMVwp IElmIGEgcm91dGVyLCBSMSBjb21tdW5pY2F0ZXMgdG8gaXRzIGxvY2FsIG1vZGVtIFwoYnV0IG5v dCBiZXlvbmQgdGhhdFwpLCBubyBjcmVkaXQgd2luZG93cyBpcyB1c2VkXG4yXCkgSWYgYSByb3V0 ZXIsIFIxLCBjb21tdW5pY2F0ZXMgdG8gYSByZW1vdGUgcm91dGVyLCBSMiwgYnkgd2F5IG9mIGl0 cyBsb2NhbCBtb2RlbSBcKG0xXCkgYW5kIHJlbW90ZSBtb2RlbSBcKG0yXCksIHRoZW4gY3JlZGl0 cyBjYW4gYmUgdXNlZC4gSW4gdGhhdCBjYXNlLCBSMSB3aWxsIGtub3cgb2YgdGhlIGNyZWRpdHMg Y29ycmVzcG9uZGluZyB0byBtMlxuXG5SZW1lbWJlcmluZyBiYWNrIHRvIHdoYXQgU3RhbiBzYWlk IGluIFZhbmNvdXZlciwgdGhpcyBpcyBub3QgZW50aXJlbHkgY29ycmVjdCwgc28gSSB0aGluayB0 aGF0IHRoaXMgc2VjdGlvbiBuZWVkcyBib3RoIHNvbWUgY2xhcmlmaWNhdGlvbiBhbmQgcGVyaGFw cyBhbiBleGFtcGxlIHdpdGggYSBmaWd1cmUgYW5kIGEgcmVmZXJlbmNlIHRvIGZpZ3VyZSAxP1xu ICkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA0NiAwIFI+PgplbmRv YmoKMzk4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTE2LjAw MCA0MjYuMDUwIDM2Ni4wMDAgNTM4LjA1MF0vUGFyZW50IDM5NyAwIFIvT3BlbiBmYWxzZT4+CmVu ZG9iagozOTkgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JC b3hbODEuMDAwIDM5Mi41MDAgNDk1LjAwMCA0MTQuMDUwXS9NYXRyaXhbMSAwIDAgMSAtODEuMDAw IC0zOTIuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRl PDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3Ro IDE3OD4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjM4MS4wMDAgNDAzLjUw MCBtCjQ5NS4wMDAgNDAzLjUwMCBsCjQ5NS4wMDAgNDE0LjA1MCBsCjM4MS4wMDAgNDE0LjA1MCBs CmYKODEuMDAwIDM5Mi41MDAgbQoyNDMuMDAwIDM5Mi41MDAgbAoyNDMuMDAwIDQwMy4wNTAgbAo4 MS4wMDAgNDAzLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0MDAgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs4MS4wMDAgMzkyLjUwMCA0OTUuMDAwIDQx NC4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzgxLjAwMCA0MTQuMDUwIDQ5 NS4wMDAgNDE0LjA1MCAzODEuMDAwIDQwMy41MDAgNDk1LjAwMCA0MDMuNTAwIDgxLjAwMCA0MDMu MDUwIDI0My4wMDAgNDAzLjA1MCA4MS4wMDAgMzkyLjUwMCAyNDMuMDAwIDM5Mi41MDBdL0FQPDwv TiAzOTkgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNDYg MCBSPj4KZW5kb2JqCjQwMSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVj dFs0NDQuMDAwIDQwOS4wNTAgNDc0LjAwMCA0MzkuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAx LjAwMCAwLjAwMF0vUG9wdXAgNDAyIDAgUi9Db250ZW50cyhVc2UgYSBzZWN0aW9uIG51bWJlciBy ZWZlcmVuY2UgaGVyZS4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1Ag NDYgMCBSPj4KZW5kb2JqCjQwMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAy OC9SZWN0WzQ3OS4wMDAgMzI3LjA1MCA3MjkuMDAwIDQzOS4wNTBdL1BhcmVudCA0MDEgMCBSL09w ZW4gZmFsc2U+PgplbmRvYmoKNDAzIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0v Rm9ybVR5cGUgMS9CQm94WzMzOS4wMDAgMzU5LjUwMCA0NTMuMDAwIDM3MC4wNTBdL01hdHJpeFsx IDAgMCAxIC0zMzkuMDAwIC0zNTkuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3Vy Y2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3Rh dGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJn CjMzOS4wMDAgMzU5LjUwMCBtCjQ1My4wMDAgMzU5LjUwMCBsCjQ1My4wMDAgMzcwLjA1MCBsCjMz OS4wMDAgMzcwLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0MDQgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszMzkuMDAwIDM1OS41MDAgNDUzLjAwMCAz NzAuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzMzOS4wMDAgMzcwLjA1MCA0 NTMuMDAwIDM3MC4wNTAgMzM5LjAwMCAzNTkuNTAwIDQ1My4wMDAgMzU5LjUwMF0vQVA8PC9OIDQw MyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA0NiAwIFI+ PgplbmRvYmoKNDA1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzQx MS4wMDAgMzY1LjA1MCA0NDEuMDAwIDM5NS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAw IDAuMDAwXS9Qb3B1cCA0MDYgMCBSL0NvbnRlbnRzKFRlY2huaWNhbGx5LCBpdCBpcyBub3Qgd2l0 aGluIHRoZSBfZW50aXJlXyBuZXR3b3JrLCBpcyBpdD8gSXQgb25seSBjb25jZXJucyB0aG9zZSwg d2l0aCB3aGljaCBhIG5vZGUgaGFzIGEgZGlyZWN0IGxpbms/KS9UKFRDbGF1c2VuKS9NKEQ6MjAx MjEwMDMxNjI5MzQrMDInMDAnKS9QIDQ2IDAgUj4+CmVuZG9iago0MDYgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0NDYuMDAwIDI4My4wNTAgNjk2LjAwMCAzOTUu MDUwXS9QYXJlbnQgNDA1IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjQwNyAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvVW5kZXJsaW5lL0YgNC9SZWN0WzI5Ny4wMDAgMzM3LjUwMCAzMjEuMDAw IDM0OC4wNTBdL0NbMS4wMDAgMC4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMjk3LjAwMCAzNDguMDUw IDMyMS4wMDAgMzQ4LjA1MCAyOTcuMDAwIDMzNy41MDAgMzIxLjAwMCAzMzcuNTAwXS9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQ2IDAgUj4+CmVuZG9iago0MDggMCBv YmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMjk3LjAwMCAz MzcuNTAwIDMyMS4wMDAgMzQ4LjA1MF0vTWF0cml4WzEgMCAwIDEgLTI5Ny4wMDAgLTMzNy41MDBd L0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJ UyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJl YW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMjk3LjAwMCAzMzcuNTAwIG0KMzIxLjAw MCAzMzcuNTAwIGwKMzIxLjAwMCAzNDguMDUwIGwKMjk3LjAwMCAzNDguMDUwIGwKZgpRCgplbmRz dHJlYW0KZW5kb2JqCjQwOSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0Yg NC9SZWN0WzI5Ny4wMDAgMzM3LjUwMCAzMjEuMDAwIDM0OC4wNTBdL0NbMS4wMDAgMS4wMDAgMC4w MDBdL1F1YWRQb2ludHNbMjk3LjAwMCAzNDguMDUwIDMyMS4wMDAgMzQ4LjA1MCAyOTcuMDAwIDMz Ny41MDAgMzIxLjAwMCAzMzcuNTAwXS9BUDw8L04gNDA4IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6 MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQ2IDAgUj4+CmVuZG9iago0MTAgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDQxMSAwIFIvUmVjdFsyOTQuMDAwIDM0My4w NTAgMzI0LjAwMCAzNzMuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29u dGVudHMoVGhpcyBpcyB1bmRlZmluZWQgc28gZmFyIC0gd2UgaGF2ZSBhIFwoc29tZXdoYXRcKSBk ZWZpbml0aW9uIG9mICJOZWlnaGJvciIsIGJ1dCBub3QgInBlZXIiLiBSZWFsbHkgbmVlZCBhIGdv b2QgdGVybWlub2xvZ3kgc2VjdGlvbi4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCsw MicwMCcpL1AgNDYgMCBSPj4KZW5kb2JqCjQxMSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv UG9wdXAvRiAyOC9SZWN0WzMyOS4wMDAgMjYxLjA1MCA1NzkuMDAwIDM3My4wNTBdL1BhcmVudCA0 MTAgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNDEyIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzE1My4wMDAgMjgyLjUwMCAyOTcuMDAwIDI5My4wNTBd L01hdHJpeFsxIDAgMCAxIC0xNTMuMDAwIC0yODIuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5 Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlw ZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAw IDAuMDAwIHJnCjE1My4wMDAgMjgyLjUwMCBtCjI5Ny4wMDAgMjgyLjUwMCBsCjI5Ny4wMDAgMjkz LjA1MCBsCjE1My4wMDAgMjkzLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0MTMgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsxNTMuMDAwIDI4Mi41MDAg Mjk3LjAwMCAyOTMuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzE1My4wMDAg MjkzLjA1MCAyOTcuMDAwIDI5My4wNTAgMTUzLjAwMCAyODIuNTAwIDI5Ny4wMDAgMjgyLjUwMF0v QVA8PC9OIDQxMiAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykv UCA0NiAwIFI+PgplbmRvYmoKNDE0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0Yg NC9SZWN0WzIzNy4wMDAgMjg4LjA1MCAyNjcuMDAwIDMxOC4wNTBdL05hbWUvQ29tbWVudC9DWzEu MDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA0MTUgMCBSL0NvbnRlbnRzKEkgdW5kZXJzdGFuZCB0aGF0 IHlvdSBkbyBub3Qgd2FudCB0byBwcm92aWRlIGFueSBmaXJtIGRhdGEsIGJ1dCBhcmUgdGhlcmUg YW55IGd1aWRlbGluZXMgb3IgZXhhbXBsZXMgdGhhdCBjYW4gYmUgcHJvdmlkZWQ/KS9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDQ2IDAgUj4+CmVuZG9iago0MTUgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyNzIuMDAwIDIwNi4wNTAg NTIyLjAwMCAzMTguMDUwXS9QYXJlbnQgNDE0IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjQ2IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0OSAwIFIK L0ZvbnQgNTAgMCBSCj4+Ci9Db250ZW50cyA0NyAwIFIvQW5ub3RzIDM5MSAwIFI+PgplbmRvYmoK MzkxIDAgb2JqClszOTMgMCBSIDM5NSAwIFIgMzk2IDAgUiAzMDUgMCBSIDM5NyAwIFIgMzk4IDAg UiA0MDAgMCBSIDQwMSAwIFIgNDAyIDAgUiA0MDQgMCBSIDQwNSAwIFIgNDA2IDAgUiA0MDcgMCBS IDQwOSAwIFIgNDEwIDAgUiA0MTEgMCBSIDQxMyAwIFIgNDE0IDAgUiA0MTUgMCBSXQplbmRvYmoK NDE3IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94Wzk5 LjAwMCA0NjkuNTAwIDE3Ny4wMDAgNDgwLjA1MF0vTWF0cml4WzEgMCAwIDEgLTk5LjAwMCAtNDY5 LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1Iw PDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDQ+ PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwo5OS4wMDAgNDY5LjUwMCBtCjE3 Ny4wMDAgNDY5LjUwMCBsCjE3Ny4wMDAgNDgwLjA1MCBsCjk5LjAwMCA0ODAuMDUwIGwKZgpRCgpl bmRzdHJlYW0KZW5kb2JqCjQxOCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0 L0YgNC9SZWN0Wzk5LjAwMCA0NjkuNTAwIDE3Ny4wMDAgNDgwLjA1MF0vQ1sxLjAwMCAxLjAwMCAw LjAwMF0vUXVhZFBvaW50c1s5OS4wMDAgNDgwLjA1MCAxNzcuMDAwIDQ4MC4wNTAgOTkuMDAwIDQ2 OS41MDAgMTc3LjAwMCA0NjkuNTAwXS9BUDw8L04gNDE3IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6 MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDUxIDAgUj4+CmVuZG9iago0MjAgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMTIzLjAwMCA0NzUuMDUwIDE1My4wMDAgNTA1 LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI5MSAwIFIvQ29u dGVudHMoQXMgRExFUCBpcyAiRGF0YSBMaW5rIEV4Y2hhbmdlIFByb3RvY29sIiwgc2F5aW5nICJE TEVQIFByb3RvY29sIiBpcyByZWR1bmRhbnQ6IGV4cGFuZGVkIGl0IGJlY29tZXMgIkRhdGEgTGlu ayBFeGNoYW5nZSBQcm90b2NvbCBQcm90b2NvbCIuXG5cblN1Z2dlc3Qgc2F5aW5nICJETEVQIGlz IGEgLi4uLiIgaW5zdGVhZCBvZiAidGhlIERMRVAgcHJvdG9jb2wgaXMgYSAuLi4uIikvVChUQ2xh dXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA1MSAwIFI+PgplbmRvYmoKMjkxIDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTU4LjAwMCAzOTMuMDUw IDQwOC4wMDAgNTA1LjA1MF0vUGFyZW50IDQyMCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago0MjEg MCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMjc5LjAw MCA1OTAuNTAwIDQ0MS4wMDAgNjAxLjA1MF0vTWF0cml4WzEgMCAwIDEgLTI3OS4wMDAgLTU5MC41 MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8 L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5z dHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMjc5LjAwMCA1OTAuNTAwIG0KNDQx LjAwMCA1OTAuNTAwIGwKNDQxLjAwMCA2MDEuMDUwIGwKMjc5LjAwMCA2MDEuMDUwIGwKZgpRCgpl bmRzdHJlYW0KZW5kb2JqCjQyMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0 L0YgNC9SZWN0WzI3OS4wMDAgNTkwLjUwMCA0NDEuMDAwIDYwMS4wNTBdL0NbMS4wMDAgMS4wMDAg MC4wMDBdL1F1YWRQb2ludHNbMjc5LjAwMCA2MDEuMDUwIDQ0MS4wMDAgNjAxLjA1MCAyNzkuMDAw IDU5MC41MDAgNDQxLjAwMCA1OTAuNTAwXS9BUDw8L04gNDIxIDAgUiA+Pi9UKFRDbGF1c2VuKS9N KEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDUxIDAgUj4+CmVuZG9iago0MjMgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzg3LjAwMCA1OTYuMDUwIDQxNy4wMDAg NjI2LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDQxOSAwIFIv Q29udGVudHMoVGhhdCBpcyBmaW5lLiBCdXQuLi4uXG5JZiBtb3JlIGxpbmsgdHlwZXMgYmVjb21l IHByZXZhbGVudCwgc2hvdWxkIHRoZXJlIGFsc28gbm90IGJlIGEgc3BhY2UgZm9yIGZ1dHVyZSBz dGFuZGFyZHMtYWN0aW9uIGNvZGUgcG9pbnRzP1xuXG5JIGNhbiBvbmx5IHRoaW5rIG9mIGEgc2ls bHkgZXhhbXBsZSByaWdodCBub3csIGJ1dCBjb25zaWRlciB0aGlzOlxuXG5JbiB0aGUgbmVhciBm dXR1cmUsIHNtb2tlLXNpZ25hbCBiYXNlZCBsaW5rcyB3aWxsIGJlY29tZSBwcmV2YWxlbnQsIGlu IHdoaWNoIGNhc2Ugd2Ugd291bGQgd2FudCBETEVQIHRvIHVuZGVyc3RhbmQgbWV0ZW9yb2xvZ2lj YWwgZGF0YSwgYXMgd2VsbCBhcyBkYXRhIGNvbmNlcm5pbmcgdGhlIHN0b2NrIG9mIGZpcmV3b29k IG9mIGEgcmVtb3RlIG1vZGVtLCB0byBhY2N1cmF0ZWx5IGRlc2NyaWJlIHRoZSBjaGFyYWN0ZXJp c3RpY3Mgb2YgYSBsaW5rLiBUaHVzLCB0aGUgU1NXRyBcKFNtb2tlU2lnbmFsIFdHXCkgc3BlY2lm aWVzIGEgRExFUCBleHRlbnNpb24gZm9yIGNhcnJ5aW5nIGFuZCBwcm9jZXNzaW5nIHN1Y2ggZGF0 YS5cblxuV2hhdCBoYXBwZW5zIGluIHRoYXQgY2FzZSwgY29tcGF0aWJpbGl0eSB3aXNlPyBDYW4g YW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gb2YgRExFUCBpbiBhIHJvdXRlciB0aHVzIGhhbmRs ZSBmb3J3YXJkIGNvbXBhdGliaWxpdHksIHdoZW4gZmFjZWQgd2l0aCBhIFNtb2tlU2lnbmFsIE1v ZGVtPyBcbikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA1MSAwIFI+ PgplbmRvYmoKNDE5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3Rb NDIyLjAwMCA1MTQuMDUwIDY3Mi4wMDAgNjI2LjA1MF0vUGFyZW50IDQyMyAwIFIvT3BlbiBmYWxz ZT4+CmVuZG9iago0MjQgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlw ZSAxL0JCb3hbODEuMDAwIDQ0Ny41MDAgNDk1LjAwMCA0NjkuMDUwXS9NYXRyaXhbMSAwIDAgMSAt ODEuMDAwIC00NDcuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0 R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4v TGVuZ3RoIDE3OD4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjM4MS4wMDAg NDU4LjUwMCBtCjQ5NS4wMDAgNDU4LjUwMCBsCjQ5NS4wMDAgNDY5LjA1MCBsCjM4MS4wMDAgNDY5 LjA1MCBsCmYKODEuMDAwIDQ0Ny41MDAgbQozODcuMDAwIDQ0Ny41MDAgbAozODcuMDAwIDQ1OC4w NTAgbAo4MS4wMDAgNDU4LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0MjUgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs4MS4wMDAgNDQ3LjUwMCA0OTUu MDAwIDQ2OS4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzgxLjAwMCA0Njku MDUwIDQ5NS4wMDAgNDY5LjA1MCAzODEuMDAwIDQ1OC41MDAgNDk1LjAwMCA0NTguNTAwIDgxLjAw MCA0NTguMDUwIDM4Ny4wMDAgNDU4LjA1MCA4MS4wMDAgNDQ3LjUwMCAzODcuMDAwIDQ0Ny41MDBd L0FQPDwvTiA0MjQgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcp L1AgNTEgMCBSPj4KZW5kb2JqCjQyNiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9G IDQvUG9wdXAgNDI3IDAgUi9SZWN0WzM1MS4wMDAgNDUzLjA1MCAzODEuMDAwIDQ4My4wNTBdL05h bWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhJIHdvdWxkIG1ha2UgYSBj b3VudGVyLWFyZ3VtZW50IGhlcmU6XG5cbmhhdmluZyBleHBlcmltZW50YWwgc3BhY2VzIGluY3Jl YXNlcyB0aGUgcHJvYmFiaWxpdHkgb2Ygbm9uLWludGVyb3BlcmF0aW5nIHN5c3RlbXMsIGVzcGVj aWFsbHkgaWYgZnV0dXJlIGV2b2x1dGlvbiBvZiB0aGUgcHJvdG9jb2wgaXMgZW52aXNpb25lZCB0 byBoYXBwZW4gYnkgd2F5IG9mIHRoZSBleHBlcmltZW50YWwgc3BhY2UuXG5cbkkgd291bGQgZmVl bCBhIExPVCBtb3JlIGNvbWZvcnRhYmxlIHdpdGggYSBzbWFsbGVyIGV4cGVyaW1lbnRhbCBzcGFj ZSwgYW5kIHRoZW4gZ3VpZGVsaW5lcyBhcyB0byBob3cgdG8gcHJvY2VlZCB0byBzdGFuZGFyZGl6 aW5nIGNvZGUtcG9pbnRzICBmb3IgZnV0dXJlIGV2b2x1dGlvbnMuXG5cbkkgc2hvdWxkIG5vdGUg dGhhdCBJIGRpZG4ndCB1c2UgdG8gdGhpbmsgbGlrZSB0aGF0LCBidXQgb3VyIGZyaWVuZGx5IEFE IFwoQURyaWFuXCkgbWFuYWdlZCB0byBjb252aW5jZSBtZS5cblxuSSB3b3VsZCB0aGVyZWZvcmUg c3VnZ2VzdCB0aGF0LCBhdCB0aGUgdmVyeSBsZWFzdCwgYSBnZW5lcm91cyBzcGFjZSBvZiBjb2Rl IHBvaW50cyBiZSBhbGxvY2F0ZWQgdG8gIlN0YW5kYXJkcyBBY3Rpb24iLCBhbmQgdGhhdCB0aGlz IHBhcmFncmFwaCBzdGF0ZXMgdGhhdCB0aGlzIGlzIHRvIGJlIHVuZGVydGFrZW4gYXMgb3Igd2hl biB0aGUgbmVlZCBhcnJpc2VzLikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAw JykvUCA1MSAwIFI+PgplbmRvYmoKNDI3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1 cC9GIDI4L1JlY3RbMzg2LjAwMCAzNzEuMDUwIDYzNi4wMDAgNDgzLjA1MF0vUGFyZW50IDQyNiAw IFIvT3BlbiBmYWxzZT4+CmVuZG9iago0MjggMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv Rm9ybS9Gb3JtVHlwZSAxL0JCb3hbOTMuMDAwIDM0OC41MDAgMjEzLjAwMCAzNTkuMDUwXS9NYXRy aXhbMSAwIDAgMSAtOTMuMDAwIC0zNDguNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVz b3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRH U3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAw IHJnCjkzLjAwMCAzNDguNTAwIG0KMjEzLjAwMCAzNDguNTAwIGwKMjEzLjAwMCAzNTkuMDUwIGwK OTMuMDAwIDM1OS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKNDI5IDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbOTMuMDAwIDM0OC41MDAgMjEzLjAwMCAz NTkuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzkzLjAwMCAzNTkuMDUwIDIx My4wMDAgMzU5LjA1MCA5My4wMDAgMzQ4LjUwMCAyMTMuMDAwIDM0OC41MDBdL0FQPDwvTiA0Mjgg MCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNTEgMCBSPj4K ZW5kb2JqCjQzMCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsxNzEu MDAwIDM1NC4wNTAgMjAxLjAwMCAzODQuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAw LjAwMF0vUG9wdXAgNDMxIDAgUi9Db250ZW50cyhJIHdvbid0IGNvbW1lbnQgb24gdGhpcyBzZWN0 aW9uIGluIGdyZWF0IGRldGFpbHMsIGJ1dCBJIHdpbGwgbWFrZSBvbmUgb3ZlcmFsbCBjb21tZW50 OiB3aGVuIEkgcmVhZCBpdCwgSSBmb3VuZCBteXNlbGYgZG9vZGVsaW5nIGEgc3RhdGUgbWFjaGlu ZSBvbiBhIG5hcGtpbiwgdG8ga2VlcCB0cmFjayBvZiB3aGF0IHRoZSBwcm90b2NvbCB3YXMgZG9p bmcsIGFuZCB3aGVuLlxuXG5JIHdvdWxkIHN1Z2dlc3QgdGhhdCBzdWNoIGEgc3RhdGUtbWFjaGlu ZSBjb3VsZCBiZSBpbnRlcmVzdGluZy9pbGx1c3RyYXRpdmUgdG8gaW5jbHVkZS4gSSBkaWRuJ3Qg ZHJhdyBpdCBpbiBBU0NJSS10ZXh0LCBzbyBJIGNhbid0IHByb3ZpZGUgYSBkcm9wLWluIGRyYXdp bmcsIGJ1dCBpZiB0aGUgYXV0aG9ycyBhcmUgaW50ZXJlc3RlZCwgdGhlbiBJIGNvdWxkIGZvcndh cmQgbXkgbmFwa2luIHRvIHRoZW0gb24gb2NjYXNpb24/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEw MDMxNjI5MzQrMDInMDAnKS9QIDUxIDAgUj4+CmVuZG9iago0MzEgMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyMDYuMDAwIDI3Mi4wNTAgNDU2LjAwMCAzODQuMDUw XS9QYXJlbnQgNDMwIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjQzMiAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgNDMzIDAgUi9SZWN0Wzc1LjAwMCAzMzIuMDUwIDEw NS4wMDAgMzYyLjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRz KEkgd291bGQgbGlrZSB0byBzZWUgc29tZSBzb3J0IG9mICJTaWduYWxpbmcgb3ZlcnZpZXciIGJl Zm9yZSB0aGUgZGVzY3JpcHRpb24gb2YgYSBzdGF0ZSBtYWNoaW5lLCBvZiB0aGUgc29ydDpcblxu IkEgRExFUCBkZXZpY2UgY2FuIHNlbmQsIHJlY2VpdmUgYW5kIHByb2Nlc3MgdGhlIGZvbGxvd2lu ZyBzaWduYWxzOlxuXG5ORUVEX01PUkVfQVBQTEVQSUU6IFxuCXNlbnQgd2hlbiBhIERMRVAgZGV2 aWNlIGlzIG91dCBvZiBhcHBsZSBwaWVcblxuTkVFRF9NT1JFX1NPVVJfQ1JFQU06XG4Jc2VudCB3 aGVuIGEgRExFUCBkZXZpY2UgaGFzIGFwcGxlIHBpZSwgYnV0XG4JbmVlZHMgc291ciBjcmVhbSB0 byBjb25zdW1lIHdpdGggaXRcblxuIlxuQW5vdGhlciB0aGluZyBpcywgdGhhdCB0aGUgZG9jdW1l bnQgLSBhbmQgdGhpcyBzZWN0aW9uIGluIHBhcnRpY3VsYXIgLSB0YWxrcyBhYm91dCBzaWduYWxz IGFuZCBtZXNzYWdlcyBpbiBhIGJpdCBvZiBhbiBpbmNvaGVyZW50IGZhc2hpb24uIEkgd291bGQg cmVjb21tZW5kIHVzaW5nICJTaWduYWwiIGFzIHRoZSBsb2dpY2FsIGludGVyYWN0aW9uIGJldHdl ZW4gdGhlIGRldmljZXMsICJNZXNzYWdlIiB3aGVuIHJlZmVycmluZyB0byB0aGUgYWN0dWFsIGJp dHMgYW5kIGJpdC1mb3JtYXQgc2VudCBiZXR3ZWVuIGRldmljZXMuXG5cbkZpbmFsbHksIGEgc2Vz c2lvbiBleGlzdHMgYmV0d2VlbiBhIHJvdXRlciBhbmQgaXRzIGxvY2FsIG1vZGVtLCByaWdodD8g VGhlIHN0YXRlIHJlbGF0ZWQgdG8gYSBzZXNzaW9uIGRlc2NyaWJlcyB0aGUgIm5laWdoYm9ycyIg XChvciBpcyBpdCBwZWVycz9cKSByZWFjaGFibGUgYnkgdGhlIHJvdXRlciB2aWEgdGhhdCBtb2Rl bT8gSWYgc28sIHRoZW4gdGhpcyB3b3VsZCBkbyB3ZWxsIGJ5IGJlaW5nIGV4cGxhaW5lZCwgcGVy aGFwcyBpbiBhIFRlcm1pbm9sb2d5IHNlY3Rpb24gYXMgdGhlIGRlZmluaXRpb24gb2YgIkRMRVAg U2Vzc2lvbiI/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDUxIDAg Uj4+CmVuZG9iago0MzMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVj dFsxMTAuMDAwIDI1MC4wNTAgMzYwLjAwMCAzNjIuMDUwXS9QYXJlbnQgNDMyIDAgUi9PcGVuIGZh bHNlPj4KZW5kb2JqCjUxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250ZW50cyA1MiAwIFIvQW5ub3Rz IDQxNiAwIFI+PgplbmRvYmoKNDE2IDAgb2JqCls0MTggMCBSIDQyMCAwIFIgMjkxIDAgUiA0MjIg MCBSIDQyMyAwIFIgNDE5IDAgUiA0MjUgMCBSIDQyNiAwIFIgNDI3IDAgUiA0MjkgMCBSIDQzMCAw IFIgNDMxIDAgUiA0MzIgMCBSIDQzMyAwIFJdCmVuZG9iago0MzUgMCBvYmoKPDwvVHlwZS9YT2Jq ZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMTc3LjAwMCAyNDkuNTAwIDE5NS4wMDAg MjYwLjA1MF0vTWF0cml4WzEgMCAwIDEgLTE3Ny4wMDAgLTI0OS41MDBdL0dyb3VwPDwvUy9UcmFu c3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0 aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4w MDAgMS4wMDAgMC4wMDAgcmcKMTc3LjAwMCAyNDkuNTAwIG0KMTk1LjAwMCAyNDkuNTAwIGwKMTk1 LjAwMCAyNjAuMDUwIGwKMTc3LjAwMCAyNjAuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjQz NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzE3Ny4wMDAg MjQ5LjUwMCAxOTUuMDAwIDI2MC4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNb MTc3LjAwMCAyNjAuMDUwIDE5NS4wMDAgMjYwLjA1MCAxNzcuMDAwIDI0OS41MDAgMTk1LjAwMCAy NDkuNTAwXS9BUDw8L04gNDM1IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQr MDInMDAnKS9QIDU2IDAgUj4+CmVuZG9iago0MzcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L1RleHQvRiA0L1JlY3RbMTcxLjAwMCAyNTUuMDUwIDIwMS4wMDAgMjg1LjA1MF0vTmFtZS9Db21t ZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDMxNSAwIFIvQ29udGVudHMoVGhlIFJGQyBl ZGl0b3IgdXNlczpcblxuCSIuLi5ibGFoIGJsYWgsIGUuZy4sIGJsYWggYmxhaCJcblxuYW5kXG4J Ii4uLmJsYWggYmxhaCwgaS5lLiwgYmxhaCBibGFoIlxuXG5SZWNvbW1lbmQgbWFraW5nIHRoZWly IGxpZmUgZWFzaWVyIFwoYW5kIHJlZHVjaW5nIHRoZWlyIHByb2Nlc3NpbmcgdGltZVwpIGJ5IGp1 c3QgZG9pbmcgdGhpcyBmcm9tIHRoZSBzdGFydCA7XCkpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAw MzE2MjkzNCswMicwMCcpL1AgNTYgMCBSPj4KZW5kb2JqCjMxNSAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzIwNi4wMDAgMTczLjA1MCA0NTYuMDAwIDI4NS4wNTBd L1BhcmVudCA0MzcgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNDM4IDAgb2JqCjw8L1R5cGUvWE9i amVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzMwOS4wMDAgNTY4LjUwMCAzNTcuMDAw IDU3OS4wNTBdL01hdHJpeFsxIDAgMCAxIC0zMDkuMDAwIC01NjguNTAwXS9Hcm91cDw8L1MvVHJh bnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVs dGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEu MDAwIDEuMDAwIDAuMDAwIHJnCjMwOS4wMDAgNTY4LjUwMCBtCjM1Ny4wMDAgNTY4LjUwMCBsCjM1 Ny4wMDAgNTc5LjA1MCBsCjMwOS4wMDAgNTc5LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0 NDAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszMDkuMDAw IDU2OC41MDAgMzU3LjAwMCA1NzkuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRz WzMwOS4wMDAgNTc5LjA1MCAzNTcuMDAwIDU3OS4wNTAgMzA5LjAwMCA1NjguNTAwIDM1Ny4wMDAg NTY4LjUwMF0vQVA8PC9OIDQzOCAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0 KzAyJzAwJykvUCA1NiAwIFI+PgplbmRvYmoKNDQxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9UZXh0L0YgNC9SZWN0WzMxOC4wMDAgNTc0LjA1MCAzNDguMDAwIDYwNC4wNTBdL05hbWUvQ29t bWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA0MzkgMCBSL0NvbnRlbnRzKElzIGEgcGFy dG5lciBkaWZmZXJlbnQgZnJvbSBhIHBlZXI/IG9yIGZyb20gYSBuZWlnaGJvcj8gPT4gVGVybWlu b2xvZ3kgc2VjdGlvbi4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1Ag NTYgMCBSPj4KZW5kb2JqCjQzOSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAy OC9SZWN0WzM1My4wMDAgNDkyLjA1MCA2MDMuMDAwIDYwNC4wNTBdL1BhcmVudCA0NDEgMCBSL09w ZW4gZmFsc2U+PgplbmRvYmoKNTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDU5IDAgUgovRm9udCA2MCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUi9B bm5vdHMgNDM0IDAgUj4+CmVuZG9iago0MzQgMCBvYmoKWzQzNiAwIFIgNDM3IDAgUiAzMTUgMCBS IDQ0MCAwIFIgNDQxIDAgUiA0MzkgMCBSXQplbmRvYmoKNDQzIDAgb2JqCjw8L1R5cGUvWE9iamVj dC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzIzMS4wMDAgMjcxLjUwMCAzMDkuMDAwIDI4 Mi4wNTBdL01hdHJpeFsxIDAgMCAxIC0yMzEuMDAwIC0yNzEuNTAwXS9Hcm91cDw8L1MvVHJhbnNw YXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlw bHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAw IDEuMDAwIDAuMDAwIHJnCjIzMS4wMDAgMjcxLjUwMCBtCjMwOS4wMDAgMjcxLjUwMCBsCjMwOS4w MDAgMjgyLjA1MCBsCjIzMS4wMDAgMjgyLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0NDQg MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsyMzEuMDAwIDI3 MS41MDAgMzA5LjAwMCAyODIuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzIz MS4wMDAgMjgyLjA1MCAzMDkuMDAwIDI4Mi4wNTAgMjMxLjAwMCAyNzEuNTAwIDMwOS4wMDAgMjcx LjUwMF0vQVA8PC9OIDQ0MyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAy JzAwJykvUCA2NiAwIFI+PgplbmRvYmoKNDQ1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9U ZXh0L0YgNC9SZWN0WzI1NS4wMDAgMjc3LjA1MCAyODUuMDAwIDMwNy4wNTBdL05hbWUvQ29tbWVu dC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyOTYgMCBSL0NvbnRlbnRzKEFzIERMRVAgaXMg IkRhdGEgTGluayBFeGNoYW5nZSBQcm90b2NvbCIsIHNheWluZyAiRExFUCBQcm90b2NvbCIgaXMg cmVkdW5kYW50OiBleHBhbmRlZCBpdCBiZWNvbWVzICJEYXRhIExpbmsgRXhjaGFuZ2UgUHJvdG9j b2wgUHJvdG9jb2wiLlxuXG5TdWdnZXN0IHNheWluZyAiRExFUCBpcyBhIC4uLi4iIGluc3RlYWQg b2YgInRoZSBETEVQIHByb3RvY29sIGlzIGEgLi4uLiIpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAw MzE2MjkzNCswMicwMCcpL1AgNjYgMCBSPj4KZW5kb2JqCjI5NiAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzI5MC4wMDAgMTk1LjA1MCA1NDAuMDAwIDMwNy4wNTBd L1BhcmVudCA0NDUgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNDQ2IDAgb2JqCjw8L1R5cGUvWE9i amVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzI5MS4wMDAgNjAxLjUwMCA0NzcuMDAw IDYxMi4wNTBdL01hdHJpeFsxIDAgMCAxIC0yOTEuMDAwIC02MDEuNTAwXS9Hcm91cDw8L1MvVHJh bnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVs dGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEu MDAwIDEuMDAwIDAuMDAwIHJnCjI5MS4wMDAgNjAxLjUwMCBtCjQ3Ny4wMDAgNjAxLjUwMCBsCjQ3 Ny4wMDAgNjEyLjA1MCBsCjI5MS4wMDAgNjEyLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0 NDcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsyOTEuMDAw IDYwMS41MDAgNDc3LjAwMCA2MTIuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRz WzI5MS4wMDAgNjEyLjA1MCA0NzcuMDAwIDYxMi4wNTAgMjkxLjAwMCA2MDEuNTAwIDQ3Ny4wMDAg NjAxLjUwMF0vQVA8PC9OIDQ0NiAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0 KzAyJzAwJykvUCA2NiAwIFI+PgplbmRvYmoKNDQ4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9UZXh0L0YgNC9SZWN0WzI5NC4wMDAgNjA3LjA1MCAzMjQuMDAwIDYzNy4wNTBdL05hbWUvQ29t bWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA0NDkgMCBSL0NvbnRlbnRzKERpc2FncmVl IHdpdGggdGhpcy5cblRoZSByZXF1aXJlbWVudCB3b3VsZCBiZSBmb3IgYW4gaW1wbGVtZW50YXRp b24gbm90IHN1cHBvcnRpbmcgYW4gb3B0aW9uYWwgc2lnbmFsIHRvIGlkZW50aWZ5IGFuZCBkcm9w IHdpdGhvdXQgcHJvY2Vzc2luZyB0aGUgc2lnbmFsLlxuXG5JbiB0ZXJtcyBvZiBhIG1lc3NhZ2Ug XCh0aGUgZW5jb2Rpbmcgb2YgYSBzaWduYWwgaW50byBhIGJ5dGUgZm9ybWF0IHNlbnQgYWNyb3Nz IHRoZSB3aXJlXCksIGl0IHdvdWxkIGJlIHJlcXVpcmVkIHRvIHBhcnNlIG9ubHkgdGhlIGhlYWRl ciwgbm90IHRoZSBmdWxsIG1lc3NhZ2UgXChwcmVzdW1hYmx5LCB0aGUgcmVjaXBpZW50IG5vdCBz dXBwb3J0aW5nIGFuIG9wdGlvbmFsIG1lc3NhZ2Ugd291bGQgYWN0dWFsbHkgbm90IGJlIGFibGUg dG8gcGFyc2UgdGhlIG1lc3NhZ2VcKS5cblxuQWN0dWFsbHksIHRoaXMgbGlua3MgaW4gd2l0aCB0 aGUgd2hvbGUgInVua25vd24vZXhwZXJpbWVudGFsIiBkaXNjdXNzaW9uOiBpdCBzaG91bGQgYmUg c3VjaCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIG5vdCB1bmRlcnN0YW5kaW5nIGEgc2lnbmFsIGNh biBpZGVudGlmeSBhbmQgc2tpcCB0aGF0IHNpZ25hbCBcKGJlIGl0IGR1ZSB0byBub3Qgc3VwcG9y dGluZyBhbiBvcHRpb25hbCBzaWduYWwgb3Igbm90IHVuZGVyc3RhbmRpbmcgYW4gZXhwZXJpbWVu dGFsIHNpZ25hbFwpKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDY2 IDAgUj4+CmVuZG9iago0NDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgv UmVjdFszMjkuMDAwIDUyNS4wNTAgNTc5LjAwMCA2MzcuMDUwXS9QYXJlbnQgNDQ4IDAgUi9PcGVu IGZhbHNlPj4KZW5kb2JqCjQ1MCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zv cm1UeXBlIDEvQkJveFsxNzcuMDAwIDU2OC41MDAgMjEzLjAwMCA1NzkuMDUwXS9NYXRyaXhbMSAw IDAgMSAtMTc3LjAwMCAtNTY4LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNl czw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRl Pj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwox NzcuMDAwIDU2OC41MDAgbQoyMTMuMDAwIDU2OC41MDAgbAoyMTMuMDAwIDU3OS4wNTAgbAoxNzcu MDAwIDU3OS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKNDUxIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMTc3LjAwMCA1NjguNTAwIDIxMy4wMDAgNTc5 LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxNzcuMDAwIDU3OS4wNTAgMjEz LjAwMCA1NzkuMDUwIDE3Ny4wMDAgNTY4LjUwMCAyMTMuMDAwIDU2OC41MDBdL0FQPDwvTiA0NTAg MCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNjYgMCBSPj4K ZW5kb2JqCjQ1MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgNDUz IDAgUi9SZWN0WzE4MC4wMDAgNTc0LjA1MCAyMTAuMDAwIDYwNC4wNTBdL05hbWUvQ29tbWVudC9D WzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhOb3csIEkgYW0gY29uZnVzZWQuXG5cbkRvZXMg RExFUCB1c2UgdGhlIHRlcm0gbWVzc2FnZXMgb3IgcGFja2V0cz9cblxuSW4gUkZDNTQ0NCB3ZSBl bnNocmluZWQgdGhlIG5vdGlvbiBvZiBhIHBhY2tldCBhcyBhbiBlbmNhcHN1bGF0aW9uIG9mIGEg c2V0IG9mIG1lc3NhZ2VzLiBJIGFtIG5vdCBzYXlpbmcgdGhhdCB3ZSBzaG91bGQgdXNlIHRoaXMg Zm9ybWF0LCBvciB0ZXJtaW5vbG9neSwgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQgd2Ugc2hvdWxk IGJlIGNvbnNpc3RlbnQgaW5zaWRlIGEgc3BlY2lmaWNhdGlvbi5cblxuSSBzZWUgdGhhdCBzZWN0 aW9uIDkgYW5kIDEwIHRyeSB0byBtYWtlIGEgZGlzdGluY3Rpb24sIGJ1dCBpdCBzdGlsbCBpcyB2 ZXJ5IHVuY2xlYXIgYW5kIGNvbmZ1c2luZ1xuXG5BcyBJIHVuZGVyc3RhbmQgaXQsIERMRVAgZGVm aW5lcywgaW4gdGhpcyBzZWN0aW9uLCBhIFBBQ0tFVCwgd2l0aCB0aGUgdHlwZSBvZiB0aGUgUEFD S0VUIGRlZmluaW5nIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgY29udGVudCBcKHRoZSBUTFZz IGNvbnRhaW5lZFwpLiBCdXQgRExFUCBkb2VzIG5vdCBkZWZpbmUgYSBzZXBhcmF0ZSBlbnRpdHkg Im1lc3NhZ2UiLCByYXRoZXIgYSAibWVzc2FnZSIgaXMgdXNlZCBmb3IgZGVzY3JpYmluZyBhICJw YWNrZXQiIGluIHNvbWUgY2lyY3Vtc3RhbmNlcy4gSSB0aGluayB0aGF0LCByZWFkaW5nIDkgYW5k IDEwLCAgIkEgbWVzc2FnZSBpcyBhIHBhY2tldCBjb250YWluaW5nIHNvbWUgcHJlLWRlZmluZWQg c2V0IG9mIFRMVnMiLCBidXQgdGhhdCBpcyB2ZXJ5IG5lYnVsb3VzLiBBbHNvLCBpZiBJIHVuZGVy c3RhbmQgaXQgY29ycmVjdGx5LCBkb2VzIGxlbmQgaXRzZWxmIHRvIGEgbGVzcyBjbGVhciBwYXJz aW5nIGxvZ2ljIGFsc28gXChzbyBlaXRoZXIgSSBkbyBub3QgdW5kZXJzdGFuZCBpdCBjb3JyZWN0 bHksIGFuZCBpdCBzaG91bGQgYmUgZXhwbGFpbmVkIHNvIHRoYXQgSSBkbyA7XCkgLS0gb3IsIEkg ZG8gdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIGFuZCB3ZSBzaG91bGQgY29tZSB1cCB3aXRoIGEg Y2xlYXJlciB3YXkgXCkuXG5cblxuSXQgc2VlbXMgY29uZnVzaW5nIHRvIGhhdmUvdXNlIGJvdGgg dGVybXMsIHBpY2sgb25lLiBNeSBwZXJzb25hbCBwcmVmZXJlbmNlIHdvdWxkLCBwcm9iYWJseSwg YmUgbWVzc2FnZSwgYnV0IEkgaGF2ZSBubyBzdHJvbmcgcmVsaWdpb24gb24gdGhlIGNob2ljZSBv ZiB3b3JkLCBhcyBsb25nIGFzICpvbmUqIHVzIHVzZWQgO1wpKS9UKFRDbGF1c2VuKS9NKEQ6MjAx MjEwMDMxNjI5MzQrMDInMDAnKS9QIDY2IDAgUj4+CmVuZG9iago0NTMgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyMTUuMDAwIDQ5Mi4wNTAgNDY1LjAwMCA2MDQu MDUwXS9QYXJlbnQgNDUyIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjQ1NCAwIG9iago8PC9UeXBl L1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs4MS4wMDAgMjM4LjUwMCA0Nzcu MDAwIDI2MC4wNTBdL01hdHJpeFsxIDAgMCAxIC04MS4wMDAgLTIzOC41MDBdL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9N dWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTc4Pj5zdHJlYW0KcQovUjAgZ3MK MS4wMDAgMS4wMDAgMC4wMDAgcmcKMzgxLjAwMCAyNDkuNTAwIG0KNDc3LjAwMCAyNDkuNTAwIGwK NDc3LjAwMCAyNjAuMDUwIGwKMzgxLjAwMCAyNjAuMDUwIGwKZgo4MS4wMDAgMjM4LjUwMCBtCjEz NS4wMDAgMjM4LjUwMCBsCjEzNS4wMDAgMjQ5LjA1MCBsCjgxLjAwMCAyNDkuMDUwIGwKZgpRCgpl bmRzdHJlYW0KZW5kb2JqCjQ1NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0 L0YgNC9SZWN0WzgxLjAwMCAyMzguNTAwIDQ3Ny4wMDAgMjYwLjA1MF0vQ1sxLjAwMCAxLjAwMCAw LjAwMF0vUXVhZFBvaW50c1szODEuMDAwIDI2MC4wNTAgNDc3LjAwMCAyNjAuMDUwIDM4MS4wMDAg MjQ5LjUwMCA0NzcuMDAwIDI0OS41MDAgODEuMDAwIDI0OS4wNTAgMTM1LjAwMCAyNDkuMDUwIDgx LjAwMCAyMzguNTAwIDEzNS4wMDAgMjM4LjUwMF0vQVA8PC9OIDQ1NCAwIFIgPj4vVChUQ2xhdXNl bikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA2NiAwIFI+PgplbmRvYmoKNDU2IDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzM4NC4wMDAgMjU1LjA1MCA0MTQu MDAwIDI4NS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA0NTcg MCBSL0NvbnRlbnRzKFllcywgcGxlYXNlIGRvIDtcKSkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAz MTYyOTM0KzAyJzAwJykvUCA2NiAwIFI+PgplbmRvYmoKNDU3IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNDE5LjAwMCAxNzMuMDUwIDY2OS4wMDAgMjg1LjA1MF0v UGFyZW50IDQ1NiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago0NTggMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDQ1OSAwIFIvUmVjdFs4MS4wMDAgMTY3LjA1MCAxMTEu MDAwIDE5Ny4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhP SywgZ2VuZXJhbGx5Li4uLi5cblxuMVwpIEl0IG5lZWRzIHRvIGJlIHNhaWQgaG93IHRoZSBmaWVs ZHMgYXJlIGVuY29kZWQuIEZvciBtb3N0LCB0aGUgdGVybSAieHh4IGlzIGFuIG4tYml0IHVuc2ln bmVkIGludGVnZXIgZmllbGQsIHdoaWNoIC4uLiIgc2VlbXMgdG8gIGJlIHdoYXQgaXMgbmVlZGVk IFwodmVyc2lvbnMsIGxlbmd0aHMsIC4uLlwpXG5cbjJcKSBTb21lIGVuZXRpdGllcyBcKFJvdXRl cklEP1wpIGRvIG5vdCBoYXZlIGxlbmd0aCBub3IgcmVmZXJlbmNlcyBhcyB0byBob3cgdGhleSBh cmUgbWFkZS4gQXJlIHRoZXkgSVAgYWRkcmVzc2VzPyBNQUMgYWRkcmVzc2VzPyBEZXJpdmVkIHNv IGFzIHRvIGJlIHVuaXF1ZSwgYnV0IG90aGVyd2lzZSB3aXRob3V0IHNlbWFudGljcz9cblxuM1wp IEkgZG8gbm90IGtub3cgd2hhdCBhICJuIGJpdCB1bnNpZ25lZCBudW1iZXIiIGlzLCBidXQgSSBk byBrbm93IHdoYXQgYSAibiBiaXQgdW5zaWduZWQgaW50ZWdlciIgaXMuICBJIGFsc28gZG8gbm90 IGtub3cgd2hhdCBhICJuIGJpdCB1bnNpZ25lZCB2YWx1ZSIgaXMsIGFuZCBldmVuIGxlc3MgaG93 IHRvIGVuY29kZSAiYWRkL2Ryb3AiIGFuZCBvdGhlciAgdGV4dHVhbCB0aGluZ3MgaW50byBhbiBv Y3RldCwgdW5sZXNzIHRvbGQgc28uXG5cbkNoYW5nZSAibnVtYmVyIiBhbmQgInZhbHVlIiBhbmQg dGhlIGxpa2UgdG8gImludGVnZXIiLCBvciBJIHdpbGwgcHJvZHVjZSBhbiBpbXBsZW1lbnRhdGlv biB0cnlpbmcgdG8gcmVhZCBhIHZlcnNpb24gbnVtYmVyIGFzIGEgZmxvYXQgO1wpIEFuZCBmb3Ig ImFkZC9kcm9wIiwgdGVsbCBtZSBob3cgdG8gcmVwcmVzZW50IGl0LCBvciBJIHdpbGwgY29tZSB1 cCB3aXRoIGNyZWF0aXZlIGJpdC1wYXR0ZXJucy4uLi4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAw MzE2MjkzNCswMicwMCcpL1AgNjYgMCBSPj4KZW5kb2JqCjQ1OSAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzExNi4wMDAgODUuMDUwIDM2Ni4wMDAgMTk3LjA1MF0v UGFyZW50IDQ1OCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago0NjAgMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDQ2MSAwIFIvUmVjdFszNy45OTIgMjYyLjIxOSA2Ny45 OTIgMjkyLjIxOV0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKEkg c29ydGEgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBnb29kIHRvIHN0cnVjdHVyZSB0aGlzIHNlY3Rp b24gc29tZXdoYXQuIEZvciBleGFtcGxlOlxuXG5PbmUgc2VjdGlvbiBmb3IgIk1hbmRhdG9yeSBU TFZzIlxuT25lIHNlY3Rpb24gZm9yICJPcHRpb25hbCBUTFZzIlxuXG5PciBhIHN0cnVjdHVyZSB3 aXRoIGEgMm5kIGxldmVsIHNlY3Rpb24gZm9yIGFsbCBUTFZzIHJlbGF0ZWQgdG8gYSBzcGVjaWZp YyAic3RhdGUiIGluIHRoZSBETEVQIHN0YXRlIG1hY2hpbmU/XG5cbk9yIHNvbWV0aGluZz9cblxu QWxzbywgSSBhbSBzb21ld2hhdCBpZmZ5IG9uIHRoaXMgc2VjdGlvbiBtaXhpbmcgdGhlIHN5bnRh Y3RpY2FsIHN0cnVjdHVyZSBvZiB0aGUgbWVzc2FnZXMvVExWcywgYW5kIHRoZWlyIHByb2Nlc3Np bmcuIEkgd291bGQgZmluZCBpdCBhIGxvdCBjbGVhbmVyIHRvIHNlcGFyYXRlIHRoZSB0d28gLSBh IGxvdCBlYXNpZXIgdG8gcmVhZC9pbXBsZW1lbnQuIFRoZSBzZXBhcmF0aW9uIGlzIC0ga2luZGEg LSBzdGFydGVkIFwoc2VjdGlvbiAxMSBhbmQgZm9yd2FyZCBkZWZpbmVzIGhvdy93aGVuIG1lc3Nh Z2VzIGFyZSBzZW50XCksIHNvIEkgd291bGQgcmVjb21tZW5kIHRyaW1taW5nIHNvbWUgb2YgdGhh dCBpbmZvcm1hdGlvbiBmcm9tIHRoaXMgc2VjdGlvbi4gV3JpdGluZyB0aGUgc2FtZSB0aGluZyBp biBtb3JlIHRoYW4gb25lIHBsYWNlIGp1c3QgbWVhbnMgdGhhdCBpdCBpcyBlYXNpZXIgZm9yIHRo ZSBzcGVjaWZpY2F0aW9uIHRvIGNvbnRyYWRpY3QgaXRzZWxmIDtcKSkvVChUQ2xhdXNlbikvTShE OjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA2NiAwIFI+PgplbmRvYmoKNDYxIDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNzIuOTkyIDE4MC4yMTkgMzIyLjk5MiAy OTIuMjE5XS9QYXJlbnQgNDYwIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjY2IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA2OSAwIFIKL0ZvbnQgNzAg MCBSCj4+Ci9Db250ZW50cyA2NyAwIFIvQW5ub3RzIDQ0MiAwIFI+PgplbmRvYmoKNDQyIDAgb2Jq Cls0NDQgMCBSIDQ0NSAwIFIgMjk2IDAgUiA0NDcgMCBSIDQ0OCAwIFIgNDQ5IDAgUiA0NTEgMCBS IDQ1MiAwIFIgNDUzIDAgUiA0NTUgMCBSIDQ1NiAwIFIgNDU3IDAgUiA0NTggMCBSIDQ1OSAwIFIg NDYwIDAgUiA0NjEgMCBSXQplbmRvYmoKNDYzIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBl L0Zvcm0vRm9ybVR5cGUgMS9CQm94WzE2NS4wMDAgMTgzLjUwMCAyNDMuMDAwIDE5NC4wNTBdL01h dHJpeFsxIDAgMCAxIC0xNjUuMDAwIC0xODMuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4v UmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9F eHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAu MDAwIHJnCjE2NS4wMDAgMTgzLjUwMCBtCjI0My4wMDAgMTgzLjUwMCBsCjI0My4wMDAgMTk0LjA1 MCBsCjE2NS4wMDAgMTk0LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0NjQgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsxNjUuMDAwIDE4My41MDAgMjQz LjAwMCAxOTQuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzE2NS4wMDAgMTk0 LjA1MCAyNDMuMDAwIDE5NC4wNTAgMTY1LjAwMCAxODMuNTAwIDI0My4wMDAgMTgzLjUwMF0vQVA8 PC9OIDQ2MyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA3 MSAwIFI+PgplbmRvYmoKNDY2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9S ZWN0WzE4OS4wMDAgMTg5LjA1MCAyMTkuMDAwIDIxOS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAw IDEuMDAwIDAuMDAwXS9Qb3B1cCAzMDEgMCBSL0NvbnRlbnRzKEFzIERMRVAgaXMgIkRhdGEgTGlu ayBFeGNoYW5nZSBQcm90b2NvbCIsIHNheWluZyAiRExFUCBQcm90b2NvbCIgaXMgcmVkdW5kYW50 OiBleHBhbmRlZCBpdCBiZWNvbWVzICJEYXRhIExpbmsgRXhjaGFuZ2UgUHJvdG9jb2wgUHJvdG9j b2wiLlxuXG5TdWdnZXN0IHNheWluZyAiRExFUCBpcyBhIC4uLi4iIGluc3RlYWQgb2YgInRoZSBE TEVQIHByb3RvY29sIGlzIGEgLi4uLiIpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCsw MicwMCcpL1AgNzEgMCBSPj4KZW5kb2JqCjMwMSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv UG9wdXAvRiAyOC9SZWN0WzIyNC4wMDAgMTA3LjA1MCA0NzQuMDAwIDIxOS4wNTBdL1BhcmVudCA0 NjYgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNDY3IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzgxLjAwMCA0NjkuNTAwIDM3NS4wMDAgNjY3LjA1MF0v TWF0cml4WzEgMCAwIDEgLTgxLjAwMCAtNDY5LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+ L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUv RXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMzMwPj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAg MC4wMDAgcmcKMTQxLjAwMCA2NTYuNTAwIG0KMjc5LjAwMCA2NTYuNTAwIGwKMjc5LjAwMCA2Njcu MDUwIGwKMTQxLjAwMCA2NjcuMDUwIGwKZgo4MS4wMDAgNjQ1LjUwMCBtCjI2Ny4wMDAgNjQ1LjUw MCBsCjI2Ny4wMDAgNjU2LjA1MCBsCjgxLjAwMCA2NTYuMDUwIGwKZgo4MS4wMDAgNjM0LjUwMCBt CjI0OS4wMDAgNjM0LjUwMCBsCjI0OS4wMDAgNjQ1LjA1MCBsCjgxLjAwMCA2NDUuMDUwIGwKZgo4 MS4wMDAgNjIzLjUwMCBtCjI2Ny4wMDAgNjIzLjUwMCBsCjI2Ny4wMDAgNjM0LjA1MCBsCjgxLjAw MCA2MzQuMDUwIGwKZgo4MS4wMDAgNjEyLjUwMCBtCjI2Ny4wMDAgNjEyLjUwMCBsCjI2Ny4wMDAg NjIzLjA1MCBsCjgxLjAwMCA2MjMuMDUwIGwKZgo4MS4wMDAgNjAxLjUwMCBtCjMzMy4wMDAgNjAx LjUwMCBsCjMzMy4wMDAgNjEyLjA1MCBsCjgxLjAwMCA2MTIuMDUwIGwKZgo4MS4wMDAgNTkwLjUw MCBtCjMzMy4wMDAgNTkwLjUwMCBsCjMzMy4wMDAgNjAxLjA1MCBsCjgxLjAwMCA2MDEuMDUwIGwK Zgo4MS4wMDAgNTc5LjUwMCBtCjIzNy4wMDAgNTc5LjUwMCBsCjIzNy4wMDAgNTkwLjA1MCBsCjgx LjAwMCA1OTAuMDUwIGwKZgo4MS4wMDAgNTY4LjUwMCBtCjI0OS4wMDAgNTY4LjUwMCBsCjI0OS4w MDAgNTc5LjA1MCBsCjgxLjAwMCA1NzkuMDUwIGwKZgo4MS4wMDAgNTU3LjUwMCBtCjM3NS4wMDAg NTU3LjUwMCBsCjM3NS4wMDAgNTY4LjA1MCBsCjgxLjAwMCA1NjguMDUwIGwKZgo4MS4wMDAgNTQ2 LjUwMCBtCjM1Ny4wMDAgNTQ2LjUwMCBsCjM1Ny4wMDAgNTU3LjA1MCBsCjgxLjAwMCA1NTcuMDUw IGwKZgo4MS4wMDAgNTM1LjUwMCBtCjIzMS4wMDAgNTM1LjUwMCBsCjIzMS4wMDAgNTQ2LjA1MCBs CjgxLjAwMCA1NDYuMDUwIGwKZgo4MS4wMDAgNTI0LjUwMCBtCjM2My4wMDAgNTI0LjUwMCBsCjM2 My4wMDAgNTM1LjA1MCBsCjgxLjAwMCA1MzUuMDUwIGwKZgo4MS4wMDAgNTEzLjUwMCBtCjMzMy4w MDAgNTEzLjUwMCBsCjMzMy4wMDAgNTI0LjA1MCBsCjgxLjAwMCA1MjQuMDUwIGwKZgo4MS4wMDAg NTAyLjUwMCBtCjM3NS4wMDAgNTAyLjUwMCBsCjM3NS4wMDAgNTEzLjA1MCBsCjgxLjAwMCA1MTMu MDUwIGwKZgo4MS4wMDAgNDkxLjUwMCBtCjMxNS4wMDAgNDkxLjUwMCBsCjMxNS4wMDAgNTAyLjA1 MCBsCjgxLjAwMCA1MDIuMDUwIGwKZgo4MS4wMDAgNDgwLjUwMCBtCjI2Ny4wMDAgNDgwLjUwMCBs CjI2Ny4wMDAgNDkxLjA1MCBsCjgxLjAwMCA0OTEuMDUwIGwKZgo4MS4wMDAgNDY5LjUwMCBtCjI3 OS4wMDAgNDY5LjUwMCBsCjI3OS4wMDAgNDgwLjA1MCBsCjgxLjAwMCA0ODAuMDUwIGwKZgpRCgpl bmRzdHJlYW0KZW5kb2JqCjQ2OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0 L0YgNC9SZWN0WzgxLjAwMCA0NjkuNTAwIDM3NS4wMDAgNjY3LjA1MF0vQ1sxLjAwMCAxLjAwMCAw LjAwMF0vUXVhZFBvaW50c1sxNDEuMDAwIDY2Ny4wNTAgMjc5LjAwMCA2NjcuMDUwIDE0MS4wMDAg NjU2LjUwMCAyNzkuMDAwIDY1Ni41MDAgODEuMDAwIDY1Ni4wNTAgMjY3LjAwMCA2NTYuMDUwIDgx LjAwMCA2NDUuNTAwIDI2Ny4wMDAgNjQ1LjUwMCA4MS4wMDAgNjQ1LjA1MCAyNDkuMDAwIDY0NS4w NTAgODEuMDAwIDYzNC41MDAgMjQ5LjAwMCA2MzQuNTAwIDgxLjAwMCA2MzQuMDUwIDI2Ny4wMDAg NjM0LjA1MCA4MS4wMDAgNjIzLjUwMCAyNjcuMDAwIDYyMy41MDAgODEuMDAwIDYyMy4wNTAgMjY3 LjAwMCA2MjMuMDUwIDgxLjAwMCA2MTIuNTAwIDI2Ny4wMDAgNjEyLjUwMCA4MS4wMDAgNjEyLjA1 MCAzMzMuMDAwIDYxMi4wNTAgODEuMDAwIDYwMS41MDAgMzMzLjAwMCA2MDEuNTAwIDgxLjAwMCA2 MDEuMDUwIDMzMy4wMDAgNjAxLjA1MCA4MS4wMDAgNTkwLjUwMCAzMzMuMDAwIDU5MC41MDAgODEu MDAwIDU5MC4wNTAgMjM3LjAwMCA1OTAuMDUwIDgxLjAwMCA1NzkuNTAwIDIzNy4wMDAgNTc5LjUw MCA4MS4wMDAgNTc5LjA1MCAyNDkuMDAwIDU3OS4wNTAgODEuMDAwIDU2OC41MDAgMjQ5LjAwMCA1 NjguNTAwIDgxLjAwMCA1NjguMDUwIDM3NS4wMDAgNTY4LjA1MCA4MS4wMDAgNTU3LjUwMCAzNzUu MDAwIDU1Ny41MDAgODEuMDAwIDU1Ny4wNTAgMzU3LjAwMCA1NTcuMDUwIDgxLjAwMCA1NDYuNTAw IDM1Ny4wMDAgNTQ2LjUwMCA4MS4wMDAgNTQ2LjA1MCAyMzEuMDAwIDU0Ni4wNTAgODEuMDAwIDUz NS41MDAgMjMxLjAwMCA1MzUuNTAwIDgxLjAwMCA1MzUuMDUwIDM2My4wMDAgNTM1LjA1MCA4MS4w MDAgNTI0LjUwMCAzNjMuMDAwIDUyNC41MDAgODEuMDAwIDUyNC4wNTAgMzMzLjAwMCA1MjQuMDUw IDgxLjAwMCA1MTMuNTAwIDMzMy4wMDAgNTEzLjUwMCA4MS4wMDAgNTEzLjA1MCAzNzUuMDAwIDUx My4wNTAgODEuMDAwIDUwMi41MDAgMzc1LjAwMCA1MDIuNTAwIDgxLjAwMCA1MDIuMDUwIDMxNS4w MDAgNTAyLjA1MCA4MS4wMDAgNDkxLjUwMCAzMTUuMDAwIDQ5MS41MDAgODEuMDAwIDQ5MS4wNTAg MjY3LjAwMCA0OTEuMDUwIDgxLjAwMCA0ODAuNTAwIDI2Ny4wMDAgNDgwLjUwMCA4MS4wMDAgNDgw LjA1MCAyNzkuMDAwIDQ4MC4wNTAgODEuMDAwIDQ2OS41MDAgMjc5LjAwMCA0NjkuNTAwXS9BUDw8 L04gNDY3IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDcx IDAgUj4+CmVuZG9iago0NzAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1Jl Y3RbMjQzLjAwMCA0NzUuMDUwIDI3My4wMDAgNTA1LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAg MS4wMDAgMC4wMDBdL1BvcHVwIDQ2NSAwIFIvQ29udGVudHMoRm9yIHRoaXMsIHlvdSByZWFsbHkg c2hvdWxkIHNldCB1cCBcKGFuZCByZWZlcmVuY2VcKSB0aGUgSUFOQSByZWdpc3RyeSwgd2l0aCBt bmVtb25pY3MsIGFuZCB0aGVuIGp1c3QgdXNlIHRoYXQuIFRoaXMgdGFibGUgcmVhZHMgbGlrZSBh ICJtaW5pIElBTkEgc2VjdGlvbiwgb3V0c2lkZSBvZiB0aGUgSUFOQSBzZWN0aW9uIiwgd2hpY2gg aXMgYm91bmQgdG8gYmUgY29uZnVzaW5nIGFuZCBhIHNvdXJjZSBvZiBlcnJvcnMuKS9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDcxIDAgUj4+CmVuZG9iago0NjUgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyNzguMDAwIDM5My4wNTAg NTI4LjAwMCA1MDUuMDUwXS9QYXJlbnQgNDcwIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjQ3MSAw IG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsxODMuMDAw IDMyNi41MDAgMjczLjAwMCAzMzcuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMTgzLjAwMCAtMzI2LjUw MF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwv QUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0 cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoxODMuMDAwIDMyNi41MDAgbQoyNzMu MDAwIDMyNi41MDAgbAoyNzMuMDAwIDMzNy4wNTAgbAoxODMuMDAwIDMzNy4wNTAgbApmClEKCmVu ZHN0cmVhbQplbmRvYmoKNDcyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQv RiA0L1JlY3RbMTgzLjAwMCAzMjYuNTAwIDI3My4wMDAgMzM3LjA1MF0vQ1sxLjAwMCAxLjAwMCAw LjAwMF0vUXVhZFBvaW50c1sxODMuMDAwIDMzNy4wNTAgMjczLjAwMCAzMzcuMDUwIDE4My4wMDAg MzI2LjUwMCAyNzMuMDAwIDMyNi41MDBdL0FQPDwvTiA0NzEgMCBSID4+L1QoVENsYXVzZW4pL00o RDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNzEgMCBSPj4KZW5kb2JqCjQ3OCAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyNDAuMDAwIDMzMi4wNTAgMjcwLjAwMCAz NjIuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgNDY5IDAgUi9D b250ZW50cyhBbiA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyIGZpZWxkLCBjb250YWluaW5nIHRoZSBs ZW5ndGguLi4uKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDcxIDAg Uj4+CmVuZG9iago0NjkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVj dFsyNzUuMDAwIDI1MC4wNTAgNTI1LjAwMCAzNjIuMDUwXS9QYXJlbnQgNDc4IDAgUi9PcGVuIGZh bHNlPj4KZW5kb2JqCjQ3OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVj dFszNjAuMDAwIDI5OS4wNTAgMzkwLjAwMCAzMjkuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAx LjAwMCAwLjAwMF0vUG9wdXAgNDczIDAgUi9Db250ZW50cyhTaG91bGQgcHJvYmFibHkgYWRkIHRo YXQgdGhlIGVuY29kaW5nIGFuZCBpbnRlcm5hbCBzdHJ1Y3R1cmUgaGVyZW9mIGlzIHNwZWNpZmll ZCBmb3IgZWFjaCBvZiB0aGUgZGlmZmVyZW50IFRMViB0eXBlcywgZ2l2ZW4gaW4gdGhlIGZvbGxv d2luZy4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNzEgMCBSPj4K ZW5kb2JqCjQ3MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzM5 NS4wMDAgMjE3LjA1MCA2NDUuMDAwIDMyOS4wNTBdL1BhcmVudCA0NzkgMCBSL09wZW4gZmFsc2U+ PgplbmRvYmoKNzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDc0IDAgUgovRm9udCA3NSAwIFIKPj4KL0NvbnRlbnRzIDcyIDAgUi9Bbm5vdHMgNDYy IDAgUj4+CmVuZG9iago0NjIgMCBvYmoKWzQ2NCAwIFIgNDY2IDAgUiAzMDEgMCBSIDQ2OCAwIFIg NDcwIDAgUiA0NjUgMCBSIDQ3MiAwIFIgNDc4IDAgUiA0NjkgMCBSIDQ3OSAwIFIgNDczIDAgUl0K ZW5kb2JqCjQ4MSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEv QkJveFsyNzMuMDAwIDUxMy41MDAgMzMzLjAwMCA1MjQuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMjcz LjAwMCAtNTEzLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdT dGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xl bmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoyNzMuMDAwIDUx My41MDAgbQozMzMuMDAwIDUxMy41MDAgbAozMzMuMDAwIDUyNC4wNTAgbAoyNzMuMDAwIDUyNC4w NTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKNDgyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9IaWdobGlnaHQvRiA0L1JlY3RbMjczLjAwMCA1MTMuNTAwIDMzMy4wMDAgNTI0LjA1MF0vQ1sx LjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1syNzMuMDAwIDUyNC4wNTAgMzMzLjAwMCA1MjQu MDUwIDI3My4wMDAgNTEzLjUwMCAzMzMuMDAwIDUxMy41MDBdL0FQPDwvTiA0ODEgMCBSID4+L1Qo VENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgNzYgMCBSPj4KZW5kb2JqCjQ4 MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyODIuMDAwIDUxOS4w NTAgMzEyLjAwMCA1NDkuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9w dXAgNDc2IDAgUi9Db250ZW50cyhUaGlzIGFwcGxpZXMgdGhyb3VnaG91dCB0aGlzIHNlY3Rpb246 XG5cbkhvdyBiaWcgaXMgdGhhdCBmaWVsZCwgYW5kIGhvdyBpcyBpdCBlbmNvZGVkP1xuUm91dGVy SUQsIGlzIHRoYXQgYSBXZWxsIEtub3duIEVudGl0eT8pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAw MzE2MjkzNCswMicwMCcpL1AgNzYgMCBSPj4KZW5kb2JqCjQ3NiAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzMxNy4wMDAgNDM3LjA1MCA1NjcuMDAwIDU0OS4wNTBd L1BhcmVudCA0ODMgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNzYgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc5IDAgUgovRm9udCA4MCAwIFIKPj4K L0NvbnRlbnRzIDc3IDAgUi9Bbm5vdHMgNDgwIDAgUj4+CmVuZG9iago0ODAgMCBvYmoKWzQ4MiAw IFIgNDgzIDAgUiA0NzYgMCBSXQplbmRvYmoKNDg1IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzMzMy4wMDAgNTc5LjUwMCAzNTEuMDAwIDU5MC4wNTBd L01hdHJpeFsxIDAgMCAxIC0zMzMuMDAwIC01NzkuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5 Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlw ZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAw IDAuMDAwIHJnCjMzMy4wMDAgNTc5LjUwMCBtCjM1MS4wMDAgNTc5LjUwMCBsCjM1MS4wMDAgNTkw LjA1MCBsCjMzMy4wMDAgNTkwLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0ODYgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszMzMuMDAwIDU3OS41MDAg MzUxLjAwMCA1OTAuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzMzMy4wMDAg NTkwLjA1MCAzNTEuMDAwIDU5MC4wNTAgMzMzLjAwMCA1NzkuNTAwIDM1MS4wMDAgNTc5LjUwMF0v QVA8PC9OIDQ4NSAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykv UCA4MSAwIFI+PgplbmRvYmoKNDg3IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0v Rm9ybVR5cGUgMS9CQm94WzMyNy4wMDAgNTc5LjUwMCAzNDUuMDAwIDU5MC4wNTBdL01hdHJpeFsx IDAgMCAxIC0zMjcuMDAwIC01NzkuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3Vy Y2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3Rh dGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJn CjMyNy4wMDAgNTc5LjUwMCBtCjM0NS4wMDAgNTc5LjUwMCBsCjM0NS4wMDAgNTkwLjA1MCBsCjMy Ny4wMDAgNTkwLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0ODggMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszMjcuMDAwIDU3OS41MDAgMzQ1LjAwMCA1 OTAuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzMyNy4wMDAgNTkwLjA1MCAz NDUuMDAwIDU5MC4wNTAgMzI3LjAwMCA1NzkuNTAwIDM0NS4wMDAgNTc5LjUwMF0vQVA8PC9OIDQ4 NyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA4MSAwIFI+ PgplbmRvYmoKNDg5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzMx NS4wMDAgNTg1LjA1MCAzNDUuMDAwIDYxNS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAw IDAuMDAwXS9Qb3B1cCAzMzAgMCBSL0NvbnRlbnRzKFRoZSBSRkMgZWRpdG9yIHVzZXM6XG5cbgki Li4uYmxhaCBibGFoLCBlLmcuLCBibGFoIGJsYWgiXG5cbmFuZFxuCSIuLi5ibGFoIGJsYWgsIGku ZS4sIGJsYWggYmxhaCJcblxuUmVjb21tZW5kIG1ha2luZyB0aGVpciBsaWZlIGVhc2llciBcKGFu ZCByZWR1Y2luZyB0aGVpciBwcm9jZXNzaW5nIHRpbWVcKSBieSBqdXN0IGRvaW5nIHRoaXMgZnJv bSB0aGUgc3RhcnQgO1wpKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9Q IDgxIDAgUj4+CmVuZG9iagozMzAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0Yg MjgvUmVjdFszNTAuMDAwIDUwMy4wNTAgNjAwLjAwMCA2MTUuMDUwXS9QYXJlbnQgNDg5IDAgUi9P cGVuIGZhbHNlPj4KZW5kb2JqCjQ5MCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3Jt L0Zvcm1UeXBlIDEvQkJveFsxMDUuMDAwIDQ4MC41MDAgMTI5LjAwMCA0OTEuMDUwXS9NYXRyaXhb MSAwIDAgMSAtMTA1LjAwMCAtNDgwLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291 cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0 YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCBy ZwoxMDUuMDAwIDQ4MC41MDAgbQoxMjkuMDAwIDQ4MC41MDAgbAoxMjkuMDAwIDQ5MS4wNTAgbAox MDUuMDAwIDQ5MS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKNDkxIDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMTA1LjAwMCA0ODAuNTAwIDEyOS4wMDAg NDkxLjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxMDUuMDAwIDQ5MS4wNTAg MTI5LjAwMCA0OTEuMDUwIDEwNS4wMDAgNDgwLjUwMCAxMjkuMDAwIDQ4MC41MDBdL0FQPDwvTiA0 OTAgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgODEgMCBS Pj4KZW5kb2JqCjQ5MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsx MDIuMDAwIDQ4Ni4wNTAgMTMyLjAwMCA1MTYuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAw MCAwLjAwMF0vUG9wdXAgMzM0IDAgUi9Db250ZW50cyhUaGUgUkZDIGVkaXRvciB1c2VzOlxuXG4J Ii4uLmJsYWggYmxhaCwgZS5nLiwgYmxhaCBibGFoIlxuXG5hbmRcbgkiLi4uYmxhaCBibGFoLCBp LmUuLCBibGFoIGJsYWgiXG5cblJlY29tbWVuZCBtYWtpbmcgdGhlaXIgbGlmZSBlYXNpZXIgXChh bmQgcmVkdWNpbmcgdGhlaXIgcHJvY2Vzc2luZyB0aW1lXCkgYnkganVzdCBkb2luZyB0aGlzIGZy b20gdGhlIHN0YXJ0IDtcKSkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykv UCA4MSAwIFI+PgplbmRvYmoKMzM0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9G IDI4L1JlY3RbMTM3LjAwMCA0MDQuMDUwIDM4Ny4wMDAgNTE2LjA1MF0vUGFyZW50IDQ5MiAwIFIv T3BlbiBmYWxzZT4+CmVuZG9iago0OTMgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9y bS9Gb3JtVHlwZSAxL0JCb3hbMTA1LjAwMCAyMzguNTAwIDEyOS4wMDAgMjQ5LjA1MF0vTWF0cml4 WzEgMCAwIDEgLTEwNS4wMDAgLTIzOC41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNv dXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdT dGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAg cmcKMTA1LjAwMCAyMzguNTAwIG0KMTI5LjAwMCAyMzguNTAwIGwKMTI5LjAwMCAyNDkuMDUwIGwK MTA1LjAwMCAyNDkuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjQ5NCAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzEwNS4wMDAgMjM4LjUwMCAxMjkuMDAw IDI0OS4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMTA1LjAwMCAyNDkuMDUw IDEyOS4wMDAgMjQ5LjA1MCAxMDUuMDAwIDIzOC41MDAgMTI5LjAwMCAyMzguNTAwXS9BUDw8L04g NDkzIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDgxIDAg Uj4+CmVuZG9iago0OTUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3Rb MTAyLjAwMCAyNDQuMDUwIDEzMi4wMDAgMjc0LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4w MDAgMC4wMDBdL1BvcHVwIDMzOCAwIFIvQ29udGVudHMoVGhlIFJGQyBlZGl0b3IgdXNlczpcblxu CSIuLi5ibGFoIGJsYWgsIGUuZy4sIGJsYWggYmxhaCJcblxuYW5kXG4JIi4uLmJsYWggYmxhaCwg aS5lLiwgYmxhaCBibGFoIlxuXG5SZWNvbW1lbmQgbWFraW5nIHRoZWlyIGxpZmUgZWFzaWVyIFwo YW5kIHJlZHVjaW5nIHRoZWlyIHByb2Nlc3NpbmcgdGltZVwpIGJ5IGp1c3QgZG9pbmcgdGhpcyBm cm9tIHRoZSBzdGFydCA7XCkpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcp L1AgODEgMCBSPj4KZW5kb2JqCjMzOCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAv RiAyOC9SZWN0WzEzNy4wMDAgMTYyLjA1MCAzODcuMDAwIDI3NC4wNTBdL1BhcmVudCA0OTUgMCBS L09wZW4gZmFsc2U+PgplbmRvYmoKNDk2IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zv cm0vRm9ybVR5cGUgMS9CQm94WzIxMy4wMDAgMzM3LjUwMCAyNDkuMDAwIDM0OC4wNTBdL01hdHJp eFsxIDAgMCAxIC0yMTMuMDAwIC0zMzcuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVz b3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRH U3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAw IHJnCjIxMy4wMDAgMzM3LjUwMCBtCjI0OS4wMDAgMzM3LjUwMCBsCjI0OS4wMDAgMzQ4LjA1MCBs CjIxMy4wMDAgMzQ4LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago0OTcgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsyMTMuMDAwIDMzNy41MDAgMjQ5LjAw MCAzNDguMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzIxMy4wMDAgMzQ4LjA1 MCAyNDkuMDAwIDM0OC4wNTAgMjEzLjAwMCAzMzcuNTAwIDI0OS4wMDAgMzM3LjUwMF0vQVA8PC9O IDQ5NiAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA4MSAw IFI+PgplbmRvYmoKNTAwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0 WzIxNi4wMDAgMzQzLjA1MCAyNDYuMDAwIDM3My4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEu MDAwIDAuMDAwXS9Qb3B1cCA1MDEgMCBSL0NvbnRlbnRzKEVuY29kZWQgaG93PykvVChUQ2xhdXNl bikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA4MSAwIFI+PgplbmRvYmoKNTAxIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjUxLjAwMCAyNjEuMDUwIDUw MS4wMDAgMzczLjA1MF0vUGFyZW50IDUwMCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago1MDMgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMjM3LjAwMCA2NDAuMDUwIDI2 Ny4wMDAgNjcwLjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDUw NSAwIFIvQ29udGVudHMoRW5jb2RlZCBob3c/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5 MzQrMDInMDAnKS9QIDgxIDAgUj4+CmVuZG9iago1MDUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL1BvcHVwL0YgMjgvUmVjdFsyNzIuMDAwIDU1OC4wNTAgNTIyLjAwMCA2NzAuMDUwXS9QYXJl bnQgNTAzIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjUwNiAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvVGV4dC9GIDQvUmVjdFsyMzcuMDAwIDYxOC4wNTAgMjY3LjAwMCA2NDguMDUwXS9OYW1l L0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgNTA3IDAgUi9Db250ZW50cyhFbmNv ZGVkIGhvdz8pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgODEgMCBS Pj4KZW5kb2JqCjUwNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0 WzI3Mi4wMDAgNTM2LjA1MCA1MjIuMDAwIDY0OC4wNTBdL1BhcmVudCA1MDYgMCBSL09wZW4gZmFs c2U+PgplbmRvYmoKODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0K L1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov RXh0R1N0YXRlIDg0IDAgUgovRm9udCA4NSAwIFIKPj4KL0NvbnRlbnRzIDgyIDAgUi9Bbm5vdHMg NDg0IDAgUj4+CmVuZG9iago0ODQgMCBvYmoKWzQ4NiAwIFIgNDg4IDAgUiA0ODkgMCBSIDMzMCAw IFIgNDkxIDAgUiA0OTIgMCBSIDMzNCAwIFIgNDk0IDAgUiA0OTUgMCBSIDMzOCAwIFIgNDk3IDAg UiA1MDAgMCBSIDUwMSAwIFIgNTAzIDAgUiA1MDUgMCBSIDUwNiAwIFIgNTA3IDAgUl0KZW5kb2Jq CjUwOSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyMDcuMDAwIDIy Mi4wNTAgMjM3LjAwMCAyNTIuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0v UG9wdXAgNDk5IDAgUi9Db250ZW50cyhFbmNvZGVkIGhvdz8pL1QoVENsYXVzZW4pL00oRDoyMDEy MTAwMzE2MjkzNCswMicwMCcpL1AgODYgMCBSPj4KZW5kb2JqCjQ5OSAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzI0Mi4wMDAgMTQwLjA1MCA0OTIuMDAwIDI1Mi4w NTBdL1BhcmVudCA1MDkgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKODYgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDg5IDAgUgovRm9udCA5MCAwIFIK Pj4KL0NvbnRlbnRzIDg3IDAgUi9Bbm5vdHMgNTA4IDAgUj4+CmVuZG9iago1MDggMCBvYmoKWzUw OSAwIFIgNDk5IDAgUl0KZW5kb2JqCjUxMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4 dC9GIDQvUmVjdFsxODkuMDAwIDMxMC4wNTAgMjE5LjAwMCAzNDAuMDUwXS9OYW1lL0NvbW1lbnQv Q1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgNTAyIDAgUi9Db250ZW50cyhFbmNvZGVkIGhvdz8p L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgOTEgMCBSPj4KZW5kb2Jq CjUwMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzIyNC4wMDAg MjI4LjA1MCA0NzQuMDAwIDM0MC4wNTBdL1BhcmVudCA1MTMgMCBSL09wZW4gZmFsc2U+PgplbmRv YmoKOTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDk0IDAgUgovRm9udCA5NSAwIFIKPj4KL0NvbnRlbnRzIDkyIDAgUi9Bbm5vdHMgNTEwIDAgUj4+ CmVuZG9iago1MTAgMCBvYmoKWzUxMyAwIFIgNTAyIDAgUl0KZW5kb2JqCjUxNyAwIG9iago8PC9U eXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsyMDEuMDAwIDI2MC41MDAg Mjg1LjAwMCAyNzEuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMjAxLjAwMCAtMjYwLjUwMF0vR3JvdXA8 PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNl L0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9S MCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoyMDEuMDAwIDI2MC41MDAgbQoyODUuMDAwIDI2MC41 MDAgbAoyODUuMDAwIDI3MS4wNTAgbAoyMDEuMDAwIDI3MS4wNTAgbApmClEKCmVuZHN0cmVhbQpl bmRvYmoKNTE4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3Rb MjAxLjAwMCAyNjAuNTAwIDI4NS4wMDAgMjcxLjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVh ZFBvaW50c1syMDEuMDAwIDI3MS4wNTAgMjg1LjAwMCAyNzEuMDUwIDIwMS4wMDAgMjYwLjUwMCAy ODUuMDAwIDI2MC41MDBdL0FQPDwvTiA1MTcgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAw MzE2MjkzNCswMicwMCcpL1AgOTYgMCBSPj4KZW5kb2JqCjUxOSAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgNDk4IDAgUi9SZWN0WzIyNS4wMDAgMjY2LjA1MCAyNTUu MDAwIDI5Ni4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhX YWl0LCB3aGF0P1xuXG4xXCkgVGhpcyBUTFYgZG9lc24ndCBtYXRjaCB0aGUgb3RoZXIgVExWczog bGVuZ3RoIGNvbWVzIGFmdGVyIHR5cGUuIEhlbmNlLCBuZWVkcyBkaWZmZXJlbnQgcGFyc2VyLWxv Z2ljIHdoZXJlIG5vbmUgaXMgbmVlZGVkLlxuXG4yXCkgVGhlIFRMViBGbGFncyBzZW1hbnRpY3Mg aXMgbm90IGRlZmluZWQgYW55d2hlcmUsIHdoYXQgZG9lcyBpdCBtZWFuIHRoYXQgaXQgaXMgc2V0 IHRvIDB4MTAgPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCA5NiAw IFI+PgplbmRvYmoKNDk4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1Jl Y3RbMjYwLjAwMCAxODQuMDUwIDUxMC4wMDAgMjk2LjA1MF0vUGFyZW50IDQ5NyAwIFIvT3BlbiBm YWxzZT4+CmVuZG9iago1MjAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3Jt VHlwZSAxL0JCb3hbMzMzLjAwMCAxMzkuNTAwIDM2OS4wMDAgMTUwLjA1MF0vTWF0cml4WzEgMCAw IDEgLTMzMy4wMDAgLTEzOS41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8 PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+ Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzMz LjAwMCAxMzkuNTAwIG0KMzY5LjAwMCAxMzkuNTAwIGwKMzY5LjAwMCAxNTAuMDUwIGwKMzMzLjAw MCAxNTAuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjUyMSAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzMzMy4wMDAgMTM5LjUwMCAzNjkuMDAwIDE1MC4w NTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzMzLjAwMCAxNTAuMDUwIDM2OS4w MDAgMTUwLjA1MCAzMzMuMDAwIDEzOS41MDAgMzY5LjAwMCAxMzkuNTAwXS9BUDw8L04gNTIwIDAg UiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDk2IDAgUj4+CmVu ZG9iago1MjIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzM2LjAw MCAxNDUuMDUwIDM2Ni4wMDAgMTc1LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4w MDBdL1BvcHVwIDUxMSAwIFIvQ29udGVudHMoaW50ZWdlcikvVChUQ2xhdXNlbikvTShEOjIwMTIx MDAzMTYyOTM0KzAyJzAwJykvUCA5NiAwIFI+PgplbmRvYmoKNTExIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzcxLjAwMCA2My4wNTAgNjIxLjAwMCAxNzUuMDUw XS9QYXJlbnQgNTIyIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjUyMyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFszMzYuMDAwIDQ4Ni4wNTAgMzY2LjAwMCA1MTYuMDUw XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgNTE0IDAgUi9Db250ZW50 cyhpbnRlZ2VyKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDk2IDAg Uj4+CmVuZG9iago1MTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVj dFszNzEuMDAwIDQwNC4wNTAgNjIxLjAwMCA1MTYuMDUwXS9QYXJlbnQgNTIzIDAgUi9PcGVuIGZh bHNlPj4KZW5kb2JqCjUyNCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1U eXBlIDEvQkJveFszMzMuMDAwIDQ4MC41MDAgMzY5LjAwMCA0OTEuMDUwXS9NYXRyaXhbMSAwIDAg MSAtMzMzLjAwMCAtNDgwLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8 L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+ Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwozMzMu MDAwIDQ4MC41MDAgbQozNjkuMDAwIDQ4MC41MDAgbAozNjkuMDAwIDQ5MS4wNTAgbAozMzMuMDAw IDQ5MS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKNTI1IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMzMzLjAwMCA0ODAuNTAwIDM2OS4wMDAgNDkxLjA1 MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1szMzMuMDAwIDQ5MS4wNTAgMzY5LjAw MCA0OTEuMDUwIDMzMy4wMDAgNDgwLjUwMCAzNjkuMDAwIDQ4MC41MDBdL0FQPDwvTiA1MjQgMCBS ID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgOTYgMCBSPj4KZW5k b2JqCjk2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSA5OSAwIFIKL0ZvbnQgMTAwIDAgUgo+PgovQ29udGVudHMgOTcgMCBSL0Fubm90cyA1MTUgMCBS Pj4KZW5kb2JqCjUxNSAwIG9iagpbNTE4IDAgUiA1MTkgMCBSIDQ5OCAwIFIgNTIxIDAgUiA1MjIg MCBSIDUxMSAwIFIgNTIzIDAgUiA1MTQgMCBSIDUyNSAwIFJdCmVuZG9iago1MjcgMCBvYmoKPDwv VHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMjk3LjAwMCAyODIuNTAw IDMzMy4wMDAgMjkzLjA1MF0vTWF0cml4WzEgMCAwIDEgLTI5Ny4wMDAgLTI4Mi41MDBdL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxz ZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQov UjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMjk3LjAwMCAyODIuNTAwIG0KMzMzLjAwMCAyODIu NTAwIGwKMzMzLjAwMCAyOTMuMDUwIGwKMjk3LjAwMCAyOTMuMDUwIGwKZgpRCgplbmRzdHJlYW0K ZW5kb2JqCjUyOCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0 WzI5Ny4wMDAgMjgyLjUwMCAzMzMuMDAwIDI5My4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1 YWRQb2ludHNbMjk3LjAwMCAyOTMuMDUwIDMzMy4wMDAgMjkzLjA1MCAyOTcuMDAwIDI4Mi41MDAg MzMzLjAwMCAyODIuNTAwXS9BUDw8L04gNTI3IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEw MDMxNjI5MzQrMDInMDAnKS9QIDEwMSAwIFI+PgplbmRvYmoKNTI5IDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzMwMC4wMDAgMjg4LjA1MCAzMzAuMDAwIDMxOC4wNTBd L05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA1MTIgMCBSL0NvbnRlbnRz KGludGVnZXIpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTAxIDAg Uj4+CmVuZG9iago1MTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVj dFszMzUuMDAwIDIwNi4wNTAgNTg1LjAwMCAzMTguMDUwXS9QYXJlbnQgNTI5IDAgUi9PcGVuIGZh bHNlPj4KZW5kb2JqCjEwMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzky XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMTA0IDAgUgovRm9udCAxMDUgMCBSCj4+Ci9Db250ZW50cyAxMDIgMCBSL0Fu bm90cyA1MjYgMCBSPj4KZW5kb2JqCjUyNiAwIG9iagpbNTI4IDAgUiA1MjkgMCBSIDUxMiAwIFJd CmVuZG9iago1MzEgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAx L0JCb3hbNDA1LjAwMCAzNzAuNTAwIDQyOS4wMDAgMzgxLjA1MF0vTWF0cml4WzEgMCAwIDEgLTQw NS4wMDAgLTM3MC41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRH U3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9M ZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKNDA1LjAwMCAz NzAuNTAwIG0KNDI5LjAwMCAzNzAuNTAwIGwKNDI5LjAwMCAzODEuMDUwIGwKNDA1LjAwMCAzODEu MDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjUzMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzQwNS4wMDAgMzcwLjUwMCA0MjkuMDAwIDM4MS4wNTBdL0Nb MS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbNDA1LjAwMCAzODEuMDUwIDQyOS4wMDAgMzgx LjA1MCA0MDUuMDAwIDM3MC41MDAgNDI5LjAwMCAzNzAuNTAwXS9BUDw8L04gNTMxIDAgUiA+Pi9U KFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDEwNiAwIFI+PgplbmRvYmoK NTMzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzQwMi4wMDAgMzc2 LjA1MCA0MzIuMDAwIDQwNi4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Q b3B1cCAzNDMgMCBSL0NvbnRlbnRzKFRoZSBSRkMgZWRpdG9yIHVzZXM6XG5cbgkiLi4uYmxhaCBi bGFoLCBlLmcuLCBibGFoIGJsYWgiXG5cbmFuZFxuCSIuLi5ibGFoIGJsYWgsIGkuZS4sIGJsYWgg YmxhaCJcblxuUmVjb21tZW5kIG1ha2luZyB0aGVpciBsaWZlIGVhc2llciBcKGFuZCByZWR1Y2lu ZyB0aGVpciBwcm9jZXNzaW5nIHRpbWVcKSBieSBqdXN0IGRvaW5nIHRoaXMgZnJvbSB0aGUgc3Rh cnQgO1wpKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDEwNiAwIFI+ PgplbmRvYmoKMzQzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3Rb NDM3LjAwMCAyOTQuMDUwIDY4Ny4wMDAgNDA2LjA1MF0vUGFyZW50IDUzMyAwIFIvT3BlbiBmYWxz ZT4+CmVuZG9iago1MzQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3Rb MTc3LjAwMCAyMDAuMDUwIDIwNy4wMDAgMjMwLjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4w MDAgMC4wMDBdL1BvcHVwIDUwNCAwIFIvQ29udGVudHMoOCBiaXQgdW5zaWduZWQgaW50ZWdlcj8p L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTA2IDAgUj4+CmVuZG9i ago1MDQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyMTIuMDAw IDExOC4wNTAgNDYyLjAwMCAyMzAuMDUwXS9QYXJlbnQgNTM0IDAgUi9PcGVuIGZhbHNlPj4KZW5k b2JqCjUzNSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJv eFsyOTcuMDAwIDU1Ny41MDAgMzI3LjAwMCA1NjguMDUwXS9NYXRyaXhbMSAwIDAgMSAtMjk3LjAw MCAtNTU3LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0 ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0 aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoyOTcuMDAwIDU1Ny41 MDAgbQozMjcuMDAwIDU1Ny41MDAgbAozMjcuMDAwIDU2OC4wNTAgbAoyOTcuMDAwIDU2OC4wNTAg bApmClEKCmVuZHN0cmVhbQplbmRvYmoKNTM2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9I aWdobGlnaHQvRiA0L1JlY3RbMjk3LjAwMCA1NTcuNTAwIDMyNy4wMDAgNTY4LjA1MF0vQ1sxLjAw MCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1syOTcuMDAwIDU2OC4wNTAgMzI3LjAwMCA1NjguMDUw IDI5Ny4wMDAgNTU3LjUwMCAzMjcuMDAwIDU1Ny41MDBdL0FQPDwvTiA1MzUgMCBSID4+L1QoVENs YXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTA2IDAgUj4+CmVuZG9iago1Mzcg MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMjk3LjAwMCA1NjMuMDUw IDMyNy4wMDAgNTkzLjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVw IDUxNiAwIFIvQ29udGVudHMoaW50ZWdlcikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0 KzAyJzAwJykvUCAxMDYgMCBSPj4KZW5kb2JqCjUxNiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvUG9wdXAvRiAyOC9SZWN0WzMzMi4wMDAgNDgxLjA1MCA1ODIuMDAwIDU5My4wNTBdL1BhcmVu dCA1MzcgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTA2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMDkgMCBSCi9Gb250IDExMCAwIFIKPj4KL0Nv bnRlbnRzIDEwNyAwIFIvQW5ub3RzIDUzMCAwIFI+PgplbmRvYmoKNTMwIDAgb2JqCls1MzIgMCBS IDUzMyAwIFIgMzQzIDAgUiA1MzQgMCBSIDUwNCAwIFIgNTM2IDAgUiA1MzcgMCBSIDUxNiAwIFJd CmVuZG9iago1MzkgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAx L0JCb3hbMzU3LjAwMCA0MjUuNTAwIDM5My4wMDAgNDM2LjA1MF0vTWF0cml4WzEgMCAwIDEgLTM1 Ny4wMDAgLTQyNS41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRH U3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9M ZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzU3LjAwMCA0 MjUuNTAwIG0KMzkzLjAwMCA0MjUuNTAwIGwKMzkzLjAwMCA0MzYuMDUwIGwKMzU3LjAwMCA0MzYu MDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjU0MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzM1Ny4wMDAgNDI1LjUwMCAzOTMuMDAwIDQzNi4wNTBdL0Nb MS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzU3LjAwMCA0MzYuMDUwIDM5My4wMDAgNDM2 LjA1MCAzNTcuMDAwIDQyNS41MDAgMzkzLjAwMCA0MjUuNTAwXS9BUDw8L04gNTM5IDAgUiA+Pi9U KFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDExMSAwIFI+PgplbmRvYmoK NTQxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzM2MC4wMDAgNDMx LjA1MCAzOTAuMDAwIDQ2MS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Q b3B1cCA1NDIgMCBSL0NvbnRlbnRzKGVuY29kZWQgaG93PykvVChUQ2xhdXNlbikvTShEOjIwMTIx MDAzMTYyOTM0KzAyJzAwJykvUCAxMTEgMCBSPj4KZW5kb2JqCjU0MiAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzM5NS4wMDAgMzQ5LjA1MCA2NDUuMDAwIDQ2MS4w NTBdL1BhcmVudCA1NDEgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNTQzIDAgb2JqCjw8L1R5cGUv WE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzQxMS4wMDAgMTUwLjUwMCA0NTku MDAwIDE2MS4wNTBdL01hdHJpeFsxIDAgMCAxIC00MTEuMDAwIC0xNTAuNTAwXS9Hcm91cDw8L1Mv VHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0v TXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdz CjEuMDAwIDEuMDAwIDAuMDAwIHJnCjQxMS4wMDAgMTUwLjUwMCBtCjQ1OS4wMDAgMTUwLjUwMCBs CjQ1OS4wMDAgMTYxLjA1MCBsCjQxMS4wMDAgMTYxLjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9i ago1NDQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs0MTEu MDAwIDE1MC41MDAgNDU5LjAwMCAxNjEuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9p bnRzWzQxMS4wMDAgMTYxLjA1MCA0NTkuMDAwIDE2MS4wNTAgNDExLjAwMCAxNTAuNTAwIDQ1OS4w MDAgMTUwLjUwMF0vQVA8PC9OIDU0MyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYy OTM0KzAyJzAwJykvUCAxMTEgMCBSPj4KZW5kb2JqCjU0NSAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvVGV4dC9GIDQvUmVjdFs0MjAuMDAwIDE1Ni4wNTAgNDUwLjAwMCAxODYuMDUwXS9OYW1l L0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgNTQ2IDAgUi9Db250ZW50cyhTZXQg dXAgYW4gSUFOQSByZWdpc3RyeSBmb3IgdGhpcywgcHJvdmlkZSBkZWZhdWx0IHJlZ2lzdHJhdGlv bnMsIGFuZCByZWZlcmVuY2UgdGhhdCByZWdpc3RyeSBoZXJlLikvVChUQ2xhdXNlbikvTShEOjIw MTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxMTEgMCBSPj4KZW5kb2JqCjU0NiAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzQ1NS4wMDAgNzQuMDUwIDcwNS4wMDAgMTg2 LjA1MF0vUGFyZW50IDU0NSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxMTEgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDExNCAwIFIKL0ZvbnQgMTE1 IDAgUgo+PgovQ29udGVudHMgMTEyIDAgUi9Bbm5vdHMgNTM4IDAgUj4+CmVuZG9iago1MzggMCBv YmoKWzU0MCAwIFIgNTQxIDAgUiA1NDIgMCBSIDU0NCAwIFIgNTQ1IDAgUiA1NDYgMCBSXQplbmRv YmoKNTQ4IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94 WzM2My4wMDAgNjU2LjUwMCAzODcuMDAwIDY2Ny4wNTBdL01hdHJpeFsxIDAgMCAxIC0zNjMuMDAw IC02NTYuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRl PDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3Ro IDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjM2My4wMDAgNjU2LjUw MCBtCjM4Ny4wMDAgNjU2LjUwMCBsCjM4Ny4wMDAgNjY3LjA1MCBsCjM2My4wMDAgNjY3LjA1MCBs CmYKUQoKZW5kc3RyZWFtCmVuZG9iago1NDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hp Z2hsaWdodC9GIDQvUmVjdFszNjMuMDAwIDY1Ni41MDAgMzg3LjAwMCA2NjcuMDUwXS9DWzEuMDAw IDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzM2My4wMDAgNjY3LjA1MCAzODcuMDAwIDY2Ny4wNTAg MzYzLjAwMCA2NTYuNTAwIDM4Ny4wMDAgNjU2LjUwMF0vQVA8PC9OIDU0OCAwIFIgPj4vVChUQ2xh dXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxMTYgMCBSPj4KZW5kb2JqCjU1MCAw IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFszNTcuMDAwIDY2Mi4wNTAg Mzg3LjAwMCA2OTIuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAg MzQ4IDAgUi9Db250ZW50cyhUaGUgUkZDIGVkaXRvciB1c2VzOlxuXG4JIi4uLmJsYWggYmxhaCwg ZS5nLiwgYmxhaCBibGFoIlxuXG5hbmRcbgkiLi4uYmxhaCBibGFoLCBpLmUuLCBibGFoIGJsYWgi XG5cblJlY29tbWVuZCBtYWtpbmcgdGhlaXIgbGlmZSBlYXNpZXIgXChhbmQgcmVkdWNpbmcgdGhl aXIgcHJvY2Vzc2luZyB0aW1lXCkgYnkganVzdCBkb2luZyB0aGlzIGZyb20gdGhlIHN0YXJ0IDtc KSkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxMTYgMCBSPj4KZW5k b2JqCjM0OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzM5Mi4w MDAgNTgwLjA1MCA2NDIuMDAwIDY5Mi4wNTBdL1BhcmVudCA1NTAgMCBSL09wZW4gZmFsc2U+Pgpl bmRvYmoKNTUxIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9C Qm94WzM5OS4wMDAgNTEzLjUwMCA0MjMuMDAwIDUyNC4wNTBdL01hdHJpeFsxIDAgMCAxIC0zOTku MDAwIC01MTMuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0 YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVu Z3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjM5OS4wMDAgNTEz LjUwMCBtCjQyMy4wMDAgNTEzLjUwMCBsCjQyMy4wMDAgNTI0LjA1MCBsCjM5OS4wMDAgNTI0LjA1 MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago1NTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0hpZ2hsaWdodC9GIDQvUmVjdFszOTkuMDAwIDUxMy41MDAgNDIzLjAwMCA1MjQuMDUwXS9DWzEu MDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzM5OS4wMDAgNTI0LjA1MCA0MjMuMDAwIDUyNC4w NTAgMzk5LjAwMCA1MTMuNTAwIDQyMy4wMDAgNTEzLjUwMF0vQVA8PC9OIDU1MSAwIFIgPj4vVChU Q2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxMTYgMCBSPj4KZW5kb2JqCjU1 MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs0MDUuMDAwIDUxOS4w NTAgNDM1LjAwMCA1NDkuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9w dXAgMzUyIDAgUi9Db250ZW50cyhUaGUgUkZDIGVkaXRvciB1c2VzOlxuXG4JIi4uLmJsYWggYmxh aCwgZS5nLiwgYmxhaCBibGFoIlxuXG5hbmRcbgkiLi4uYmxhaCBibGFoLCBpLmUuLCBibGFoIGJs YWgiXG5cblJlY29tbWVuZCBtYWtpbmcgdGhlaXIgbGlmZSBlYXNpZXIgXChhbmQgcmVkdWNpbmcg dGhlaXIgcHJvY2Vzc2luZyB0aW1lXCkgYnkganVzdCBkb2luZyB0aGlzIGZyb20gdGhlIHN0YXJ0 IDtcKSkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxMTYgMCBSPj4K ZW5kb2JqCjM1MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzQ0 MC4wMDAgNDM3LjA1MCA2OTAuMDAwIDU0OS4wNTBdL1BhcmVudCA1NTMgMCBSL09wZW4gZmFsc2U+ PgplbmRvYmoKNTU0IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUg MS9CQm94Wzk5LjAwMCAyMDUuNTAwIDE0Ny4wMDAgMjE2LjA1MF0vTWF0cml4WzEgMCAwIDEgLTk5 LjAwMCAtMjA1LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdT dGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xl bmd0aCAxMDQ+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwo5OS4wMDAgMjA1 LjUwMCBtCjE0Ny4wMDAgMjA1LjUwMCBsCjE0Ny4wMDAgMjE2LjA1MCBsCjk5LjAwMCAyMTYuMDUw IGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjU1NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv SGlnaGxpZ2h0L0YgNC9SZWN0Wzk5LjAwMCAyMDUuNTAwIDE0Ny4wMDAgMjE2LjA1MF0vQ1sxLjAw MCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s5OS4wMDAgMjE2LjA1MCAxNDcuMDAwIDIxNi4wNTAg OTkuMDAwIDIwNS41MDAgMTQ3LjAwMCAyMDUuNTAwXS9BUDw8L04gNTU0IDAgUiA+Pi9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDExNiAwIFI+PgplbmRvYmoKNTU2IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzEwOC4wMDAgMjExLjA1MCAx MzguMDAwIDI0MS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA1 NTcgMCBSL0NvbnRlbnRzKEVuY29kZWQgaG93PykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYy OTM0KzAyJzAwJykvUCAxMTYgMCBSPj4KZW5kb2JqCjU1NyAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzE0My4wMDAgMTI5LjA1MCAzOTMuMDAwIDI0MS4wNTBdL1Bh cmVudCA1NTYgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNTU4IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9VbmRlcmxpbmUvRiA0L1JlY3RbOTkuMDAwIDE2MS41MDAgMTUzLjAwMCAxNzIuMDUw XS9DWzEuMDAwIDAuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzk5LjAwMCAxNzIuMDUwIDE1My4wMDAg MTcyLjA1MCA5OS4wMDAgMTYxLjUwMCAxNTMuMDAwIDE2MS41MDBdL1QoVENsYXVzZW4pL00oRDoy MDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTE2IDAgUj4+CmVuZG9iago1NTkgMCBvYmoKPDwvVHlw ZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbOTkuMDAwIDE2MS41MDAgMTUz LjAwMCAxNzIuMDUwXS9NYXRyaXhbMSAwIDAgMSAtOTkuMDAwIC0xNjEuNTAwXS9Hcm91cDw8L1Mv VHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0v TXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEKL1IwIGdz CjEuMDAwIDEuMDAwIDAuMDAwIHJnCjk5LjAwMCAxNjEuNTAwIG0KMTUzLjAwMCAxNjEuNTAwIGwK MTUzLjAwMCAxNzIuMDUwIGwKOTkuMDAwIDE3Mi4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoK NTYwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbOTkuMDAw IDE2MS41MDAgMTUzLjAwMCAxNzIuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRz Wzk5LjAwMCAxNzIuMDUwIDE1My4wMDAgMTcyLjA1MCA5OS4wMDAgMTYxLjUwMCAxNTMuMDAwIDE2 MS41MDBdL0FQPDwvTiA1NTkgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCsw MicwMCcpL1AgMTE2IDAgUj4+CmVuZG9iago1NjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L1RleHQvRiA0L1JlY3RbMTExLjAwMCAxNjcuMDUwIDE0MS4wMDAgMTk3LjA1MF0vTmFtZS9Db21t ZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDU2MiAwIFIvQ29udGVudHMoRW5jb2RlZCBo b3c/XG4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTE2IDAgUj4+ CmVuZG9iago1NjIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsx NDYuMDAwIDg1LjA1MCAzOTYuMDAwIDE5Ny4wNTBdL1BhcmVudCA1NjEgMCBSL09wZW4gZmFsc2U+ PgplbmRvYmoKMTE2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4 dEdTdGF0ZSAxMTkgMCBSCi9Gb250IDEyMCAwIFIKPj4KL0NvbnRlbnRzIDExNyAwIFIvQW5ub3Rz IDU0NyAwIFI+PgplbmRvYmoKNTQ3IDAgb2JqCls1NDkgMCBSIDU1MCAwIFIgMzQ4IDAgUiA1NTIg MCBSIDU1MyAwIFIgMzUyIDAgUiA1NTUgMCBSIDU1NiAwIFIgNTU3IDAgUiA1NTggMCBSIDU2MCAw IFIgNTYxIDAgUiA1NjIgMCBSXQplbmRvYmoKNTY0IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94Wzk5LjAwMCA0MDMuNTAwIDE0Ny4wMDAgNDE0LjA1MF0v TWF0cml4WzEgMCAwIDEgLTk5LjAwMCAtNDAzLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+ L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUv RXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDQ+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAw LjAwMCByZwo5OS4wMDAgNDAzLjUwMCBtCjE0Ny4wMDAgNDAzLjUwMCBsCjE0Ny4wMDAgNDE0LjA1 MCBsCjk5LjAwMCA0MTQuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjU2NSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0Wzk5LjAwMCA0MDMuNTAwIDE0Ny4w MDAgNDE0LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s5OS4wMDAgNDE0LjA1 MCAxNDcuMDAwIDQxNC4wNTAgOTkuMDAwIDQwMy41MDAgMTQ3LjAwMCA0MDMuNTAwXS9BUDw8L04g NTY0IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDEyMSAw IFI+PgplbmRvYmoKNTY2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0 WzEwOC4wMDAgNDA5LjA1MCAxMzguMDAwIDQzOS4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEu MDAwIDAuMDAwXS9Qb3B1cCA1NjcgMCBSL0NvbnRlbnRzKEVuY29kZWQgaG93PykvVChUQ2xhdXNl bikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxMjEgMCBSPj4KZW5kb2JqCjU2NyAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzE0My4wMDAgMzI3LjA1MCAz OTMuMDAwIDQzOS4wNTBdL1BhcmVudCA1NjYgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTIxIDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMjQgMCBS Ci9Gb250IDEyNSAwIFIKPj4KL0NvbnRlbnRzIDEyMiAwIFIvQW5ub3RzIDU2MyAwIFI+PgplbmRv YmoKNTYzIDAgb2JqCls1NjUgMCBSIDU2NiAwIFIgNTY3IDAgUl0KZW5kb2JqCjU2OSAwIG9iago8 PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsxMDUuMDAwIDI5My41 MDAgMTI5LjAwMCAzMDQuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMTA1LjAwMCAtMjkzLjUwMF0vR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZh bHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpx Ci9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoxMDUuMDAwIDI5My41MDAgbQoxMjkuMDAwIDI5 My41MDAgbAoxMjkuMDAwIDMwNC4wNTAgbAoxMDUuMDAwIDMwNC4wNTAgbApmClEKCmVuZHN0cmVh bQplbmRvYmoKNTcwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1Jl Y3RbMTA1LjAwMCAyOTMuNTAwIDEyOS4wMDAgMzA0LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0v UXVhZFBvaW50c1sxMDUuMDAwIDMwNC4wNTAgMTI5LjAwMCAzMDQuMDUwIDEwNS4wMDAgMjkzLjUw MCAxMjkuMDAwIDI5My41MDBdL0FQPDwvTiA1NjkgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEy MTAwMzE2MjkzNCswMicwMCcpL1AgMTI2IDAgUj4+CmVuZG9iago1NzEgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMTExLjAwMCAyOTkuMDUwIDE0MS4wMDAgMzI5LjA1 MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDM1NyAwIFIvQ29udGVu dHMoVGhlIFJGQyBlZGl0b3IgdXNlczpcblxuCSIuLi5ibGFoIGJsYWgsIGUuZy4sIGJsYWggYmxh aCJcblxuYW5kXG4JIi4uLmJsYWggYmxhaCwgaS5lLiwgYmxhaCBibGFoIlxuXG5SZWNvbW1lbmQg bWFraW5nIHRoZWlyIGxpZmUgZWFzaWVyIFwoYW5kIHJlZHVjaW5nIHRoZWlyIHByb2Nlc3Npbmcg dGltZVwpIGJ5IGp1c3QgZG9pbmcgdGhpcyBmcm9tIHRoZSBzdGFydCA7XCkpL1QoVENsYXVzZW4p L00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTI2IDAgUj4+CmVuZG9iagozNTcgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxNDYuMDAwIDIxNy4wNTAgMzk2 LjAwMCAzMjkuMDUwXS9QYXJlbnQgNTcxIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjU3MiAwIG9i ago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFszODcuMDAwIDU3 OS41MDAgNDIzLjAwMCA1OTAuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMzg3LjAwMCAtNTc5LjUwMF0v R3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlT IGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVh bQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwozODcuMDAwIDU3OS41MDAgbQo0MjMuMDAw IDU3OS41MDAgbAo0MjMuMDAwIDU5MC4wNTAgbAozODcuMDAwIDU5MC4wNTAgbApmClEKCmVuZHN0 cmVhbQplbmRvYmoKNTczIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0 L1JlY3RbMzg3LjAwMCA1NzkuNTAwIDQyMy4wMDAgNTkwLjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAw MF0vUXVhZFBvaW50c1szODcuMDAwIDU5MC4wNTAgNDIzLjAwMCA1OTAuMDUwIDM4Ny4wMDAgNTc5 LjUwMCA0MjMuMDAwIDU3OS41MDBdL0FQPDwvTiA1NzIgMCBSID4+L1QoVENsYXVzZW4pL00oRDoy MDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTI2IDAgUj4+CmVuZG9iago1NzQgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzkwLjAwMCA1ODUuMDUwIDQyMC4wMDAgNjE1 LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDU3NSAwIFIvQ29u dGVudHMoSW50ZWdlcikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAx MjYgMCBSPj4KZW5kb2JqCjU3NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAy OC9SZWN0WzQyNS4wMDAgNTAzLjA1MCA2NzUuMDAwIDYxNS4wNTBdL1BhcmVudCA1NzQgMCBSL09w ZW4gZmFsc2U+PgplbmRvYmoKNTc2IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0v Rm9ybVR5cGUgMS9CQm94WzM4Ny4wMDAgNTI0LjUwMCA0MjMuMDAwIDUzNS4wNTBdL01hdHJpeFsx IDAgMCAxIC0zODcuMDAwIC01MjQuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3Vy Y2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3Rh dGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJn CjM4Ny4wMDAgNTI0LjUwMCBtCjQyMy4wMDAgNTI0LjUwMCBsCjQyMy4wMDAgNTM1LjA1MCBsCjM4 Ny4wMDAgNTM1LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago1NzcgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszODcuMDAwIDUyNC41MDAgNDIzLjAwMCA1 MzUuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzM4Ny4wMDAgNTM1LjA1MCA0 MjMuMDAwIDUzNS4wNTAgMzg3LjAwMCA1MjQuNTAwIDQyMy4wMDAgNTI0LjUwMF0vQVA8PC9OIDU3 NiAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxMjYgMCBS Pj4KZW5kb2JqCjU3OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsz OTAuMDAwIDUzMC4wNTAgNDIwLjAwMCA1NjAuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAw MCAwLjAwMF0vUG9wdXAgNTc5IDAgUi9Db250ZW50cyhpbnRlZ2VyKS9UKFRDbGF1c2VuKS9NKEQ6 MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDEyNiAwIFI+PgplbmRvYmoKNTc5IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNDI1LjAwMCA0NDguMDUwIDY3NS4wMDAg NTYwLjA1MF0vUGFyZW50IDU3OCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxMjYgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEyOSAwIFIKL0ZvbnQg MTMwIDAgUgo+PgovQ29udGVudHMgMTI3IDAgUi9Bbm5vdHMgNTY4IDAgUj4+CmVuZG9iago1Njgg MCBvYmoKWzU3MCAwIFIgNTcxIDAgUiAzNTcgMCBSIDU3MyAwIFIgNTc0IDAgUiA1NzUgMCBSIDU3 NyAwIFIgNTc4IDAgUiA1NzkgMCBSXQplbmRvYmoKNTgxIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9T dWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzMyMS4wMDAgNTM1LjUwMCAzNTcuMDAwIDU0Ni4w NTBdL01hdHJpeFsxIDAgMCAxIC0zMjEuMDAwIC01MzUuNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJl bmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkv VHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEu MDAwIDAuMDAwIHJnCjMyMS4wMDAgNTM1LjUwMCBtCjM1Ny4wMDAgNTM1LjUwMCBsCjM1Ny4wMDAg NTQ2LjA1MCBsCjMyMS4wMDAgNTQ2LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago1ODIgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszMjEuMDAwIDUzNS41 MDAgMzU3LjAwMCA1NDYuMDUwXS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzMyMS4w MDAgNTQ2LjA1MCAzNTcuMDAwIDU0Ni4wNTAgMzIxLjAwMCA1MzUuNTAwIDM1Ny4wMDAgNTM1LjUw MF0vQVA8PC9OIDU4MSAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAw JykvUCAxMzEgMCBSPj4KZW5kb2JqCjU4MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4 dC9GIDQvUmVjdFszMjQuMDAwIDU0MS4wNTAgMzU0LjAwMCA1NzEuMDUwXS9OYW1lL0NvbW1lbnQv Q1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgNTg0IDAgUi9Db250ZW50cyhpbnRlZ2VyKS9UKFRD bGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDEzMSAwIFI+PgplbmRvYmoKNTg0 IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzU5LjAwMCA0NTku MDUwIDYwOS4wMDAgNTcxLjA1MF0vUGFyZW50IDU4MyAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago1 ODUgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbOTku MDAwIDEzOS41MDAgMTQ3LjAwMCAxNTAuMDUwXS9NYXRyaXhbMSAwIDAgMSAtOTkuMDAwIC0xMzku NTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8 PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+ c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjk5LjAwMCAxMzkuNTAwIG0KMTQ3 LjAwMCAxMzkuNTAwIGwKMTQ3LjAwMCAxNTAuMDUwIGwKOTkuMDAwIDE1MC4wNTAgbApmClEKCmVu ZHN0cmVhbQplbmRvYmoKNTg2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQv RiA0L1JlY3RbOTkuMDAwIDEzOS41MDAgMTQ3LjAwMCAxNTAuMDUwXS9DWzEuMDAwIDEuMDAwIDAu MDAwXS9RdWFkUG9pbnRzWzk5LjAwMCAxNTAuMDUwIDE0Ny4wMDAgMTUwLjA1MCA5OS4wMDAgMTM5 LjUwMCAxNDcuMDAwIDEzOS41MDBdL0FQPDwvTiA1ODUgMCBSID4+L1QoVENsYXVzZW4pL00oRDoy MDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTMxIDAgUj4+CmVuZG9iago1ODcgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMTA4LjAwMCAxNDUuMDUwIDEzOC4wMDAgMTc1 LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDU4OCAwIFIvQ29u dGVudHMoVGhpcyBmaWVsZCBpcyByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gRm9yIGNvbXBsaWFu Y2Ugd2l0aCB0aGlzIHZlcnNpb24gb2YgdGhlIHNwZWNpZmljYXRpb24sIGl0IE1VU1QgYmUgIHNl dCB0byAwIG9uIHRyYW5zbWlzc2lvbiwgYW5kIFNIT1VMRCBiZSBpZ25vcmVkIG9uIHJlY2VpcHQu KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDEzMSAwIFI+PgplbmRv YmoKNTg4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTQzLjAw MCA2My4wNTAgMzkzLjAwMCAxNzUuMDUwXS9QYXJlbnQgNTg3IDAgUi9PcGVuIGZhbHNlPj4KZW5k b2JqCjEzMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgMTM0IDAgUgovRm9udCAxMzUgMCBSCj4+Ci9Db250ZW50cyAxMzIgMCBSL0Fubm90cyA1ODAg MCBSPj4KZW5kb2JqCjU4MCAwIG9iagpbNTgyIDAgUiA1ODMgMCBSIDU4NCAwIFIgNTg2IDAgUiA1 ODcgMCBSIDU4OCAwIFJdCmVuZG9iago1OTAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv Rm9ybS9Gb3JtVHlwZSAxL0JCb3hbMTA1LjAwMCA2NTYuNTAwIDE4My4wMDAgNjY3LjA1MF0vTWF0 cml4WzEgMCAwIDEgLTEwNS4wMDAgLTY1Ni41MDBdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9S ZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4 dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4w MDAgcmcKMTA1LjAwMCA2NTYuNTAwIG0KMTgzLjAwMCA2NTYuNTAwIGwKMTgzLjAwMCA2NjcuMDUw IGwKMTA1LjAwMCA2NjcuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjU5MSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzEwNS4wMDAgNjU2LjUwMCAxODMu MDAwIDY2Ny4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMTA1LjAwMCA2Njcu MDUwIDE4My4wMDAgNjY3LjA1MCAxMDUuMDAwIDY1Ni41MDAgMTgzLjAwMCA2NTYuNTAwXS9BUDw8 L04gNTkwIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDEz NiAwIFI+PgplbmRvYmoKNTkyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9S ZWN0WzEyOS4wMDAgNjYyLjA1MCAxNTkuMDAwIDY5Mi4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAw IDEuMDAwIDAuMDAwXS9Qb3B1cCAzMDYgMCBSL0NvbnRlbnRzKEFzIERMRVAgaXMgIkRhdGEgTGlu ayBFeGNoYW5nZSBQcm90b2NvbCIsIHNheWluZyAiRExFUCBQcm90b2NvbCIgaXMgcmVkdW5kYW50 OiBleHBhbmRlZCBpdCBiZWNvbWVzICJEYXRhIExpbmsgRXhjaGFuZ2UgUHJvdG9jb2wgUHJvdG9j b2wiLlxuXG5TdWdnZXN0IHNheWluZyAiRExFUCBpcyBhIC4uLi4iIGluc3RlYWQgb2YgInRoZSBE TEVQIHByb3RvY29sIGlzIGEgLi4uLiIpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCsw MicwMCcpL1AgMTM2IDAgUj4+CmVuZG9iagozMDYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L1BvcHVwL0YgMjgvUmVjdFsxNjQuMDAwIDU4MC4wNTAgNDE0LjAwMCA2OTIuMDUwXS9QYXJlbnQg NTkyIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjU5MyAwIG9iago8PC9UeXBlL1hPYmplY3QvU3Vi dHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsyODUuMDAwIDYzNC41MDAgMzIxLjAwMCA2NDUuMDUw XS9NYXRyaXhbMSAwIDAgMSAtMjg1LjAwMCAtNjM0LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5j eT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5 cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAw MCAwLjAwMCByZwoyODUuMDAwIDYzNC41MDAgbQozMjEuMDAwIDYzNC41MDAgbAozMjEuMDAwIDY0 NS4wNTAgbAoyODUuMDAwIDY0NS4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKNTk0IDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMjg1LjAwMCA2MzQuNTAw IDMyMS4wMDAgNjQ1LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1syODUuMDAw IDY0NS4wNTAgMzIxLjAwMCA2NDUuMDUwIDI4NS4wMDAgNjM0LjUwMCAzMjEuMDAwIDYzNC41MDBd L0FQPDwvTiA1OTMgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcp L1AgMTM2IDAgUj4+CmVuZG9iago1OTUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQv RiA0L1JlY3RbMjg4LjAwMCA2NDAuMDUwIDMxOC4wMDAgNjcwLjA1MF0vTmFtZS9Db21tZW50L0Nb MS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDU5NiAwIFIvQ29udGVudHMoVGVjaG5pY2FsbHksIEkg d291bGQgbm90IHNheSAic3RyaW5nIiBcKHRoYXQgaGFzIGEgY29tbW9uIGludGVycHJldGF0aW9u IGFzIGEgU3RyaW5nIGRhdGF0eXBlXCksIGJ1dCByYXRoZXIgYSAic2VxdWVuY2UiIG9yIGJldHRl ciBhICJzZXQiIG9mIFRMVnMpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcp L1AgMTM2IDAgUj4+CmVuZG9iago1OTYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVw L0YgMjgvUmVjdFszMjMuMDAwIDU1OC4wNTAgNTczLjAwMCA2NzAuMDUwXS9QYXJlbnQgNTk1IDAg Ui9PcGVuIGZhbHNlPj4KZW5kb2JqCjU5NyAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9G b3JtL0Zvcm1UeXBlIDEvQkJveFsxNTMuMDAwIDM4MS41MDAgMjYxLjAwMCAzOTIuMDUwXS9NYXRy aXhbMSAwIDAgMSAtMTUzLjAwMCAtMzgxLjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jl c291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0 R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAw MCByZwoxNTMuMDAwIDM4MS41MDAgbQoyNjEuMDAwIDM4MS41MDAgbAoyNjEuMDAwIDM5Mi4wNTAg bAoxNTMuMDAwIDM5Mi4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKNTk4IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMTUzLjAwMCAzODEuNTAwIDI2MS4w MDAgMzkyLjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxNTMuMDAwIDM5Mi4w NTAgMjYxLjAwMCAzOTIuMDUwIDE1My4wMDAgMzgxLjUwMCAyNjEuMDAwIDM4MS41MDBdL0FQPDwv TiA1OTcgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTM2 IDAgUj4+CmVuZG9iago1OTkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1Jl Y3RbMTkyLjAwMCAzODcuMDUwIDIyMi4wMDAgNDE3LjA1MF0vTmFtZS9Db21tZW50L0NbMS4wMDAg MS4wMDAgMC4wMDBdL1BvcHVwIDYwMCAwIFIvQ29udGVudHMoU2VlIHByZXZpb3VzIGNvbW1lbnQg cmUuIG1lc3NhZ2UtdnMtc2lnbmFsKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDIn MDAnKS9QIDEzNiAwIFI+PgplbmRvYmoKNjAwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Q b3B1cC9GIDI4L1JlY3RbMjI3LjAwMCAzMDUuMDUwIDQ3Ny4wMDAgNDE3LjA1MF0vUGFyZW50IDU5 OSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxMzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEzOSAwIFIKL0ZvbnQgMTQwIDAgUgo+PgovQ29udGVu dHMgMTM3IDAgUi9Bbm5vdHMgNTg5IDAgUj4+CmVuZG9iago1ODkgMCBvYmoKWzU5MSAwIFIgNTky IDAgUiAzMDYgMCBSIDU5NCAwIFIgNTk1IDAgUiA1OTYgMCBSIDU5OCAwIFIgNTk5IDAgUiA2MDAg MCBSXQplbmRvYmoKNjAyIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5 cGUgMS9CQm94WzQyOS4wMDAgNTY4LjUwMCA0OTUuMDAwIDU3OS4wNTBdL01hdHJpeFsxIDAgMCAx IC00MjkuMDAwIC01NjguNTAwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwv RXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+ Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjQyOS4w MDAgNTY4LjUwMCBtCjQ5NS4wMDAgNTY4LjUwMCBsCjQ5NS4wMDAgNTc5LjA1MCBsCjQyOS4wMDAg NTc5LjA1MCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iago2MDMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs0MjkuMDAwIDU2OC41MDAgNDk1LjAwMCA1NzkuMDUw XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzQyOS4wMDAgNTc5LjA1MCA0OTUuMDAw IDU3OS4wNTAgNDI5LjAwMCA1NjguNTAwIDQ5NS4wMDAgNTY4LjUwMF0vQVA8PC9OIDYwMiAwIFIg Pj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxNDEgMCBSPj4KZW5k b2JqCjYwNCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs0NDcuMDAw IDU3NC4wNTAgNDc3LjAwMCA2MDQuMDUwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAw MF0vUG9wdXAgNjA1IDAgUi9Db250ZW50cyhUaGlzIGlzICB0aGUgZmlyc3QgdXNlIG9mICJBc3Nv Y2lhdGlvbiIgLSBpcyB0aGF0IHRoZSBzYW1lIGFzICJzZXNzaW9uIj8pL1QoVENsYXVzZW4pL00o RDoyMDEyMTAwMzE2MjkzNCswMicwMCcpL1AgMTQxIDAgUj4+CmVuZG9iago2MDUgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0ODIuMDAwIDQ5Mi4wNTAgNzMyLjAw MCA2MDQuMDUwXS9QYXJlbnQgNjA0IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjE0MSAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQ0IDAgUgovRm9u dCAxNDUgMCBSCj4+Ci9Db250ZW50cyAxNDIgMCBSL0Fubm90cyA2MDEgMCBSPj4KZW5kb2JqCjYw MSAwIG9iagpbNjAzIDAgUiA2MDQgMCBSIDYwNSAwIFJdCmVuZG9iago2MDcgMCBvYmoKPDwvVHlw ZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbNDIzLjAwMCAyOTMuNTAwIDQ0 Ny4wMDAgMzA0LjA1MF0vTWF0cml4WzEgMCAwIDEgLTQyMy4wMDAgLTI5My41MDBdL0dyb3VwPDwv Uy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9C TS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAg Z3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKNDIzLjAwMCAyOTMuNTAwIG0KNDQ3LjAwMCAyOTMuNTAw IGwKNDQ3LjAwMCAzMDQuMDUwIGwKNDIzLjAwMCAzMDQuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5k b2JqCjYwOCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzQy My4wMDAgMjkzLjUwMCA0NDcuMDAwIDMwNC4wNTBdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQ b2ludHNbNDIzLjAwMCAzMDQuMDUwIDQ0Ny4wMDAgMzA0LjA1MCA0MjMuMDAwIDI5My41MDAgNDQ3 LjAwMCAyOTMuNTAwXS9BUDw8L04gNjA3IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMx NjI5MzQrMDInMDAnKS9QIDE1MSAwIFI+PgplbmRvYmoKNjA5IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9UZXh0L0YgNC9SZWN0WzQyMy4wMDAgMjk5LjA1MCA0NTMuMDAwIDMyOS4wNTBdL05h bWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzNjYgMCBSL0NvbnRlbnRzKFRo ZSBSRkMgZWRpdG9yIHVzZXM6XG5cbgkiLi4uYmxhaCBibGFoLCBlLmcuLCBibGFoIGJsYWgiXG5c bmFuZFxuCSIuLi5ibGFoIGJsYWgsIGkuZS4sIGJsYWggYmxhaCJcblxuUmVjb21tZW5kIG1ha2lu ZyB0aGVpciBsaWZlIGVhc2llciBcKGFuZCByZWR1Y2luZyB0aGVpciBwcm9jZXNzaW5nIHRpbWVc KSBieSBqdXN0IGRvaW5nIHRoaXMgZnJvbSB0aGUgc3RhcnQgO1wpKS9UKFRDbGF1c2VuKS9NKEQ6 MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDE1MSAwIFI+PgplbmRvYmoKMzY2IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNDU4LjAwMCAyMTcuMDUwIDcwOC4wMDAg MzI5LjA1MF0vUGFyZW50IDYwOSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxNTEgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE1NCAwIFIKL0ZvbnQg MTU1IDAgUgo+PgovQ29udGVudHMgMTUyIDAgUi9Bbm5vdHMgNjA2IDAgUj4+CmVuZG9iago2MDYg MCBvYmoKWzYwOCAwIFIgNjA5IDAgUiAzNjYgMCBSXQplbmRvYmoKNjExIDAgb2JqCjw8L1R5cGUv WE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzgxLjAwMCA0NDcuNTAwIDUwNy4w MDAgNDY5LjA1MF0vTWF0cml4WzEgMCAwIDEgLTgxLjAwMCAtNDQ3LjUwMF0vR3JvdXA8PC9TL1Ry YW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011 bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxNzg+PnN0cmVhbQpxCi9SMCBncwox LjAwMCAxLjAwMCAwLjAwMCByZwoyMTMuMDAwIDQ1OC41MDAgbQo1MDcuMDAwIDQ1OC41MDAgbAo1 MDcuMDAwIDQ2OS4wNTAgbAoyMTMuMDAwIDQ2OS4wNTAgbApmCjgxLjAwMCA0NDcuNTAwIG0KMTc3 LjAwMCA0NDcuNTAwIGwKMTc3LjAwMCA0NTguMDUwIGwKODEuMDAwIDQ1OC4wNTAgbApmClEKCmVu ZHN0cmVhbQplbmRvYmoKNjEyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQv RiA0L1JlY3RbODEuMDAwIDQ0Ny41MDAgNTA3LjAwMCA0NjkuMDUwXS9DWzEuMDAwIDEuMDAwIDAu MDAwXS9RdWFkUG9pbnRzWzIxMy4wMDAgNDY5LjA1MCA1MDcuMDAwIDQ2OS4wNTAgMjEzLjAwMCA0 NTguNTAwIDUwNy4wMDAgNDU4LjUwMCA4MS4wMDAgNDU4LjA1MCAxNzcuMDAwIDQ1OC4wNTAgODEu MDAwIDQ0Ny41MDAgMTc3LjAwMCA0NDcuNTAwXS9BUDw8L04gNjExIDAgUiA+Pi9UKFRDbGF1c2Vu KS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDE2NiAwIFI+PgplbmRvYmoKNjEzIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzIyMi4wMDAgNDY0LjA1MCAyNTIu MDAwIDQ5NC4wNTBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA2MTQg MCBSL0NvbnRlbnRzKEkga25vdyBJIGFtIGEgbml0LXBpY2tlciwgYnV0IGRvZXNuJ3QgT1BUSU9O QUwgZXhhY3RseSBtZWFuIHRoYXQgaXQgIk1BWSBiZSBwcmVzZW50IGlmIGFuIGltcGxlbWVudGF0 aW9uIHN1cHBvcnRzLi4uIj9cblxuSXQgc3RyaWtlcyBtZSBhcyBqdXN0IHJlZHVuZGFudCBcKHRo aXMgaXMgbm90IHRoZSBvbmx5IHBsYWNlIHdoZXJlIEkgc2VlIHRoaXMsIGJ0dy4sIGp1c3QgdGhl IG9uZSB3aGVyZSBJIGNob3NlIHRvIHBvaW50IGl0IG91dC5cKSkvVChUQ2xhdXNlbikvTShEOjIw MTIxMDAzMTYyOTM0KzAyJzAwJykvUCAxNjYgMCBSPj4KZW5kb2JqCjYxNCAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzI1Ny4wMDAgMzgyLjA1MCA1MDcuMDAwIDQ5 NC4wNTBdL1BhcmVudCA2MTMgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTY2IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNjkgMCBSCi9Gb250IDE3 MCAwIFIKPj4KL0NvbnRlbnRzIDE2NyAwIFIvQW5ub3RzIDYxMCAwIFI+PgplbmRvYmoKNjEwIDAg b2JqCls2MTIgMCBSIDYxMyAwIFIgNjE0IDAgUl0KZW5kb2JqCjYxNiAwIG9iago8PC9UeXBlL1hP YmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs0NTMuMDAwIDI3MS41MDAgNDc3LjAw MCAyODIuMDUwXS9NYXRyaXhbMSAwIDAgMSAtNDUzLjAwMCAtMjcxLjUwMF0vR3JvdXA8PC9TL1Ry YW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011 bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwox LjAwMCAxLjAwMCAwLjAwMCByZwo0NTMuMDAwIDI3MS41MDAgbQo0NzcuMDAwIDI3MS41MDAgbAo0 NzcuMDAwIDI4Mi4wNTAgbAo0NTMuMDAwIDI4Mi4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRvYmoK NjE3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbNDUzLjAw MCAyNzEuNTAwIDQ3Ny4wMDAgMjgyLjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50 c1s0NTMuMDAwIDI4Mi4wNTAgNDc3LjAwMCAyODIuMDUwIDQ1My4wMDAgMjcxLjUwMCA0NzcuMDAw IDI3MS41MDBdL0FQPDwvTiA2MTYgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2Mjkz NCswMicwMCcpL1AgMTgxIDAgUj4+CmVuZG9iago2MTggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL1RleHQvRiA0L1JlY3RbNDQ3LjAwMCAyNzcuMDUwIDQ3Ny4wMDAgMzA3LjA1MF0vTmFtZS9D b21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDM3MSAwIFIvQ29udGVudHMoVGhlIFJG QyBlZGl0b3IgdXNlczpcblxuCSIuLi5ibGFoIGJsYWgsIGUuZy4sIGJsYWggYmxhaCJcblxuYW5k XG4JIi4uLmJsYWggYmxhaCwgaS5lLiwgYmxhaCBibGFoIlxuXG5SZWNvbW1lbmQgbWFraW5nIHRo ZWlyIGxpZmUgZWFzaWVyIFwoYW5kIHJlZHVjaW5nIHRoZWlyIHByb2Nlc3NpbmcgdGltZVwpIGJ5 IGp1c3QgZG9pbmcgdGhpcyBmcm9tIHRoZSBzdGFydCA7XCkpL1QoVENsYXVzZW4pL00oRDoyMDEy MTAwMzE2MjkzNCswMicwMCcpL1AgMTgxIDAgUj4+CmVuZG9iagozNzEgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0ODIuMDAwIDE5NS4wNTAgNzMyLjAwMCAzMDcu MDUwXS9QYXJlbnQgNjE4IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjYxOSAwIG9iago8PC9UeXBl L1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsxMTEuMDAwIDIwNS41MDAgMjI1 LjAwMCAyMTYuMDUwXS9NYXRyaXhbMSAwIDAgMSAtMTExLjAwMCAtMjA1LjUwMF0vR3JvdXA8PC9T L1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JN L011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBn cwoxLjAwMCAxLjAwMCAwLjAwMCByZwoxMTEuMDAwIDIwNS41MDAgbQoyMjUuMDAwIDIwNS41MDAg bAoyMjUuMDAwIDIxNi4wNTAgbAoxMTEuMDAwIDIxNi4wNTAgbApmClEKCmVuZHN0cmVhbQplbmRv YmoKNjIwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMTEx LjAwMCAyMDUuNTAwIDIyNS4wMDAgMjE2LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBv aW50c1sxMTEuMDAwIDIxNi4wNTAgMjI1LjAwMCAyMTYuMDUwIDExMS4wMDAgMjA1LjUwMCAyMjUu MDAwIDIwNS41MDBdL0FQPDwvTiA2MTkgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2 MjkzNCswMicwMCcpL1AgMTgxIDAgUj4+CmVuZG9iago2MjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL1RleHQvRiA0L1JlY3RbMTY4LjAwMCAyMTEuMDUwIDE5OC4wMDAgMjQxLjA1MF0vTmFt ZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDQ3NCAwIFIvQ29udGVudHMoRmly c3QsIGxldCBtZSBwb2ludCB0byBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjI2XG5c blNlY29uZCwgZm9yIHRoZSByZWdpc3RyaWVzIHNldCB1cCwgdGhlcmUgbmVlZHMgdG8gYmUgc3Bl Y2lmaWNhdGlvbnMgb2Ygd2hhdCB0aGUgcmFuZ2VzIGFyZSBcKGhvdyBiaWcgYXJlIHRoZSByZWdp c3RyaWVzXCksIHdoYXQgZGVmYXVsdCBhbGxvY2F0aW9ucyBhcmUgbWFkZSwgYW5kIHdoYXQgdGhl IGFsbG9jYXRpb24gcG9saWNpZXMgXChzZWUgUkZDNTIyNlwpIGFyZSBmb3IgdGhlc2UgcmVnaXN0 cmllcywgYW5kIGZvciBzcGVjaWZpYyBpbnRlcnZhbHMvcGFydHMgb2YgdGhlc2UgcmVnaXN0cmll cy5cblxuWW91IG1lbnRpb24gZWFybGllciB0aGF0IHRoZXJlIGFyZSBzb21lIGV4cGVyaW1lbnRh bCByYW5nZXMsIGFuZCB0aGF0IGlzIGdvb2QuIFdoYXQgYXJlIHRoZXk/IEFyZSB0aGVyZSByYW5n ZXMgcmVxdWlyaW5nIHN0YW5kYXJkcyBhY3Rpb24/IEV4cGVydCByZXZpZXc/IFdoYXQgYXJlIHRo ZSBjb25zaWRlcmF0aW9ucyB0aGF0IHRoZSBleHBlcnRzIG11c3QgYmUgYXdhcmUgb2Y/IE9yLCBp cyBpdCB0aGF0IHRoZSByZWdpc3RyaWVzIGFyZSBpbmZpbml0ZWx5IGJpZywgYW5kIElBTkEgc2hv dWxkIGp1c3QgcmVnaXN0ZXIgd2hhdGV2ZXIgdGhleSBhcmUgYXNrZWQgdG8gcmVnaXN0ZXI/KS9U KFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMxNjI5MzQrMDInMDAnKS9QIDE4MSAwIFI+PgplbmRvYmoK NDc0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjAzLjAwMCAx MjkuMDUwIDQ1My4wMDAgMjQxLjA1MF0vUGFyZW50IDYyMSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9i agoxODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDE4NCAwIFIKL0ZvbnQgMTg1IDAgUgo+PgovQ29udGVudHMgMTgyIDAgUi9Bbm5vdHMgNjE1IDAg Uj4+CmVuZG9iago2MTUgMCBvYmoKWzYxNyAwIFIgNjE4IDAgUiAzNzEgMCBSIDYyMCAwIFIgNjIx IDAgUiA0NzQgMCBSXQplbmRvYmoKNjIzIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zv cm0vRm9ybVR5cGUgMS9CQm94WzgxLjAwMCA0MzYuNTAwIDQ1My4wMDAgNDY5LjA1MF0vTWF0cml4 WzEgMCAwIDEgLTgxLjAwMCAtNDM2LjUwMF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291 cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0 YXRlPj4+Pj4+L0xlbmd0aCAxNzY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCBy Zwo4MS4wMDAgNDU4LjUwMCBtCjMzMy4wMDAgNDU4LjUwMCBsCjMzMy4wMDAgNDY5LjA1MCBsCjgx LjAwMCA0NjkuMDUwIGwKZgo4MS4wMDAgNDM2LjUwMCBtCjQ1My4wMDAgNDM2LjUwMCBsCjQ1My4w MDAgNDQ3LjA1MCBsCjgxLjAwMCA0NDcuMDUwIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjYyNCAw IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzgxLjAwMCA0MzYu NTAwIDQ1My4wMDAgNDY5LjA1MF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s4MS4w MDAgNDY5LjA1MCAzMzMuMDAwIDQ2OS4wNTAgODEuMDAwIDQ1OC41MDAgMzMzLjAwMCA0NTguNTAw IDgxLjAwMCA0NDcuMDUwIDQ1My4wMDAgNDQ3LjA1MCA4MS4wMDAgNDM2LjUwMCA0NTMuMDAwIDQz Ni41MDBdL0FQPDwvTiA2MjMgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAwMzE2MjkzNCsw MicwMCcpL1AgMTg2IDAgUj4+CmVuZG9iago2MjUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L1RleHQvRiA0L1JlY3RbMjUyLjAwMCA0NDIuMDUwIDI4Mi4wMDAgNDcyLjA1MF0vTmFtZS9Db21t ZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDQ3NSAwIFIvQ29udGVudHMoSSBkbyBub3Qg dW5kZXJzdGFuZCB0aGlzLlxuXG5BZGRpdGlvbmFsIGd1aWRlbGluZXMgLS0gYWRkaXRpb25hbCB0 byB3aGF0PyBJSVJDLCB0aGVyZSBhcmUgbm8gImRlZmF1bHQgZXhwZXJ0IHJldmlldyBndWlkZWxp bmVzIiBhbnl3aGVyZSBpbiB0aGUgSUVURikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDAzMTYyOTM0 KzAyJzAwJykvUCAxODYgMCBSPj4KZW5kb2JqCjQ3NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvUG9wdXAvRiAyOC9SZWN0WzI4Ny4wMDAgMzYwLjA1MCA1MzcuMDAwIDQ3Mi4wNTBdL1BhcmVu dCA2MjUgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNjI2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9UZXh0L0YgNC9SZWN0WzI1Mi4wMDAgNDQyLjA1MCAyODIuMDAwIDQ3Mi4wNTBdL05hbWUv Q29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA0NzcgMCBSL0NvbnRlbnRzKEkgZG8g bm90IHVuZGVyc3RhbmQgdGhpcy5cblxuQWRkaXRpb25hbCBndWlkZWxpbmVzIC0tIGFkZGl0aW9u YWwgdG8gd2hhdD8gSUlSQywgdGhlcmUgYXJlIG5vICJkZWZhdWx0IGV4cGVydCByZXZpZXcgZ3Vp ZGVsaW5lcyIgYW55d2hlcmUgaW4gdGhlIElFVEYuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMDMx NjI5MzQrMDInMDAnKS9QIDE4NiAwIFI+PgplbmRvYmoKNDc3IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjg3LjAwMCAzNjAuMDUwIDUzNy4wMDAgNDcyLjA1MF0v UGFyZW50IDYyNiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxODYgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE4OSAwIFIKL0ZvbnQgMTkwIDAgUgo+ PgovQ29udGVudHMgMTg3IDAgUi9Bbm5vdHMgNjIyIDAgUj4+CmVuZG9iago2MjIgMCBvYmoKWzYy NCAwIFIgNjI1IDAgUiA0NzUgMCBSIDYyNiAwIFIgNDc3IDAgUl0KZW5kb2JqCnhyZWYKMCAxCjAw MDAwMDAwMDAgNjU1MzUgZiAKMiAxCjAwMDAwNjYxMjUgMDAwMDAgbiAKMjEgMQowMDAwMDc0MjY1 IDAwMDAwIG4gCjI2IDEKMDAwMDA3OTg5OCAwMDAwMCBuIAozMSAxCjAwMDAwODM4NTAgMDAwMDAg biAKMzYgMQowMDAwMDkyMzcyIDAwMDAwIG4gCjQxIDEKMDAwMDEwNjM1MyAwMDAwMCBuIAo0NiAx CjAwMDAxMTQzMzcgMDAwMDAgbiAKNTEgMQowMDAwMTIxOTM2IDAwMDAwIG4gCjU2IDEKMDAwMDEy NDM5MiAwMDAwMCBuIAo2NiAxCjAwMDAxMzI5NjcgMDAwMDAgbiAKNzEgMQowMDAwMTM5MzE3IDAw MDAwIG4gCjc2IDEKMDAwMDE0MDY1NSAwMDAwMCBuIAo4MSAxCjAwMDAxNDY1MDIgMDAwMDAgbiAK ODYgMQowMDAwMTQ3MTU2IDAwMDAwIG4gCjkxIDEKMDAwMDE0NzY5MCAwMDAwMCBuIAo5NiAxCjAw MDAxNTA5NDAgMDAwMDAgbiAKMTAxIDEKMDAwMDE1MjE0NiAwMDAwMCBuIAoxMDYgMQowMDAwMTU0 Nzg1IDAwMDAwIG4gCjExMSAxCjAwMDAxNTcwMTkgMDAwMDAgbiAKMTE2IDEKMDAwMDE2MTY2MSAw MDAwMCBuIAoxMjEgMQowMDAwMTYyOTAwIDAwMDAwIG4gCjEyNiAxCjAwMDAxNjYxNDIgMDAwMDAg biAKMTMxIDEKMDAwMDE2ODQzOSAwMDAwMCBuIAoxMzYgMQowMDAwMTcxODgxIDAwMDAwIG4gCjE0 MSAxCjAwMDAxNzMxNTUgMDAwMDAgbiAKMTUxIDEKMDAwMDE3NDUyMSAwMDAwMCBuIAoxNjYgMQow MDAwMTc2MDU4IDAwMDAwIG4gCjE4MSAxCjAwMDAxNzkwMzkgMDAwMDAgbiAKMTg2IDEKMDAwMDE4 MDk1MyAwMDAwMCBuIAoyMzggMQowMDAwMDY2MzAyIDAwMDAwIG4gCjI0MCAxCjAwMDAwNjc4ODIg MDAwMDAgbiAKMjQ1IDM4MgowMDAwMDY2NDI3IDAwMDAwIG4gCjAwMDAwNjY2NjQgMDAwMDAgbiAK MDAwMDA2NjkwMSAwMDAwMCBuIAowMDAwMDY3MjU5IDAwMDAwIG4gCjAwMDAwNjc1MTEgMDAwMDAg biAKMDAwMDA2Nzc2NiAwMDAwMCBuIAowMDAwMDc0NDQxIDAwMDAwIG4gCjAwMDAwNjc5NjUgMDAw MDAgbiAKMDAwMDA2ODMyMyAwMDAwMCBuIAowMDAwMDY4NTc2IDAwMDAwIG4gCjAwMDAwNjg4OTQg MDAwMDAgbiAKMDAwMDA2OTAxMCAwMDAwMCBuIAowMDAwMDY5MzcyIDAwMDAwIG4gCjAwMDAwNjk2 MjggMDAwMDAgbiAKMDAwMDA2OTk0NiAwMDAwMCBuIAowMDAwMDcwMDYyIDAwMDAwIG4gCjAwMDAw NzA0MjQgMDAwMDAgbiAKMDAwMDA3MDY4MCAwMDAwMCBuIAowMDAwMDcxMDk5IDAwMDAwIG4gCjAw MDAwNzEyMTUgMDAwMDAgbiAKMDAwMDA3MTU3NyAwMDAwMCBuIAowMDAwMDcxODMzIDAwMDAwIG4g CjAwMDAwNzIyNDAgMDAwMDAgbiAKMDAwMDA3MjM1NiAwMDAwMCBuIAowMDAwMDcyNzE4IDAwMDAw IG4gCjAwMDAwNzI5NzQgMDAwMDAgbiAKMDAwMDA3MzIxNSAwMDAwMCBuIAowMDAwMDczMzMxIDAw MDAwIG4gCjAwMDAwNzM2OTMgMDAwMDAgbiAKMDAwMDA3Mzk0OSAwMDAwMCBuIAowMDAwMDc0MTQ5 IDAwMDAwIG4gCjAwMDAwODAwNzQgMDAwMDAgbiAKMDAwMDA3NDYwNCAwMDAwMCBuIAowMDAwMDc0 ODQ3IDAwMDAwIG4gCjAwMDAwNzQ5NjMgMDAwMDAgbiAKMDAwMDA3NTMyNSAwMDAwMCBuIAowMDAw MDc1NTgxIDAwMDAwIG4gCjAwMDAwNzU5OTAgMDAwMDAgbiAKMDAwMDA3NjEwNiAwMDAwMCBuIAow MDAwMDc2NDY4IDAwMDAwIG4gCjAwMDAwNzY3MjQgMDAwMDAgbiAKMDAwMDA3NzEzMyAwMDAwMCBu IAowMDAwMDc3MjQ5IDAwMDAwIG4gCjAwMDAwNzc2MTEgMDAwMDAgbiAKMDAwMDA3Nzg2NyAwMDAw MCBuIAowMDAwMDc4Mjc0IDAwMDAwIG4gCjAwMDAxMTU3MDQgMDAwMDAgbiAKMDAwMDA3ODM5MCAw MDAwMCBuIAowMDAwMDc4NzcyIDAwMDAwIG4gCjAwMDAwNzg4ODcgMDAwMDAgbiAKMDAwMDA3OTI0 OSAwMDAwMCBuIAowMDAwMTI1NjYyIDAwMDAwIG4gCjAwMDAwOTM3NTIgMDAwMDAgbiAKMDAwMDA3 OTUwNSAwMDAwMCBuIAowMDAwMDc5NzgyIDAwMDAwIG4gCjAwMDAwODQwMjYgMDAwMDAgbiAKMDAw MDEzNDMxNyAwMDAwMCBuIAowMDAwMDgwMjIxIDAwMDAwIG4gCjAwMDAwODA1NzkgMDAwMDAgbiAK MDAwMDA4MDgzMiAwMDAwMCBuIAowMDAwMTA4NDIzIDAwMDAwIG4gCjAwMDAxNjk3MTUgMDAwMDAg biAKMDAwMDA4MTE0NCAwMDAwMCBuIAowMDAwMDgxMjYwIDAwMDAwIG4gCjAwMDAwODE2MjIgMDAw MDAgbiAKMDAwMDA4MTg3OCAwMDAwMCBuIAowMDAwMDgyNDM5IDAwMDAwIG4gCjAwMDAwODI1NTUg MDAwMDAgbiAKMDAwMDA4MjkxNyAwMDAwMCBuIAowMDAwMDgzMTczIDAwMDAwIG4gCjAwMDAxMjMy NjggMDAwMDAgbiAKMDAwMDA4MzczNCAwMDAwMCBuIAowMDAwMDkyNTQ4IDAwMDAwIG4gCjAwMDAw ODQxMTcgMDAwMDAgbiAKMDAwMDA4NDQ3NCAwMDAwMCBuIAowMDAwMDg0NTkwIDAwMDAwIG4gCjAw MDAwODQ5NTIgMDAwMDAgbiAKMDAwMDA4NTIwOCAwMDAwMCBuIAowMDAwMDg1NzY5IDAwMDAwIG4g CjAwMDAwODU4ODUgMDAwMDAgbiAKMDAwMDA4NjI0NyAwMDAwMCBuIAowMDAwMDg2NTAzIDAwMDAw IG4gCjAwMDAwODcwNjQgMDAwMDAgbiAKMDAwMDA4NzE4MCAwMDAwMCBuIAowMDAwMDg3NTQyIDAw MDAwIG4gCjAwMDAxNDI1MTcgMDAwMDAgbiAKMDAwMDA4Nzc5OCAwMDAwMCBuIAowMDAwMDg4NzM3 IDAwMDAwIG4gCjAwMDAwODg4NTMgMDAwMDAgbiAKMDAwMDE0MzY1OCAwMDAwMCBuIAowMDAwMDg5 MjExIDAwMDAwIG4gCjAwMDAwODk0NjQgMDAwMDAgbiAKMDAwMDA5MDAxNyAwMDAwMCBuIAowMDAw MTQ0Nzk5IDAwMDAwIG4gCjAwMDAwOTAxMzMgMDAwMDAgbiAKMDAwMDA5MDQ5MSAwMDAwMCBuIAow MDAwMDkwNzQ0IDAwMDAwIG4gCjAwMDAwOTExNzkgMDAwMDAgbiAKMDAwMDE1MzM5NiAwMDAwMCBu IAowMDAwMDkxMjk1IDAwMDAwIG4gCjAwMDAwOTE2NTcgMDAwMDAgbiAKMDAwMDA5MTkxMyAwMDAw MCBuIAowMDAwMDkyMjU2IDAwMDAwIG4gCjAwMDAxNTgyOTMgMDAwMDAgbiAKMDAwMDEwNjUyOSAw MDAwMCBuIAowMDAwMDkyNzI3IDAwMDAwIG4gCjAwMDAwOTMwODkgMDAwMDAgbiAKMDAwMDE1OTQz NiAwMDAwMCBuIAowMDAwMDkzMzQ1IDAwMDAwIG4gCjAwMDAwOTM4NjggMDAwMDAgbiAKMDAwMDA5 NDU4NiAwMDAwMCBuIAowMDAwMDk1MTQ5IDAwMDAwIG4gCjAwMDAxNjQxNTAgMDAwMDAgbiAKMDAw MDA5NTUwOCAwMDAwMCBuIAowMDAwMDk1NjI0IDAwMDAwIG4gCjAwMDAwOTU5ODIgMDAwMDAgbiAK MDAwMDA5NjIzNSAwMDAwMCBuIAowMDAwMDk2OTY4IDAwMDAwIG4gCjAwMDAwOTcwODQgMDAwMDAg biAKMDAwMDA5NzUxNiAwMDAwMCBuIAowMDAwMDk3ODMzIDAwMDAwIG4gCjAwMDAxNzQ0MDUgMDAw MDAgbiAKMDAwMDA5ODgzNSAwMDAwMCBuIAowMDAwMDk4OTUxIDAwMDAwIG4gCjAwMDAwOTkzMTMg MDAwMDAgbiAKMDAwMDA5OTU2OSAwMDAwMCBuIAowMDAwMTc3MzA4IDAwMDAwIG4gCjAwMDAwOTk3 NzQgMDAwMDAgbiAKMDAwMDA5OTg5MCAwMDAwMCBuIAowMDAwMTAwMjQ4IDAwMDAwIG4gCjAwMDAx MDA1MDEgMDAwMDAgbiAKMDAwMDEwMDc3NSAwMDAwMCBuIAowMDAwMTAwODkxIDAwMDAwIG4gCjAw MDAxMDEyNTMgMDAwMDAgbiAKMDAwMDEwMTUwOSAwMDAwMCBuIAowMDAwMTAyMTQ5IDAwMDAwIG4g CjAwMDAxMDIyNjUgMDAwMDAgbiAKMDAwMDEwMjY5NyAwMDAwMCBuIAowMDAwMTAzMDE0IDAwMDAw IG4gCjAwMDAxMDMzOTkgMDAwMDAgbiAKMDAwMDEwMzUxNSAwMDAwMCBuIAowMDAwMTA0NzgwIDAw MDAwIG4gCjAwMDAxMDQ4OTYgMDAwMDAgbiAKMDAwMDEwNTI1NCAwMDAwMCBuIAowMDAwMTA1NTA3 IDAwMDAwIG4gCjAwMDAxMDYyMzggMDAwMDAgbiAKMDAwMDExNDUxMyAwMDAwMCBuIAowMDAwMTA2 NzgwIDAwMDAwIG4gCjAwMDAxMDcxNDIgMDAwMDAgbiAKMDAwMDEwNzM5OCAwMDAwMCBuIAowMDAw MTA3NzYwIDAwMDAwIG4gCjAwMDAxMDgwMTYgMDAwMDAgbiAKMDAwMDEwODUzOSAwMDAwMCBuIAow MDAwMTA5NzI4IDAwMDAwIG4gCjAwMDAxMDk4NDQgMDAwMDAgbiAKMDAwMDExMDI3NiAwMDAwMCBu IAowMDAwMTEwNTkzIDAwMDAwIG4gCjAwMDAxMTA4MjQgMDAwMDAgbiAKMDAwMDExMDk0MCAwMDAw MCBuIAowMDAwMTExMzAyIDAwMDAwIG4gCjAwMDAxMTE1NTggMDAwMDAgbiAKMDAwMDExMTg3MiAw MDAwMCBuIAowMDAwMTExOTg4IDAwMDAwIG4gCjAwMDAxMTIyMjYgMDAwMDAgbiAKMDAwMDExMjU4 OCAwMDAwMCBuIAowMDAwMTEyODQ0IDAwMDAwIG4gCjAwMDAxMTMxNzAgMDAwMDAgbiAKMDAwMDEx MzI4NiAwMDAwMCBuIAowMDAwMTEzNjQ4IDAwMDAwIG4gCjAwMDAxMTM5MDQgMDAwMDAgbiAKMDAw MDExNDIyMSAwMDAwMCBuIAowMDAwMTIyMTEyIDAwMDAwIG4gCjAwMDAxMTQ2ODQgMDAwMDAgbiAK MDAwMDExNTA0MiAwMDAwMCBuIAowMDAwMTE3MzcyIDAwMDAwIG4gCjAwMDAxMTUyOTUgMDAwMDAg biAKMDAwMDExNTgyMCAwMDAwMCBuIAowMDAwMTE2MTgyIDAwMDAwIG4gCjAwMDAxMTY0MzggMDAw MDAgbiAKMDAwMDExNzQ4OCAwMDAwMCBuIAowMDAwMTE3OTIwIDAwMDAwIG4gCjAwMDAxMTgyMzcg MDAwMDAgbiAKMDAwMDExOTE1MSAwMDAwMCBuIAowMDAwMTE5MjY3IDAwMDAwIG4gCjAwMDAxMTk2 MjUgMDAwMDAgbiAKMDAwMDExOTg3OCAwMDAwMCBuIAowMDAwMTIwNTMzIDAwMDAwIG4gCjAwMDAx MjA2NDkgMDAwMDAgbiAKMDAwMDEyMTgyMCAwMDAwMCBuIAowMDAwMTI0NTY4IDAwMDAwIG4gCjAw MDAxMjIyNDMgMDAwMDAgbiAKMDAwMDEyMjYwNSAwMDAwMCBuIAowMDAwMTIyODYxIDAwMDAwIG4g CjAwMDAxMjMzODQgMDAwMDAgbiAKMDAwMDEyNDI3NiAwMDAwMCBuIAowMDAwMTIzNzQ2IDAwMDAw IG4gCjAwMDAxMjQwMDIgMDAwMDAgbiAKMDAwMDEzMzE0MyAwMDAwMCBuIAowMDAwMTI0NjM1IDAw MDAwIG4gCjAwMDAxMjQ5OTcgMDAwMDAgbiAKMDAwMDEyNTI1MyAwMDAwMCBuIAowMDAwMTI1Nzc4 IDAwMDAwIG4gCjAwMDAxMjYxNDAgMDAwMDAgbiAKMDAwMDEyNjM5NiAwMDAwMCBuIAowMDAwMTI3 Mjk1IDAwMDAwIG4gCjAwMDAxMjc0MTEgMDAwMDAgbiAKMDAwMDEyNzc3MyAwMDAwMCBuIAowMDAw MTI4MDI5IDAwMDAwIG4gCjAwMDAxMjk0ODUgMDAwMDAgbiAKMDAwMDEyOTYwMSAwMDAwMCBuIAow MDAwMTMwMDMzIDAwMDAwIG4gCjAwMDAxMzAzNTAgMDAwMDAgbiAKMDAwMDEzMDU2MyAwMDAwMCBu IAowMDAwMTMwNjc5IDAwMDAwIG4gCjAwMDAxMzE3NjEgMDAwMDAgbiAKMDAwMDEzMTg3NiAwMDAw MCBuIAowMDAwMTMyODUyIDAwMDAwIG4gCjAwMDAxMzk0OTMgMDAwMDAgbiAKMDAwMDEzMzI5MCAw MDAwMCBuIAowMDAwMTMzNjUyIDAwMDAwIG4gCjAwMDAxMzc3NjIgMDAwMDAgbiAKMDAwMDEzMzkw OCAwMDAwMCBuIAowMDAwMTM0NDMzIDAwMDAwIG4gCjAwMDAxMzYwMTggMDAwMDAgbiAKMDAwMDEz ODc0OSAwMDAwMCBuIAowMDAwMTM3MzI3IDAwMDAwIG4gCjAwMDAxMzc4NzggMDAwMDAgbiAKMDAw MDEzODI0MCAwMDAwMCBuIAowMDAwMTM5MjAxIDAwMDAwIG4gCjAwMDAxNzg5MjMgMDAwMDAgbiAK MDAwMDE4MDM3NiAwMDAwMCBuIAowMDAwMTQwNTM5IDAwMDAwIG4gCjAwMDAxODA4MzcgMDAwMDAg biAKMDAwMDEzODQ5NiAwMDAwMCBuIAowMDAwMTM4ODY1IDAwMDAwIG4gCjAwMDAxNDA4MzEgMDAw MDAgbiAKMDAwMDEzOTYwMCAwMDAwMCBuIAowMDAwMTM5OTYyIDAwMDAwIG4gCjAwMDAxNDAyMTgg MDAwMDAgbiAKMDAwMDE0NjY3OCAwMDAwMCBuIAowMDAwMTQwODc0IDAwMDAwIG4gCjAwMDAxNDEy MzYgMDAwMDAgbiAKMDAwMDE0MTQ5MiAwMDAwMCBuIAowMDAwMTQxODU0IDAwMDAwIG4gCjAwMDAx NDIxMTAgMDAwMDAgbiAKMDAwMDE0MjYzMyAwMDAwMCBuIAowMDAwMTQyOTk1IDAwMDAwIG4gCjAw MDAxNDMyNTEgMDAwMDAgbiAKMDAwMDE0Mzc3NCAwMDAwMCBuIAowMDAwMTQ0MTM2IDAwMDAwIG4g CjAwMDAxNDQzOTIgMDAwMDAgbiAKMDAwMDE0NDkxNSAwMDAwMCBuIAowMDAwMTQ1Mjc3IDAwMDAw IG4gCjAwMDAxNDg5NTMgMDAwMDAgbiAKMDAwMDE0NzA0MCAwMDAwMCBuIAowMDAwMTQ1NTMzIDAw MDAwIG4gCjAwMDAxNDU3NDAgMDAwMDAgbiAKMDAwMDE0NzU3NCAwMDAwMCBuIAowMDAwMTQ1ODU2 IDAwMDAwIG4gCjAwMDAxNTM3MzEgMDAwMDAgbiAKMDAwMDE0NjA2MyAwMDAwMCBuIAowMDAwMTQ2 MTc5IDAwMDAwIG4gCjAwMDAxNDYzODYgMDAwMDAgbiAKMDAwMDE0NzMzMiAwMDAwMCBuIAowMDAw MTQ2ODMzIDAwMDAwIG4gCjAwMDAxNDc4NjYgMDAwMDAgbiAKMDAwMDE0OTg4OSAwMDAwMCBuIAow MDAwMTUyMDMwIDAwMDAwIG4gCjAwMDAxNDczNjcgMDAwMDAgbiAKMDAwMDE1MDIwNiAwMDAwMCBu IAowMDAwMTUxMTE3IDAwMDAwIG4gCjAwMDAxNTQ2NjkgMDAwMDAgbiAKMDAwMDE0NzkwMSAwMDAw MCBuIAowMDAwMTQ4MjYzIDAwMDAwIG4gCjAwMDAxNDg1MTkgMDAwMDAgbiAKMDAwMDE0OTA2OSAw MDAwMCBuIAowMDAwMTQ5NDMxIDAwMDAwIG4gCjAwMDAxNDk2ODcgMDAwMDAgbiAKMDAwMDE1MDAw NCAwMDAwMCBuIAowMDAwMTUwMzIyIDAwMDAwIG4gCjAwMDAxNTA2ODQgMDAwMDAgbiAKMDAwMDE1 MjMyNiAwMDAwMCBuIAowMDAwMTUxMjA4IDAwMDAwIG4gCjAwMDAxNTE1NzAgMDAwMDAgbiAKMDAw MDE1MTgyNyAwMDAwMCBuIAowMDAwMTU0OTY1IDAwMDAwIG4gCjAwMDAxNTIzNjkgMDAwMDAgbiAK MDAwMDE1MjczMSAwMDAwMCBuIAowMDAwMTUyOTg4IDAwMDAwIG4gCjAwMDAxNTM1MTIgMDAwMDAg biAKMDAwMDE1Mzg0NyAwMDAwMCBuIAowMDAwMTU0MjA5IDAwMDAwIG4gCjAwMDAxNTQ0NjYgMDAw MDAgbiAKMDAwMDE1NzE5OSAwMDAwMCBuIAowMDAwMTU1MDQ4IDAwMDAwIG4gCjAwMDAxNTU0MTAg MDAwMDAgbiAKMDAwMDE1NTY2NyAwMDAwMCBuIAowMDAwMTU1ODc1IDAwMDAwIG4gCjAwMDAxNTU5 OTEgMDAwMDAgbiAKMDAwMDE1NjM1MyAwMDAwMCBuIAowMDAwMTU2NjEwIDAwMDAwIG4gCjAwMDAx NTY5MDQgMDAwMDAgbiAKMDAwMDE2MTg0MSAwMDAwMCBuIAowMDAwMTU3MjY2IDAwMDAwIG4gCjAw MDAxNTc2MjggMDAwMDAgbiAKMDAwMDE1Nzg4NSAwMDAwMCBuIAowMDAwMTU4NDA5IDAwMDAwIG4g CjAwMDAxNTg3NzEgMDAwMDAgbiAKMDAwMDE1OTAyOCAwMDAwMCBuIAowMDAwMTU5NTUyIDAwMDAw IG4gCjAwMDAxNTk5MTAgMDAwMDAgbiAKMDAwMDE2MDE2NCAwMDAwMCBuIAowMDAwMTYwMzcyIDAw MDAwIG4gCjAwMDAxNjA0ODggMDAwMDAgbiAKMDAwMDE2MDcyNCAwMDAwMCBuIAowMDAwMTYxMDgy IDAwMDAwIG4gCjAwMDAxNjEzMzYgMDAwMDAgbiAKMDAwMDE2MTU0NiAwMDAwMCBuIAowMDAwMTYz MDgwIDAwMDAwIG4gCjAwMDAxNjE5NjQgMDAwMDAgbiAKMDAwMDE2MjMyMiAwMDAwMCBuIAowMDAw MTYyNTc2IDAwMDAwIG4gCjAwMDAxNjI3ODQgMDAwMDAgbiAKMDAwMDE2NjMyMiAwMDAwMCBuIAow MDAwMTYzMTIzIDAwMDAwIG4gCjAwMDAxNjM0ODUgMDAwMDAgbiAKMDAwMDE2Mzc0MiAwMDAwMCBu IAowMDAwMTY0MjY2IDAwMDAwIG4gCjAwMDAxNjQ2MjggMDAwMDAgbiAKMDAwMDE2NDg4NSAwMDAw MCBuIAowMDAwMTY1MDg4IDAwMDAwIG4gCjAwMDAxNjUyMDQgMDAwMDAgbiAKMDAwMDE2NTU2NiAw MDAwMCBuIAowMDAwMTY1ODIzIDAwMDAwIG4gCjAwMDAxNjYwMjYgMDAwMDAgbiAKMDAwMDE2ODYx OSAwMDAwMCBuIAowMDAwMTY2NDEzIDAwMDAwIG4gCjAwMDAxNjY3NzUgMDAwMDAgbiAKMDAwMDE2 NzAzMiAwMDAwMCBuIAowMDAwMTY3MjM1IDAwMDAwIG4gCjAwMDAxNjczNTEgMDAwMDAgbiAKMDAw MDE2NzcwOSAwMDAwMCBuIAowMDAwMTY3OTYzIDAwMDAwIG4gCjAwMDAxNjgzMjQgMDAwMDAgbiAK MDAwMDE3MjA2MSAwMDAwMCBuIAowMDAwMTY4Njg2IDAwMDAwIG4gCjAwMDAxNjkwNDggMDAwMDAg biAKMDAwMDE2OTMwNSAwMDAwMCBuIAowMDAwMTY5ODMxIDAwMDAwIG4gCjAwMDAxNzAxOTMgMDAw MDAgbiAKMDAwMDE3MDQ1MCAwMDAwMCBuIAowMDAwMTcwNzkyIDAwMDAwIG4gCjAwMDAxNzA5MDgg MDAwMDAgbiAKMDAwMDE3MTI3MCAwMDAwMCBuIAowMDAwMTcxNTI3IDAwMDAwIG4gCjAwMDAxNzE3 NjUgMDAwMDAgbiAKMDAwMDE3MzMzNSAwMDAwMCBuIAowMDAwMTcyMTUyIDAwMDAwIG4gCjAwMDAx NzI1MTQgMDAwMDAgbiAKMDAwMDE3Mjc3MSAwMDAwMCBuIAowMDAwMTczMDM5IDAwMDAwIG4gCjAw MDAxNzQ3MDEgMDAwMDAgbiAKMDAwMDE3MzM3OCAwMDAwMCBuIAowMDAwMTczNzQwIDAwMDAwIG4g CjAwMDAxNzM5OTcgMDAwMDAgbiAKMDAwMDE3NjIzOCAwMDAwMCBuIAowMDAwMTc0NzQ0IDAwMDAw IG4gCjAwMDAxNzUxNzYgMDAwMDAgbiAKMDAwMDE3NTQ5NCAwMDAwMCBuIAowMDAwMTc1OTQyIDAw MDAwIG4gCjAwMDAxNzkyMTkgMDAwMDAgbiAKMDAwMDE3NjI4MSAwMDAwMCBuIAowMDAwMTc2NjQz IDAwMDAwIG4gCjAwMDAxNzY5MDAgMDAwMDAgbiAKMDAwMDE3NzQyNCAwMDAwMCBuIAowMDAwMTc3 Nzg2IDAwMDAwIG4gCjAwMDAxNzgwNDMgMDAwMDAgbiAKMDAwMDE4MTEzMyAwMDAwMCBuIAowMDAw MTc5Mjg2IDAwMDAwIG4gCjAwMDAxNzk3MTYgMDAwMDAgbiAKMDAwMDE4MDAzMiAwMDAwMCBuIAow MDAwMTgwNDkyIDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSA2MjcvUHJldiA2NTczNS9Sb290IDEg MCBSL0luZm8gMiAwIFIvSURbPDFCMEY3NjAyMjc4NDNCMjIxM0YxNzlFRjgxNTBFRUVBPjxBMDdB NUQ4QjYyOTk4RDEwNDkzN0EwNjNCNkQ3QzVDNT5dPj4Kc3RhcnR4cmVmCjE4MTE5MgolJUVPRgoK MiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOS4wNCkKL0NyZWF0aW9uRGF0ZShE OjIwMTIwODMwMTcyOTU0LTA0JzAwJykvVGl0bGUoRW5zY3JpcHQgT3V0cHV0KQovQ3JlYXRvcihH TlUgZW5zY3JpcHQgMS42LjUuMSkvTW9kRGF0ZShEOjIwMTIxMDAzMTYzMTI5KzAyJzAwJyk+Pgpl bmRvYmoKMjM4IDAgb2JqClszMTcxIDMgNjQwNDIgNjQwMzYgNTkxMjYgNjQwMzAgNjQwNDIgNjQw MzYgNTkxMjYgNjQwMzAgMTgxMTkyIDwzQjAzNkY4OURENDRBM0M2OTM5NzQxQjAzMzhEQjlDRj4g MiAwIDE4OTgwOSAxODk4MDMgMTg5Nzk2XQplbmRvYmoKNjI3IDAgb2JqCjw8L0xlbmd0aCAyPj5z dHJlYW0KcQoKZW5kc3RyZWFtCmVuZG9iago2MjggMCBvYmoKPDwvTGVuZ3RoIDI+PnN0cmVhbQpR CgplbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNjMyIDAgUiAvQ29udGVudHNb NjI3IDAgUiA1IDAgUiA2MjggMCBSIDYzMSAwIFJdL0Fubm90cyAyNDAgMCBSPj4KZW5kb2JqCjI0 MCAwIG9iagpbNjI5IDAgUiA2MzAgMCBSXQplbmRvYmoKMjEgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNjQw IDAgUiAvQ29udGVudHNbNjI3IDAgUiAyMiAwIFIgNjI4IDAgUiA2MzkgMCBSXS9Bbm5vdHMgMjUx IDAgUj4+CmVuZG9iagoyNTEgMCBvYmoKWzYzMyAwIFIgNjM0IDAgUiA2MzUgMCBSIDYzNiAwIFIg NjM3IDAgUiA2MzggMCBSXQplbmRvYmoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw IDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNjQ4IDAgUiAvQ29u dGVudHNbNjI3IDAgUiAyNyAwIFIgNjI4IDAgUiA2NDcgMCBSXS9Bbm5vdHMgMjc2IDAgUj4+CmVu ZG9iagoyNzYgMCBvYmoKWzY0MSAwIFIgNjQyIDAgUiA2NDMgMCBSIDY0NCAwIFIgNjQ1IDAgUiA2 NDYgMCBSXQplbmRvYmoKMzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5 Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNjUzIDAgUiAvQ29udGVudHNbNjI3 IDAgUiAzMiAwIFIgNjI4IDAgUiA2NTIgMCBSXS9Bbm5vdHMgMzAwIDAgUj4+CmVuZG9iagozMDAg MCBvYmoKWzY0OSAwIFIgNjUwIDAgUiA2NTEgMCBSXQplbmRvYmoKMzYgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJj ZXMgNjYyIDAgUiAvQ29udGVudHNbNjI3IDAgUiAzNyAwIFIgNjI4IDAgUiA2NjEgMCBSXS9Bbm5v dHMgMzE3IDAgUj4+CmVuZG9iagozMTcgMCBvYmoKWzY1NCAwIFIgNjU1IDAgUiA2NTYgMCBSIDY1 NyAwIFIgNjU4IDAgUiA2NTkgMCBSIDY2MCAwIFJdCmVuZG9iago0MSAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNl cyA2NzQgMCBSIC9Db250ZW50c1s2MjcgMCBSIDQyIDAgUiA2MjggMCBSIDY3MyAwIFJdL0Fubm90 cyAzNDkgMCBSPj4KZW5kb2JqCjM0OSAwIG9iagpbNjYzIDAgUiA2NjQgMCBSIDY2NSAwIFIgNjY2 IDAgUiA2NjcgMCBSIDY2OCAwIFIgNjY5IDAgUiA2NzAgMCBSIDY3MSAwIFIgNjcyIDAgUl0KZW5k b2JqCjQ2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDY4MiAwIFIgL0NvbnRlbnRzWzYyNyAwIFIgNDcgMCBS IDYyOCAwIFIgNjgxIDAgUl0vQW5ub3RzIDM5MSAwIFI+PgplbmRvYmoKMzkxIDAgb2JqCls2NzUg MCBSIDY3NiAwIFIgNjc3IDAgUiA2NzggMCBSIDY3OSAwIFIgNjgwIDAgUl0KZW5kb2JqCjUxIDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIvUmVzb3VyY2VzIDY4OSAwIFIgL0NvbnRlbnRzWzYyNyAwIFIgNTIgMCBSIDYyOCAwIFIg Njg4IDAgUl0vQW5ub3RzIDQxNiAwIFI+PgplbmRvYmoKNDE2IDAgb2JqCls2ODMgMCBSIDY4NCAw IFIgNjg1IDAgUiA2ODYgMCBSIDY4NyAwIFJdCmVuZG9iago1NiAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyA2 OTMgMCBSIC9Db250ZW50c1s2MjcgMCBSIDU3IDAgUiA2MjggMCBSIDY5MiAwIFJdL0Fubm90cyA0 MzQgMCBSPj4KZW5kb2JqCjQzNCAwIG9iagpbNjkwIDAgUiA2OTEgMCBSXQplbmRvYmoKNjYgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUi9SZXNvdXJjZXMgNzAxIDAgUiAvQ29udGVudHNbNjI3IDAgUiA2NyAwIFIgNjI4IDAgUiA3 MDAgMCBSXS9Bbm5vdHMgNDQyIDAgUj4+CmVuZG9iago0NDIgMCBvYmoKWzY5NCAwIFIgNjk1IDAg UiA2OTYgMCBSIDY5NyAwIFIgNjk4IDAgUiA2OTkgMCBSXQplbmRvYmoKNzEgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNv dXJjZXMgNzA3IDAgUiAvQ29udGVudHNbNjI3IDAgUiA3MiAwIFIgNjI4IDAgUiA3MDYgMCBSXS9B bm5vdHMgNDYyIDAgUj4+CmVuZG9iago0NjIgMCBvYmoKWzcwMiAwIFIgNzAzIDAgUiA3MDQgMCBS IDcwNSAwIFJdCmVuZG9iago3NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIg NzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyA3MTAgMCBSIC9Db250ZW50c1s2 MjcgMCBSIDc3IDAgUiA2MjggMCBSIDcwOSAwIFJdL0Fubm90cyA0ODAgMCBSPj4KZW5kb2JqCjQ4 MCAwIG9iagpbNzA4IDAgUl0KZW5kb2JqCjgxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDcxOCAwIFIgL0Nv bnRlbnRzWzYyNyAwIFIgODIgMCBSIDYyOCAwIFIgNzE3IDAgUl0vQW5ub3RzIDQ4NCAwIFI+Pgpl bmRvYmoKNDg0IDAgb2JqCls3MTEgMCBSIDcxMiAwIFIgNzEzIDAgUiA3MTQgMCBSIDcxNSAwIFIg NzE2IDAgUl0KZW5kb2JqCjg2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3 OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDcyMSAwIFIgL0NvbnRlbnRzWzYy NyAwIFIgODcgMCBSIDYyOCAwIFIgNzIwIDAgUl0vQW5ub3RzIDUwOCAwIFI+PgplbmRvYmoKNTA4 IDAgb2JqCls3MTkgMCBSXQplbmRvYmoKOTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw IDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNzI0IDAgUiAvQ29u dGVudHNbNjI3IDAgUiA5MiAwIFIgNjI4IDAgUiA3MjMgMCBSXS9Bbm5vdHMgNTEwIDAgUj4+CmVu ZG9iago1MTAgMCBvYmoKWzcyMiAwIFJdCmVuZG9iago5NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyA3Mjkg MCBSIC9Db250ZW50c1s2MjcgMCBSIDk3IDAgUiA2MjggMCBSIDcyOCAwIFJdL0Fubm90cyA1MTUg MCBSPj4KZW5kb2JqCjUxNSAwIG9iagpbNzI1IDAgUiA3MjYgMCBSIDcyNyAwIFJdCmVuZG9iagox MDEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUi9SZXNvdXJjZXMgNzMyIDAgUiAvQ29udGVudHNbNjI3IDAgUiAxMDIgMCBSIDYy OCAwIFIgNzMxIDAgUl0vQW5ub3RzIDUyNiAwIFI+PgplbmRvYmoKNTI2IDAgb2JqCls3MzAgMCBS XQplbmRvYmoKMTA2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDczNyAwIFIgL0NvbnRlbnRzWzYyNyAwIFIg MTA3IDAgUiA2MjggMCBSIDczNiAwIFJdL0Fubm90cyA1MzAgMCBSPj4KZW5kb2JqCjUzMCAwIG9i agpbNzMzIDAgUiA3MzQgMCBSIDczNSAwIFJdCmVuZG9iagoxMTEgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMg NzQxIDAgUiAvQ29udGVudHNbNjI3IDAgUiAxMTIgMCBSIDYyOCAwIFIgNzQwIDAgUl0vQW5ub3Rz IDUzOCAwIFI+PgplbmRvYmoKNTM4IDAgb2JqCls3MzggMCBSIDczOSAwIFJdCmVuZG9iagoxMTYg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUi9SZXNvdXJjZXMgNzQ3IDAgUiAvQ29udGVudHNbNjI3IDAgUiAxMTcgMCBSIDYyOCAw IFIgNzQ2IDAgUl0vQW5ub3RzIDU0NyAwIFI+PgplbmRvYmoKNTQ3IDAgb2JqCls3NDIgMCBSIDc0 MyAwIFIgNzQ0IDAgUiA3NDUgMCBSXQplbmRvYmoKMTIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDc1MCAw IFIgL0NvbnRlbnRzWzYyNyAwIFIgMTIyIDAgUiA2MjggMCBSIDc0OSAwIFJdL0Fubm90cyA1NjMg MCBSPj4KZW5kb2JqCjU2MyAwIG9iagpbNzQ4IDAgUl0KZW5kb2JqCjEyNiAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291 cmNlcyA3NTUgMCBSIC9Db250ZW50c1s2MjcgMCBSIDEyNyAwIFIgNjI4IDAgUiA3NTQgMCBSXS9B bm5vdHMgNTY4IDAgUj4+CmVuZG9iago1NjggMCBvYmoKWzc1MSAwIFIgNzUyIDAgUiA3NTMgMCBS XQplbmRvYmoKMTMxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDc1OSAwIFIgL0NvbnRlbnRzWzYyNyAwIFIg MTMyIDAgUiA2MjggMCBSIDc1OCAwIFJdL0Fubm90cyA1ODAgMCBSPj4KZW5kb2JqCjU4MCAwIG9i agpbNzU2IDAgUiA3NTcgMCBSXQplbmRvYmoKMTM2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDc2NCAwIFIg L0NvbnRlbnRzWzYyNyAwIFIgMTM3IDAgUiA2MjggMCBSIDc2MyAwIFJdL0Fubm90cyA1ODkgMCBS Pj4KZW5kb2JqCjU4OSAwIG9iagpbNzYwIDAgUiA3NjEgMCBSIDc2MiAwIFJdCmVuZG9iagoxNDEg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUi9SZXNvdXJjZXMgNzY3IDAgUiAvQ29udGVudHNbNjI3IDAgUiAxNDIgMCBSIDYyOCAw IFIgNzY2IDAgUl0vQW5ub3RzIDYwMSAwIFI+PgplbmRvYmoKNjAxIDAgb2JqCls3NjUgMCBSXQpl bmRvYmoKMTUxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3Rh dGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDc3MCAwIFIgL0NvbnRlbnRzWzYyNyAwIFIgMTUy IDAgUiA2MjggMCBSIDc2OSAwIFJdL0Fubm90cyA2MDYgMCBSPj4KZW5kb2JqCjYwNiAwIG9iagpb NzY4IDAgUl0KZW5kb2JqCjE2NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIg NzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyA3NzMgMCBSIC9Db250ZW50c1s2 MjcgMCBSIDE2NyAwIFIgNjI4IDAgUiA3NzIgMCBSXS9Bbm5vdHMgNjEwIDAgUj4+CmVuZG9iago2 MTAgMCBvYmoKWzc3MSAwIFJdCmVuZG9iagoxODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNzc3IDAgUiAv Q29udGVudHNbNjI3IDAgUiAxODIgMCBSIDYyOCAwIFIgNzc2IDAgUl0vQW5ub3RzIDYxNSAwIFI+ PgplbmRvYmoKNjE1IDAgb2JqCls3NzQgMCBSIDc3NSAwIFJdCmVuZG9iagoxODYgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9S ZXNvdXJjZXMgNzgxIDAgUiAvQ29udGVudHNbNjI3IDAgUiAxODcgMCBSIDYyOCAwIFIgNzgwIDAg Ul0vQW5ub3RzIDYyMiAwIFI+PgplbmRvYmoKNjIyIDAgb2JqCls3NzggMCBSIDc3OSAwIFJdCmVu ZG9iago3ODMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9S ZWN0WzYwLjU2MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzQgMCBSIC9YWVogMC4wMDAg Njc5LjMyOCAwXT4+CmVuZG9iago2MjkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDY1OC4zMjggMjUuNDUzIDY3OS4zMjhdL0Rlc3RbNzgy IDAgUiAvWFlaIDYwLjU2MiA3MjIuMDAwIDBdPj4KZW5kb2JqCjc4NCAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDY2NC41MDAgODUuMDE1 IDY4NS41MDBdL0Rlc3RbNCAwIFIgL1hZWiAwLjAwMCA0NTAuMDg4IDBdPj4KZW5kb2JqCjYzMCAw IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAg NDI5LjA4OCAyNS40NTMgNDUwLjA4OF0vRGVzdFs3ODIgMCBSIC9YWVogNjAuNTYyIDY4NS41MDAg MF0+PgplbmRvYmoKNzg1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw IDAgMF0vUmVjdFs2MC41NjIgNjI4LjAwMCA4NS4wMTUgNjQ5LjAwMF0vRGVzdFsyMSAwIFIgL1hZ WiAwLjAwMCA2OTUuNjU4IDBdPj4KZW5kb2JqCjYzMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNjc0LjY1OCAyNS40NTMgNjk1LjY1OF0v RGVzdFs3ODIgMCBSIC9YWVogNjAuNTYyIDY0OS4wMDAgMF0+PgplbmRvYmoKNzg2IDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgNTc5LjUw MCA4NS4wMTUgNjAwLjUwMF0vRGVzdFsyMSAwIFIgL1hZWiA1ODYuNTQ3IDY4Mi45NzggMF0+Pgpl bmRvYmoKNjM0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs1ODYuNTQ3IDY2MS45NzggNjEyLjAwMCA2ODIuOTc4XS9EZXN0Wzc4MiAwIFIgL1hZWiA2 MC41NjIgNjAwLjUwMCAwXT4+CmVuZG9iago3ODcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA1MzEuMDAwIDg1LjAxNSA1NTIuMDAwXS9E ZXN0WzIxIDAgUiAvWFlaIDU4Ni41NDcgNjQ5Ljk3OCAwXT4+CmVuZG9iago2MzUgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgNjI4Ljk3 OCA2MTIuMDAwIDY0OS45NzhdL0Rlc3RbNzgyIDAgUiAvWFlaIDYwLjU2MiA1NTIuMDAwIDBdPj4K ZW5kb2JqCjc4OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbNjAuNTYyIDQ3MC41MDAgODUuMDE1IDQ5MS41MDBdL0Rlc3RbMjEgMCBSIC9YWVogMC4w MDAgNDMzLjEyOCAwXT4+CmVuZG9iago2MzYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDQxMi4xMjggMjUuNDUzIDQzMy4xMjhdL0Rlc3Rb NzgyIDAgUiAvWFlaIDYwLjU2MiA0OTEuNTAwIDBdPj4KZW5kb2JqCjc4OSAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDMzOC4wMDAgODUu MDE1IDM1OS4wMDBdL0Rlc3RbMjEgMCBSIC9YWVogNTg2LjU0NyAzOTguNDQ4IDBdPj4KZW5kb2Jq CjYzNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb NTg2LjU0NyAzNzcuNDQ4IDYxMi4wMDAgMzk4LjQ0OF0vRGVzdFs3ODIgMCBSIC9YWVogNjAuNTYy IDM1OS4wMDAgMF0+PgplbmRvYmoKNzkwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMjg5LjUwMCA4NS4wMTUgMzEwLjUwMF0vRGVzdFsy MSAwIFIgL1hZWiA1ODYuNTQ3IDI5Ny43NjggMF0+PgplbmRvYmoKNjM4IDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODYuNTQ3IDI3Ni43NjggNjEy LjAwMCAyOTcuNzY4XS9EZXN0Wzc4MiAwIFIgL1hZWiA2MC41NjIgMzEwLjUwMCAwXT4+CmVuZG9i ago3OTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzYwLjU2MiAyNTMuMDAwIDg1LjAxNSAyNzQuMDAwXS9EZXN0WzI2IDAgUiAvWFlaIDU4Ni41NDcg NjQ1LjAxOCAwXT4+CmVuZG9iago2NDEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgNjI0LjAxOCA2MTIuMDAwIDY0NS4wMThdL0Rlc3Rb NzgyIDAgUiAvWFlaIDYwLjU2MiAyNzQuMDAwIDBdPj4KZW5kb2JqCjc5MiAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDIwNC41MDAgODUu MDE1IDIyNS41MDBdL0Rlc3RbMjYgMCBSIC9YWVogNTg2LjU0NyA2NjYuMDE4IDBdPj4KZW5kb2Jq CjY0MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb NTg2LjU0NyA2NDUuMDE4IDYxMi4wMDAgNjY2LjAxOF0vRGVzdFs3ODIgMCBSIC9YWVogNjAuNTYy IDIyNS41MDAgMF0+PgplbmRvYmoKNzkzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMTMyLjAwMCA4NS4wMTUgMTUzLjAwMF0vRGVzdFsy NiAwIFIgL1hZWiA1ODYuNTQ3IDMxOS4wNTggMF0+PgplbmRvYmoKNjQzIDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODYuNTQ3IDI5OC4wNTggNjEy LjAwMCAzMTkuMDU4XS9EZXN0Wzc4MiAwIFIgL1hZWiA2MC41NjIgMTUzLjAwMCAwXT4+CmVuZG9i ago3OTUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzYwLjU2MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzI2IDAgUiAvWFlaIDAuMDAwIDUx NS43OTggMF0+PgplbmRvYmoKNjQ0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv cmRlclswIDAgMF0vUmVjdFswLjAwMCA0OTQuNzk4IDI1LjQ1MyA1MTUuNzk4XS9EZXN0Wzc5NCAw IFIgL1hZWiA2MC41NjIgNzIyLjAwMCAwXT4+CmVuZG9iago3OTYgMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA1NjguNTAwIDg1LjAxNSA1 ODkuNTAwXS9EZXN0WzI2IDAgUiAvWFlaIDAuMDAwIDIwNS45ODggMF0+PgplbmRvYmoKNjQ1IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAx ODQuOTg4IDI1LjQ1MyAyMDUuOTg4XS9EZXN0Wzc5NCAwIFIgL1hZWiA2MC41NjIgNTg5LjUwMCAw XT4+CmVuZG9iago3OTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzYwLjU2MiA1MjAuMDAwIDg1LjAxNSA1NDEuMDAwXS9EZXN0WzI2IDAgUiAvWFla IDU4Ni41NDcgMjk1LjM3OCAwXT4+CmVuZG9iago2NDYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgMjc0LjM3OCA2MTIuMDAwIDI5NS4z NzhdL0Rlc3RbNzk0IDAgUiAvWFlaIDYwLjU2MiA1NDEuMDAwIDBdPj4KZW5kb2JqCjc5OCAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDQ4 My41MDAgODUuMDE1IDUwNC41MDBdL0Rlc3RbMzEgMCBSIC9YWVogMC4wMDAgMzk0LjY2OCAwXT4+ CmVuZG9iago2NDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzAuMDAwIDM3My42NjggMjUuNDUzIDM5NC42NjhdL0Rlc3RbNzk0IDAgUiAvWFlaIDYw LjU2MiA1MDQuNTAwIDBdPj4KZW5kb2JqCjc5OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDQzNS4wMDAgODUuMDE1IDQ1Ni4wMDBdL0Rl c3RbMzEgMCBSIC9YWVogMC4wMDAgMjQ2Ljc1OCAwXT4+CmVuZG9iago2NTAgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDIyNS43NTggMjUu NDUzIDI0Ni43NThdL0Rlc3RbNzk0IDAgUiAvWFlaIDYwLjU2MiA0NTYuMDAwIDBdPj4KZW5kb2Jq CjgwMCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb NjAuNTYyIDMzOC41MDAgODUuMDE1IDM1OS41MDBdL0Rlc3RbMzEgMCBSIC9YWVogNTg2LjU0NyAy MjkuMjQ4IDBdPj4KZW5kb2JqCjY1MSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNTg2LjU0NyAyMDguMjQ4IDYxMi4wMDAgMjI5LjI0OF0vRGVzdFs3 OTQgMCBSIC9YWVogNjAuNTYyIDM1OS41MDAgMF0+PgplbmRvYmoKODAxIDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMjQyLjAwMCA4NS4w MTUgMjYzLjAwMF0vRGVzdFszNiAwIFIgL1hZWiA1ODYuNTQ3IDQxNy44NDggMF0+PgplbmRvYmoK NjU0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1 ODYuNTQ3IDM5Ni44NDggNjEyLjAwMCA0MTcuODQ4XS9EZXN0Wzc5NCAwIFIgL1hZWiA2MC41NjIg MjYzLjAwMCAwXT4+CmVuZG9iago4MDIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAxNjkuNTAwIDg1LjAxNSAxOTAuNTAwXS9EZXN0WzM2 IDAgUiAvWFlaIDU4Ni41NDcgNzA4Ljc1OCAwXT4+CmVuZG9iago2NTUgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgNjg3Ljc1OCA2MTIu MDAwIDcwOC43NThdL0Rlc3RbNzk0IDAgUiAvWFlaIDYwLjU2MiAxOTAuNTAwIDBdPj4KZW5kb2Jq CjgwNCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb NjAuNTYyIDcwMS4wMDAgODUuMDE1IDcyMi4wMDBdL0Rlc3RbMzYgMCBSIC9YWVogNTg2LjU0NyA2 NzIuMzk4IDBdPj4KZW5kb2JqCjY1NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNTg2LjU0NyA2NTEuMzk4IDYxMi4wMDAgNjcyLjM5OF0vRGVzdFs4 MDMgMCBSIC9YWVogNjAuNTYyIDcyMi4wMDAgMF0+PgplbmRvYmoKODA1IDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgNjA0LjUwMCA4NS4w MTUgNjI1LjUwMF0vRGVzdFszNiAwIFIgL1hZWiAwLjAwMCA0NDAuNTU4IDBdPj4KZW5kb2JqCjY1 NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4w MDAgNDE5LjU1OCAyNS40NTMgNDQwLjU1OF0vRGVzdFs4MDMgMCBSIC9YWVogNjAuNTYyIDYyNS41 MDAgMF0+PgplbmRvYmoKODA2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl clswIDAgMF0vUmVjdFs2MC41NjIgNDQ4LjAwMCA4NS4wMTUgNDY5LjAwMF0vRGVzdFszNiAwIFIg L1hZWiAwLjAwMCAyODQuMDM4IDBdPj4KZW5kb2JqCjY1OCAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgMjYzLjAzOCAyNS40NTMgMjg0LjAz OF0vRGVzdFs4MDMgMCBSIC9YWVogNjAuNTYyIDQ2OS4wMDAgMF0+PgplbmRvYmoKODA3IDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMzAz LjUwMCA4NS4wMTUgMzI0LjUwMF0vRGVzdFszNiAwIFIgL1hZWiAwLjAwMCAyNTkuMDE4IDBdPj4K ZW5kb2JqCjY1OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbMC4wMDAgMjM4LjAxOCAyNS40NTMgMjU5LjAxOF0vRGVzdFs4MDMgMCBSIC9YWVogNjAu NTYyIDMyNC41MDAgMF0+PgplbmRvYmoKODA4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M aW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMjQzLjAwMCA4NS4wMTUgMjY0LjAwMF0vRGVz dFszNiAwIFIgL1hZWiA1ODYuNTQ3IDI1MS41ODggMF0+PgplbmRvYmoKNjYwIDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODYuNTQ3IDIzMC41ODgg NjEyLjAwMCAyNTEuNTg4XS9EZXN0WzgwMyAwIFIgL1hZWiA2MC41NjIgMjY0LjAwMCAwXT4+CmVu ZG9iago4MDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9S ZWN0WzYwLjU2MiAxNzAuNTAwIDg1LjAxNSAxOTEuNTAwXS9EZXN0WzQxIDAgUiAvWFlaIDU4Ni41 NDcgNDI1LjI3OCAwXT4+CmVuZG9iago2NjMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgNDA0LjI3OCA2MTIuMDAwIDQyNS4yNzhdL0Rl c3RbODAzIDAgUiAvWFlaIDYwLjU2MiAxOTEuNTAwIDBdPj4KZW5kb2JqCjgxMSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDcwMS4wMDAg ODUuMDE1IDcyMi4wMDBdL0Rlc3RbNDEgMCBSIC9YWVogMC4wMDAgNzE1LjA1OCAwXT4+CmVuZG9i ago2NjQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzAuMDAwIDY5NC4wNTggMjUuNDUzIDcxNS4wNThdL0Rlc3RbODEwIDAgUiAvWFlaIDYwLjU2MiA3 MjIuMDAwIDBdPj4KZW5kb2JqCjgxMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDY1Mi41MDAgODUuMDE1IDY3My41MDBdL0Rlc3RbNDEg MCBSIC9YWVogNTg2LjU0NyA2MzMuMDE4IDBdPj4KZW5kb2JqCjY2NSAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTg2LjU0NyA2MTIuMDE4IDYxMi4w MDAgNjMzLjAxOF0vRGVzdFs4MTAgMCBSIC9YWVogNjAuNTYyIDY3My41MDAgMF0+PgplbmRvYmoK ODEzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2 MC41NjIgNTQ0LjAwMCA4NS4wMTUgNTY1LjAwMF0vRGVzdFs0MSAwIFIgL1hZWiAwLjAwMCA1NjQu OTQ0IDBdPj4KZW5kb2JqCjY2NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk ZXJbMCAwIDBdL1JlY3RbMC4wMDAgNTQzLjk0NCAyNS40NTMgNTY0Ljk0NF0vRGVzdFs4MTAgMCBS IC9YWVogNjAuNTYyIDU2NS4wMDAgMF0+PgplbmRvYmoKODE0IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMzYzLjUwMCA4NS4wMTUgMzg0 LjUwMF0vRGVzdFs0MSAwIFIgL1hZWiAwLjAwMCA1MzguNTA4IDBdPj4KZW5kb2JqCjY2NyAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNTE3 LjUwOCAyNS40NTMgNTM4LjUwOF0vRGVzdFs4MTAgMCBSIC9YWVogNjAuNTYyIDM4NC41MDAgMF0+ PgplbmRvYmoKODE1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAg MF0vUmVjdFs2MC41NjIgMzI3LjAwMCA4NS4wMTUgMzQ4LjAwMF0vRGVzdFs0MSAwIFIgL1hZWiAw LjAwMCA0MTguNzY4IDBdPj4KZW5kb2JqCjY2OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgMzk3Ljc2OCAyNS40NTMgNDE4Ljc2OF0vRGVz dFs4MTAgMCBSIC9YWVogNjAuNTYyIDM0OC4wMDAgMF0+PgplbmRvYmoKODE2IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMjkwLjUwMCA4 NS4wMTUgMzExLjUwMF0vRGVzdFs0MSAwIFIgL1hZWiAwLjAwMCAzNDkuOTU4IDBdPj4KZW5kb2Jq CjY2OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb MC4wMDAgMzI4Ljk1OCAyNS40NTMgMzQ5Ljk1OF0vRGVzdFs4MTAgMCBSIC9YWVogNjAuNTYyIDMx MS41MDAgMF0+PgplbmRvYmoKODE3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv cmRlclswIDAgMF0vUmVjdFs2MC41NjIgMTk0LjAwMCA4NS4wMTUgMjE1LjAwMF0vRGVzdFs0MSAw IFIgL1hZWiA1ODYuNTQ3IDI3NS4wNTggMF0+PgplbmRvYmoKNjcwIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODYuNTQ3IDI1NC4wNTggNjEyLjAw MCAyNzUuMDU4XS9EZXN0WzgxMCAwIFIgL1hZWiA2MC41NjIgMjE1LjAwMCAwXT4+CmVuZG9iago4 MTkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYw LjU2MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzQxIDAgUiAvWFlaIDAuMDAwIDIyOS42 NjggMF0+PgplbmRvYmoKNjcxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl clswIDAgMF0vUmVjdFswLjAwMCAyMDguNjY4IDI1LjQ1MyAyMjkuNjY4XS9EZXN0WzgxOCAwIFIg L1hZWiA2MC41NjIgNzIyLjAwMCAwXT4+CmVuZG9iago4MjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA0NjAuNTAwIDg1LjAxNSA0ODEu NTAwXS9EZXN0WzQxIDAgUiAvWFlaIDAuMDAwIDIwNi42NDkgMF0+PgplbmRvYmoKNjcyIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAxODUu NjQ5IDMxLjAxNSAyMDYuNjQ5XS9EZXN0WzgxOCAwIFIgL1hZWiA1NS4wMDAgNDgxLjUwMCAwXT4+ CmVuZG9iago4MjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzYwLjU2MiAzNTIuMDAwIDg1LjAxNSAzNzMuMDAwXS9EZXN0WzQ2IDAgUiAvWFlaIDU4 Ni41NDcgNDY5LjkwOCAwXT4+CmVuZG9iago2NzUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgNDQ4LjkwOCA2MTIuMDAwIDQ2OS45MDhd L0Rlc3RbODE4IDAgUiAvWFlaIDYwLjU2MiAzNzMuMDAwIDBdPj4KZW5kb2JqCjgyMyAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDcwMS4w MDAgODUuMDE1IDcyMi4wMDBdL0Rlc3RbNDYgMCBSIC9YWVogMC4wMDAgNTQ2Ljk4OCAwXT4+CmVu ZG9iago2NzYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9S ZWN0WzAuMDAwIDUyNS45ODggMjUuNDUzIDU0Ni45ODhdL0Rlc3RbODIyIDAgUiAvWFlaIDYwLjU2 MiA3MjIuMDAwIDBdPj4KZW5kb2JqCjgyNCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGlu ay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDQ2MC41MDAgODUuMDE1IDQ4MS41MDBdL0Rlc3Rb NDYgMCBSIC9YWVogNTg2LjU0NyA0NDguOTA4IDBdPj4KZW5kb2JqCjY3NyAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTg2LjU0NyA0MjcuOTA4IDYx Mi4wMDAgNDQ4LjkwOF0vRGVzdFs4MjIgMCBSIC9YWVogNjAuNTYyIDQ4MS41MDAgMF0+PgplbmRv YmoKODI1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVj dFs2MC41NjIgNDI0LjAwMCA4NS4wMTUgNDQ1LjAwMF0vRGVzdFs0NiAwIFIgL1hZWiA1ODYuNTQ3 IDQxMC4yODggMF0+PgplbmRvYmoKNjc4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFs1ODYuNTQ3IDM4OS4yODggNjEyLjAwMCA0MTAuMjg4XS9EZXN0 WzgyMiAwIFIgL1hZWiA2MC41NjIgNDQ1LjAwMCAwXT4+CmVuZG9iago4MjYgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAzNzUuNTAwIDg1 LjAxNSAzOTYuNTAwXS9EZXN0WzQ2IDAgUiAvWFlaIDU4Ni41NDcgMzg5LjI4OCAwXT4+CmVuZG9i ago2NzkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzU4Ni41NDcgMzY4LjI4OCA2MTIuMDAwIDM4OS4yODhdL0Rlc3RbODIyIDAgUiAvWFlaIDYwLjU2 MiAzOTYuNTAwIDBdPj4KZW5kb2JqCjgyNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGlu ay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDMyNy4wMDAgODUuMDE1IDM0OC4wMDBdL0Rlc3Rb NDYgMCBSIC9YWVogMC4wMDAgMzM3LjkwOCAwXT4+CmVuZG9iago2ODAgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDMxNi45MDggMjUuNDUz IDMzNy45MDhdL0Rlc3RbODIyIDAgUiAvWFlaIDYwLjU2MiAzNDguMDAwIDBdPj4KZW5kb2JqCjgy OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUu MDAwIDI3OC41MDAgODUuMDE1IDI5OS41MDBdL0Rlc3RbNTEgMCBSIC9YWVogMC4wMDAgNTE2LjUz OSAwXT4+CmVuZG9iago2ODMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVy WzAgMCAwXS9SZWN0WzAuMDAwIDQ5NS41MzkgMzEuMDE1IDUxNi41MzldL0Rlc3RbODIyIDAgUiAv WFlaIDU1LjAwMCAyOTkuNTAwIDBdPj4KZW5kb2JqCjgyOSAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDIwNi4wMDAgODUuMDE1IDIyNy4w MDBdL0Rlc3RbNTEgMCBSIC9YWVogNTgwLjk4NSA2NDIuNTc5IDBdPj4KZW5kb2JqCjY4NCAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTgwLjk4NSA2 MjEuNTc5IDYxMi4wMDAgNjQyLjU3OV0vRGVzdFs4MjIgMCBSIC9YWVogNTUuMDAwIDIyNy4wMDAg MF0+PgplbmRvYmoKODMxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw IDAgMF0vUmVjdFs1NS4wMDAgNzAxLjAwMCA4NS4wMTUgNzIyLjAwMF0vRGVzdFs1MSAwIFIgL1hZ WiA1ODAuOTg1IDUwMi4wOTkgMF0+PgplbmRvYmoKNjg1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODAuOTg1IDQ4MS4wOTkgNjEyLjAwMCA1MDIu MDk5XS9EZXN0WzgzMCAwIFIgL1hZWiA1NS4wMDAgNzIyLjAwMCAwXT4+CmVuZG9iago4MzIgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA1 MjAuNTAwIDg1LjAxNSA1NDEuNTAwXS9EZXN0WzUxIDAgUiAvWFlaIDAuMDAwIDM5OC44OTkgMF0+ PgplbmRvYmoKNjg2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAg MF0vUmVjdFswLjAwMCAzNzcuODk5IDMxLjAxNSAzOTguODk5XS9EZXN0WzgzMCAwIFIgL1hZWiA1 NS4wMDAgNTQxLjUwMCAwXT4+CmVuZG9iago4MzMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA0MTIuMDAwIDg1LjAxNSA0MzMuMDAwXS9E ZXN0WzUxIDAgUiAvWFlaIDAuMDAwIDM3MC4xNzkgMF0+PgplbmRvYmoKNjg3IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAzNDkuMTc5IDMx LjAxNSAzNzAuMTc5XS9EZXN0WzgzMCAwIFIgL1hZWiA1NS4wMDAgNDMzLjAwMCAwXT4+CmVuZG9i ago4MzQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzU1LjczNyAxNTkuNTAwIDg1LjAxNSAxODAuNTAwXS9EZXN0WzU2IDAgUiAvWFlaIDAuMDAwIDI5 OS45NTEgMF0+PgplbmRvYmoKNjkwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv cmRlclswIDAgMF0vUmVjdFswLjAwMCAyNzguOTUxIDMwLjI3NyAyOTkuOTUxXS9EZXN0WzgzMCAw IFIgL1hZWiA1NS43MzcgMTgwLjUwMCAwXT4+CmVuZG9iago4MzYgMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjczNyA3MDEuMDAwIDg1LjAxNSA3 MjIuMDAwXS9EZXN0WzU2IDAgUiAvWFlaIDU4MS43MjMgNjI1LjQ2MSAwXT4+CmVuZG9iago2OTEg MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MS43 MjMgNjA0LjQ2MSA2MTIuMDAwIDYyNS40NjFdL0Rlc3RbODM1IDAgUiAvWFlaIDU1LjczNyA3MjIu MDAwIDBdPj4KZW5kb2JqCjgzNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk ZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDY2NC41MDAgODUuMDE1IDY4NS41MDBdL0Rlc3RbNjYgMCBS IC9YWVogMC4wMDAgMzI3Ljc3OSAwXT4+CmVuZG9iago2OTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDMwNi43NzkgMzEuMDE1IDMyNy43 NzldL0Rlc3RbODM1IDAgUiAvWFlaIDU1LjAwMCA2ODUuNTAwIDBdPj4KZW5kb2JqCjgzOCAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDU5 Mi4wMDAgODUuMDE1IDYxMy4wMDBdL0Rlc3RbNjYgMCBSIC9YWVogNTgwLjk4NSA2NjAuMDg5IDBd Pj4KZW5kb2JqCjY5NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNTgwLjk4NSA2MzkuMDg5IDYxMi4wMDAgNjYwLjA4OV0vRGVzdFs4MzUgMCBSIC9Y WVogNTUuMDAwIDYxMy4wMDAgMF0+PgplbmRvYmoKODM5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgNDM1LjUwMCA4NS4wMTUgNDU2LjUw MF0vRGVzdFs2NiAwIFIgL1hZWiAwLjAwMCA2MTkuNTI5IDBdPj4KZW5kb2JqCjY5NiAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNTk4LjUy OSAzMS4wMTUgNjE5LjUyOV0vRGVzdFs4MzUgMCBSIC9YWVogNTUuMDAwIDQ1Ni41MDAgMF0+Pgpl bmRvYmoKODQwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs1NS4wMDAgMTU5LjAwMCA4NS4wMTUgMTgwLjAwMF0vRGVzdFs2NiAwIFIgL1hZWiA1ODAu OTg1IDMwMS43ODkgMF0+PgplbmRvYmoKNjk3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M aW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODAuOTg1IDI4MC43ODkgNjEyLjAwMCAzMDEuNzg5XS9E ZXN0WzgzNSAwIFIgL1hZWiA1NS4wMDAgMTgwLjAwMCAwXT4+CmVuZG9iago4NDIgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA3MDEuMDAw IDg1LjAxNSA3MjIuMDAwXS9EZXN0WzY2IDAgUiAvWFlaIDAuMDAwIDIwNS41OTkgMF0+PgplbmRv YmoKNjk4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVj dFswLjAwMCAxODQuNTk5IDMxLjAxNSAyMDUuNTk5XS9EZXN0Wzg0MSAwIFIgL1hZWiA1NS4wMDAg NzIyLjAwMCAwXT4+CmVuZG9iago4NDMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA0OTYuNTAwIDg1LjAxNSA1MTcuNTAwXS9EZXN0WzY2 IDAgUiAvWFlaIDAuMDAwIDI5Ny43NTcgMF0+PgplbmRvYmoKNjk5IDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAyNzYuNzU3IDMxLjAxNSAy OTcuNzU3XS9EZXN0Wzg0MSAwIFIgL1hZWiA1NS4wMDAgNTE3LjUwMCAwXT4+CmVuZG9iago4NDQg MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAw MCAzMDQuMDAwIDg1LjAxNSAzMjUuMDAwXS9EZXN0WzcxIDAgUiAvWFlaIDAuMDAwIDIzNS4xNTkg MF0+PgplbmRvYmoKNzAyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw IDAgMF0vUmVjdFswLjAwMCAyMTQuMTU5IDMxLjAxNSAyMzUuMTU5XS9EZXN0Wzg0MSAwIFIgL1hZ WiA1NS4wMDAgMzI1LjAwMCAwXT4+CmVuZG9iago4NDUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAyMzEuNTAwIDg1LjAxNSAyNTIuNTAw XS9EZXN0WzcxIDAgUiAvWFlaIDAuMDAwIDUyNC45MzkgMF0+PgplbmRvYmoKNzAzIDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA1MDMuOTM5 IDMxLjAxNSA1MjQuOTM5XS9EZXN0Wzg0MSAwIFIgL1hZWiA1NS4wMDAgMjUyLjUwMCAwXT4+CmVu ZG9iago4NDYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9S ZWN0WzU1LjAwMCAxNzEuMDAwIDg1LjAxNSAxOTIuMDAwXS9EZXN0WzcxIDAgUiAvWFlaIDAuMDAw IDM4MS43MjkgMF0+PgplbmRvYmoKNzA0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAzNjAuNzI5IDMxLjAxNSAzODEuNzI5XS9EZXN0Wzg0 MSAwIFIgL1hZWiA1NS4wMDAgMTkyLjAwMCAwXT4+CmVuZG9iago4NDcgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAxMzQuNTAwIDg1LjAx NSAxNTUuNTAwXS9EZXN0WzcxIDAgUiAvWFlaIDU4MC45ODUgMzQ3LjQ2OSAwXT4+CmVuZG9iago3 MDUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4 MC45ODUgMzI2LjQ2OSA2MTIuMDAwIDM0Ny40NjldL0Rlc3RbODQxIDAgUiAvWFlaIDU1LjAwMCAx NTUuNTAwIDBdPj4KZW5kb2JqCjg0OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDg2LjAwMCA4NS4wMTUgMTA3LjAwMF0vRGVzdFs3NiAw IFIgL1hZWiAwLjAwMCA1NzEuNjY5IDBdPj4KZW5kb2JqCjcwOCAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNTUwLjY2OSAzMS4wMTUgNTcx LjY2OV0vRGVzdFs4NDEgMCBSIC9YWVogNTUuMDAwIDEwNy4wMDAgMF0+PgplbmRvYmoKODUwIDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAg NzAxLjAwMCA4NS4wMTUgNzIyLjAwMF0vRGVzdFs4MSAwIFIgL1hZWiA1ODAuOTg1IDYzNi42MTkg MF0+PgplbmRvYmoKNzExIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw IDAgMF0vUmVjdFs1ODAuOTg1IDYxNS42MTkgNjEyLjAwMCA2MzYuNjE5XS9EZXN0Wzg0OSAwIFIg L1hZWiA1NS4wMDAgNzIyLjAwMCAwXT4+CmVuZG9iago4NTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA1NjguNTAwIDg1LjAxNSA1ODku NTAwXS9EZXN0WzgxIDAgUiAvWFlaIDAuMDAwIDUyNi4wNjkgMF0+PgplbmRvYmoKNzEyIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA1MDUu MDY5IDMxLjAxNSA1MjYuMDY5XS9EZXN0Wzg0OSAwIFIgL1hZWiA1NS4wMDAgNTg5LjUwMCAwXT4+ CmVuZG9iago4NTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzU1LjAwMCA0MzYuMDAwIDg1LjAxNSA0NTcuMDAwXS9EZXN0WzgxIDAgUiAvWFlaIDAu MDAwIDI4NC4wNjkgMF0+PgplbmRvYmoKNzEzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M aW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAyNjMuMDY5IDMxLjAxNSAyODQuMDY5XS9EZXN0 Wzg0OSAwIFIgL1hZWiA1NS4wMDAgNDU3LjAwMCAwXT4+CmVuZG9iago4NTMgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAzMDMuNTAwIDg1 LjAxNSAzMjQuNTAwXS9EZXN0WzgxIDAgUiAvWFlaIDAuMDAwIDM5MS4wNDkgMF0+PgplbmRvYmoK NzE0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFsw LjAwMCAzNzAuMDQ5IDMxLjAxNSAzOTEuMDQ5XS9EZXN0Wzg0OSAwIFIgL1hZWiA1NS4wMDAgMzI0 LjUwMCAwXT4+CmVuZG9iago4NTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9y ZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAyNjcuMDAwIDg1LjAxNSAyODguMDAwXS9EZXN0WzgxIDAg UiAvWFlaIDAuMDAwIDY4OS41MTkgMF0+PgplbmRvYmoKNzE1IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA2NjguNTE5IDMxLjAxNSA2ODku NTE5XS9EZXN0Wzg0OSAwIFIgL1hZWiA1NS4wMDAgMjg4LjAwMCAwXT4+CmVuZG9iago4NTUgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAy MzAuNTAwIDg1LjAxNSAyNTEuNTAwXS9EZXN0WzgxIDAgUiAvWFlaIDAuMDAwIDY2Ny41MTkgMF0+ PgplbmRvYmoKNzE2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAg MF0vUmVjdFswLjAwMCA2NDYuNTE5IDMxLjAxNSA2NjcuNTE5XS9EZXN0Wzg0OSAwIFIgL1hZWiA1 NS4wMDAgMjUxLjUwMCAwXT4+CmVuZG9iago4NTYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAxOTQuMDAwIDg1LjAxNSAyMTUuMDAwXS9E ZXN0Wzg2IDAgUiAvWFlaIDAuMDAwIDI2OS40MTkgMF0+PgplbmRvYmoKNzE5IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAyNDguNDE5IDMx LjAxNSAyNjkuNDE5XS9EZXN0Wzg0OSAwIFIgL1hZWiA1NS4wMDAgMjE1LjAwMCAwXT4+CmVuZG9i ago4NTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzU1LjAwMCAxNTcuNTAwIDg1LjAxNSAxNzguNTAwXS9EZXN0WzkxIDAgUiAvWFlaIDAuMDAwIDM1 Ni4xNTkgMF0+PgplbmRvYmoKNzIyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv cmRlclswIDAgMF0vUmVjdFswLjAwMCAzMzUuMTU5IDMxLjAxNSAzNTYuMTU5XS9EZXN0Wzg0OSAw IFIgL1hZWiA1NS4wMDAgMTc4LjUwMCAwXT4+CmVuZG9iago4NTggMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAxMjEuMDAwIDg1LjAxNSAx NDIuMDAwXS9EZXN0Wzk2IDAgUiAvWFlaIDAuMDAwIDMxNC42NzkgMF0+PgplbmRvYmoKNzI1IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAy OTMuNjc5IDMxLjAxNSAzMTQuNjc5XS9EZXN0Wzg0OSAwIFIgL1hZWiA1NS4wMDAgMTQyLjAwMCAw XT4+CmVuZG9iago4NjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzU1LjAwMCA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0Wzk2IDAgUiAvWFla IDU4MC45ODUgMTk1LjE0OSAwXT4+CmVuZG9iago3MjYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MC45ODUgMTc0LjE0OSA2MTIuMDAwIDE5NS4x NDldL0Rlc3RbODU5IDAgUiAvWFlaIDU1LjAwMCA3MjIuMDAwIDBdPj4KZW5kb2JqCjg2MSAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDY2 NC41MDAgODUuMDE1IDY4NS41MDBdL0Rlc3RbOTYgMCBSIC9YWVogNTgwLjk4NSA1MzYuMTQ5IDBd Pj4KZW5kb2JqCjcyNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNTgwLjk4NSA1MTUuMTQ5IDYxMi4wMDAgNTM2LjE0OV0vRGVzdFs4NTkgMCBSIC9Y WVogNTUuMDAwIDY4NS41MDAgMF0+PgplbmRvYmoKODYyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgNjI4LjAwMCA4NS4wMTUgNjQ5LjAw MF0vRGVzdFsxMDEgMCBSIC9YWVogNTgwLjk4NSAzNDAuNjY5IDBdPj4KZW5kb2JqCjczMCAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTgwLjk4NSAz MTkuNjY5IDYxMi4wMDAgMzQwLjY2OV0vRGVzdFs4NTkgMCBSIC9YWVogNTUuMDAwIDY0OS4wMDAg MF0+PgplbmRvYmoKODYzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw IDAgMF0vUmVjdFs1NS4wMDAgNTkxLjUwMCA4NS4wMTUgNjEyLjUwMF0vRGVzdFsxMDYgMCBSIC9Y WVogNTgwLjk4NSA0MjEuNTI5IDBdPj4KZW5kb2JqCjczMyAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTgwLjk4NSA0MDAuNTI5IDYxMi4wMDAgNDIx LjUyOV0vRGVzdFs4NTkgMCBSIC9YWVogNTUuMDAwIDYxMi41MDAgMF0+PgplbmRvYmoKODY0IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAg NDU5LjAwMCA4NS4wMTUgNDgwLjAwMF0vRGVzdFsxMDYgMCBSIC9YWVogMC4wMDAgMjQ1LjMxOSAw XT4+CmVuZG9iago3MzQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzAuMDAwIDIyNC4zMTkgMzEuMDE1IDI0NS4zMTldL0Rlc3RbODU5IDAgUiAvWFla IDU1LjAwMCA0ODAuMDAwIDBdPj4KZW5kb2JqCjg2NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDQyMi41MDAgODUuMDE1IDQ0My41MDBd L0Rlc3RbMTA2IDAgUiAvWFlaIDU4MC45ODUgNjE1Ljg3OSAwXT4+CmVuZG9iago3MzUgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MC45ODUgNTk0 Ljg3OSA2MTIuMDAwIDYxNS44NzldL0Rlc3RbODU5IDAgUiAvWFlaIDU1LjAwMCA0NDMuNTAwIDBd Pj4KZW5kb2JqCjg2NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNTUuMDAwIDM4Ni4wMDAgODUuMDE1IDQwNy4wMDBdL0Rlc3RbMTExIDAgUiAvWFla IDU4MC45ODUgNDc5LjQ2OSAwXT4+CmVuZG9iago3MzggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MC45ODUgNDU4LjQ2OSA2MTIuMDAwIDQ3OS40 NjldL0Rlc3RbODU5IDAgUiAvWFlaIDU1LjAwMCA0MDcuMDAwIDBdPj4KZW5kb2JqCjg2NyAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDM0 OS41MDAgODUuMDE1IDM3MC41MDBdL0Rlc3RbMTExIDAgUiAvWFlaIDU4MC45ODUgMjAwLjI2OSAw XT4+CmVuZG9iago3MzkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzU4MC45ODUgMTc5LjI2OSA2MTIuMDAwIDIwMC4yNjldL0Rlc3RbODU5IDAgUiAv WFlaIDU1LjAwMCAzNzAuNTAwIDBdPj4KZW5kb2JqCjg2OCAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDMxMy4wMDAgODUuMDE1IDMzNC4w MDBdL0Rlc3RbMTE2IDAgUiAvWFlaIDU4MC45ODUgNzEwLjY3OSAwXT4+CmVuZG9iago3NDIgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MC45ODUg Njg5LjY3OSA2MTIuMDAwIDcxMC42NzldL0Rlc3RbODU5IDAgUiAvWFlaIDU1LjAwMCAzMzQuMDAw IDBdPj4KZW5kb2JqCjg2OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJb MCAwIDBdL1JlY3RbNTUuMDAwIDE4MC41MDAgODUuMDE1IDIwMS41MDBdL0Rlc3RbMTE2IDAgUiAv WFlaIDU4MC45ODUgNTY0LjMxOSAwXT4+CmVuZG9iago3NDMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MC45ODUgNTQzLjMxOSA2MTIuMDAwIDU2 NC4zMTldL0Rlc3RbODU5IDAgUiAvWFlaIDU1LjAwMCAyMDEuNTAwIDBdPj4KZW5kb2JqCjg3MSAw IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAw IDcwMS4wMDAgODUuMDE1IDcyMi4wMDBdL0Rlc3RbMTE2IDAgUiAvWFlaIDAuMDAwIDI1MS40ODkg MF0+PgplbmRvYmoKNzQ0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw IDAgMF0vUmVjdFswLjAwMCAyMzAuNDg5IDMxLjAxNSAyNTEuNDg5XS9EZXN0Wzg3MCAwIFIgL1hZ WiA1NS4wMDAgNzIyLjAwMCAwXT4+CmVuZG9iago4NzIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA2NjQuNTAwIDg1LjAxNSA2ODUuNTAw XS9EZXN0WzExNiAwIFIgL1hZWiAwLjAwMCAyMDcuNjk5IDBdPj4KZW5kb2JqCjc0NSAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgMTg2LjY5 OSAzMS4wMTUgMjA3LjY5OV0vRGVzdFs4NzAgMCBSIC9YWVogNTUuMDAwIDY4NS41MDAgMF0+Pgpl bmRvYmoKODczIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs1NS4wMDAgNjI4LjAwMCA4NS4wMTUgNjQ5LjAwMF0vRGVzdFsxMjEgMCBSIC9YWVogMC4w MDAgNDQ5LjQ4OSAwXT4+CmVuZG9iago3NDggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDQyOC40ODkgMzEuMDE1IDQ0OS40ODldL0Rlc3Rb ODcwIDAgUiAvWFlaIDU1LjAwMCA2NDkuMDAwIDBdPj4KZW5kb2JqCjg3NCAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDU5MS41MDAgODUu MDE1IDYxMi41MDBdL0Rlc3RbMTI2IDAgUiAvWFlaIDAuMDAwIDMzOS42OTkgMF0+PgplbmRvYmoK NzUxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFsw LjAwMCAzMTguNjk5IDMxLjAxNSAzMzkuNjk5XS9EZXN0Wzg3MCAwIFIgL1hZWiA1NS4wMDAgNjEy LjUwMCAwXT4+CmVuZG9iago4NzUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9y ZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA0NTkuMDAwIDg1LjAxNSA0ODAuMDAwXS9EZXN0WzEyNiAw IFIgL1hZWiA1ODAuOTg1IDYzMS4zNjkgMF0+PgplbmRvYmoKNzUyIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODAuOTg1IDYxMC4zNjkgNjEyLjAw MCA2MzEuMzY5XS9EZXN0Wzg3MCAwIFIgL1hZWiA1NS4wMDAgNDgwLjAwMCAwXT4+CmVuZG9iago4 NzYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1 LjAwMCA0MjIuNTAwIDg1LjAxNSA0NDMuNTAwXS9EZXN0WzEyNiAwIFIgL1hZWiA1ODAuOTg1IDU3 Ni4zNjkgMF0+PgplbmRvYmoKNzUzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv cmRlclswIDAgMF0vUmVjdFs1ODAuOTg1IDU1NS4zNjkgNjEyLjAwMCA1NzYuMzY5XS9EZXN0Wzg3 MCAwIFIgL1hZWiA1NS4wMDAgNDQzLjUwMCAwXT4+CmVuZG9iago4NzcgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAzODYuMDAwIDg1LjAx NSA0MDcuMDAwXS9EZXN0WzEzMSAwIFIgL1hZWiA1ODAuOTg1IDU5MS45ODkgMF0+PgplbmRvYmoK NzU2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1 ODAuOTg1IDU3MC45ODkgNjEyLjAwMCA1OTEuOTg5XS9EZXN0Wzg3MCAwIFIgL1hZWiA1NS4wMDAg NDA3LjAwMCAwXT4+CmVuZG9iago4NzggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAzNDkuNTAwIDg1LjAxNSAzNzAuNTAwXS9EZXN0WzEz MSAwIFIgL1hZWiAwLjAwMCAxODUuNDg5IDBdPj4KZW5kb2JqCjc1NyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgMTY0LjQ4OSAzMS4wMTUg MTg1LjQ4OV0vRGVzdFs4NzAgMCBSIC9YWVogNTUuMDAwIDM3MC41MDAgMF0+PgplbmRvYmoKODc5 IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4w MDAgMzAxLjAwMCA4NS4wMTUgMzIyLjAwMF0vRGVzdFsxMzYgMCBSIC9YWVogMC4wMDAgNzAzLjk1 OSAwXT4+CmVuZG9iago3NjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVy WzAgMCAwXS9SZWN0WzAuMDAwIDY4Mi45NTkgMzEuMDE1IDcwMy45NTldL0Rlc3RbODcwIDAgUiAv WFlaIDU1LjAwMCAzMjIuMDAwIDBdPj4KZW5kb2JqCjg4MCAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDIyOC41MDAgODUuMDE1IDI0OS41 MDBdL0Rlc3RbMTM2IDAgUiAvWFlaIDAuMDAwIDY4Mi45NTkgMF0+PgplbmRvYmoKNzYxIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA2NjEu OTU5IDMxLjAxNSA2ODIuOTU5XS9EZXN0Wzg3MCAwIFIgL1hZWiA1NS4wMDAgMjQ5LjUwMCAwXT4+ CmVuZG9iago4ODEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzU1LjAwMCAxODAuMDAwIDg1LjAxNSAyMDEuMDAwXS9EZXN0WzEzNiAwIFIgL1hZWiAw LjAwMCA0MzMuMzY5IDBdPj4KZW5kb2JqCjc2MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNDEyLjM2OSAzMS4wMTUgNDMzLjM2OV0vRGVz dFs4NzAgMCBSIC9YWVogNTUuMDAwIDIwMS4wMDAgMF0+PgplbmRvYmoKODgyIDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgMTQzLjUwMCA4 NS4wMTUgMTY0LjUwMF0vRGVzdFsxNDEgMCBSIC9YWVogNTgwLjk4NSA2MTYuMzc5IDBdPj4KZW5k b2JqCjc2NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1Jl Y3RbNTgwLjk4NSA1OTUuMzc5IDYxMi4wMDAgNjE2LjM3OV0vRGVzdFs4NzAgMCBSIC9YWVogNTUu MDAwIDE2NC41MDAgMF0+PgplbmRvYmoKODg0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M aW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgNzAxLjAwMCA4NS4wMTUgNzIyLjAwMF0vRGVz dFsxNTEgMCBSIC9YWVogNTgwLjk4NSAzNDMuMDU5IDBdPj4KZW5kb2JqCjc2OCAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTgwLjk4NSAzMjIuMDU5 IDYxMi4wMDAgMzQzLjA1OV0vRGVzdFs4ODMgMCBSIC9YWVogNTUuMDAwIDcyMi4wMDAgMF0+Pgpl bmRvYmoKODg1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs1NS4wMDAgNTY4LjUwMCA4NS4wMTUgNTg5LjUwMF0vRGVzdFsxNjYgMCBSIC9YWVogMC4w MDAgNTEyLjQ2OSAwXT4+CmVuZG9iago3NzEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDQ5MS40NjkgMzEuMDE1IDUxMi40NjldL0Rlc3Rb ODgzIDAgUiAvWFlaIDU1LjAwMCA1ODkuNTAwIDBdPj4KZW5kb2JqCjg4NiAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDQ4NC4wMDAgODUu MDE1IDUwNS4wMDBdL0Rlc3RbMTgxIDAgUiAvWFlaIDU4MC45ODUgMzE5LjM3OSAwXT4+CmVuZG9i ago3NzQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzU4MC45ODUgMjk4LjM3OSA2MTIuMDAwIDMxOS4zNzldL0Rlc3RbODgzIDAgUiAvWFlaIDU1LjAw MCA1MDUuMDAwIDBdPj4KZW5kb2JqCjg4NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGlu ay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDM1MS41MDAgODUuMDE1IDM3Mi41MDBdL0Rlc3Rb MTgxIDAgUiAvWFlaIDAuMDAwIDI1NS42ODkgMF0+PgplbmRvYmoKNzc1IDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAyMzQuNjg5IDMxLjAx NSAyNTUuNjg5XS9EZXN0Wzg4MyAwIFIgL1hZWiA1NS4wMDAgMzcyLjUwMCAwXT4+CmVuZG9iago4 ODggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1 LjAwMCAyMDcuMDAwIDg1LjAxNSAyMjguMDAwXS9EZXN0WzE4NiAwIFIgL1hZWiAwLjAwMCA0OTIu NTY5IDBdPj4KZW5kb2JqCjc3OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk ZXJbMCAwIDBdL1JlY3RbMC4wMDAgNDcxLjU2OSAzMS4wMTUgNDkyLjU2OV0vRGVzdFs4ODMgMCBS IC9YWVogNTUuMDAwIDIyOC4wMDAgMF0+PgplbmRvYmoKODg5IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgMTM0LjUwMCA4NS4wMTUgMTU1 LjUwMF0vRGVzdFsxODYgMCBSIC9YWVogMC4wMDAgNDcxLjU2OSAwXT4+CmVuZG9iago3NzkgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDQ1 MC41NjkgMzEuMDE1IDQ3MS41NjldL0Rlc3RbODgzIDAgUiAvWFlaIDU1LjAwMCAxNTUuNTAwIDBd Pj4KZW5kb2JqCjg5MCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jh c2VGb250IC9QVllTUUQrSGVsdmV0aWNhIC9Gb250RGVzY3JpcHRvciA4OTQgMCBSIC9FbmNvZGlu ZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMjMgL1dpZHRocyBb CjI3OCAyNzggMzU1IDU1NiAwIDAgMCAxOTEgMzMzIDMzMyAzODkgMCAyNzggMzMzIDI3OCAyNzgg NTU2IDU1NiA1NTYgNTU2IDU1Ngo1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNTg0IDU4NCA1 ODQgNTU2IDAgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4CjcyMiAyNzggMCA2NjcgNTU2IDgz MyA3MjIgNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgMCAwIDAKMCAw IDU1NiAwIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgz MyA1NTYgNTU2IDU1Ngo1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgNTAwIDUwMCBdID4+CmVuZG9iago4OTEgMCBvYmoKPDwg L1R5cGUgL0V4dEdTdGF0ZSAvQk0gL05vcm1hbCA+PgplbmRvYmoKODkyIDAgb2JqCjw8IC9UeXBl IC9FeHRHU3RhdGUgL0JNIC9NdWx0aXBseSA+PgplbmRvYmoKODkzIDAgb2JqCjw8IC9UeXBlIC9G b250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0dPSVZJQitIZWx2ZXRpY2EgL0ZvbnRE ZXNjcmlwdG9yIDg5NiAwIFIgL1RvVW5pY29kZSA4OTcgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RD aGFyIDMzIC9XaWR0aHMgWyAyNzggXSA+PgplbmRvYmoKODk0IDAgb2JqCjw8IC9UeXBlIC9Gb250 RGVzY3JpcHRvciAvRm9udE5hbWUgL1BWWVNRRCtIZWx2ZXRpY2EgL0ZsYWdzIDMyIC9Gb250QkJv eCBbLTk1MSAtNDgxIDE0NDUgMTEyMl0KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA3NzAgL0Rlc2Nl bnQgLTIzMCAvQ2FwSGVpZ2h0IDcxNyAvU3RlbVYgMCAvWEhlaWdodAo1MjMgL0F2Z1dpZHRoIC00 NDEgL01heFdpZHRoIDE1MDAgL0ZvbnRGaWxlMiA4OTUgMCBSID4+CmVuZG9iago4OTUgMCBvYmoK PDwgL0xlbmd0aDEgMjM1MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDE1OTk1Pj5zdHJl YW0KeAG9fHl8FEX6d1Xfc2buK3NkMpkjCSQkIRcEMkJCwimHSoKA3JcihxAOxUXlFvFAjgU88EDE gwBRgog/VnEBdRW8xWPXFV3c3ay7+6KrwHTeb/UEhOy+++4f+/nNzNNd1d1TXfXUU089z7eebkIJ ISaylPBk6Kjxs6eQa6pvxJHPCJEaJs4cP/vqGb/PI0TuTgi1TWyal3XPt70fJkSpJ4S/acrsqTPP CJveI8TQQog+MPWmRVOcF6aMI8T5PiG9/zxt8vhJ7fftChJyzWGUWTYNB/TZ8nTkf0Q+Z9rMeQtH Phi4m5Br/Si/5qZZE8dfXTbmUUKuG4fzT8wcv3C28oKhiJCRAvJZN4+fOXns4lvvQD4H+ezZs26Z J3+g7EEe9SFHZs+dPPvlu27G9Q1G1O8dwtqmfegglN8AmgZaCFoF2gzaCWoFHQN9DDoD+pEQTgF5 QAlQBage1ACaBloIWgXaDNoJagUdA30MOgP6EfdWQB5QAlQBqgc1gKaBFoJWgTaDdoJaQcdAH4PO gH4kRFBAHlACVAGqBzWApoEWglaBNoN2glpBx0Afg86AfiREVEAeUAJUAaoHNYCmgRaCVoE2g3aC WkHHQB+DzoB+RN8rIA8oAaoA1bd3fBg7L6UpyeqUD3fKZ3fKRzrl453yuN8V5ed2ykMWrzjfpVO+ a6d8Qad8Yad8t055yM4V5Rd3ypd0ymNcXHF9aad8Wad8eac8eHvF/ys75Xt0yvfslK/qlO/VKd+7 U766U/6qTvk+nfJ9O+VrOuVrO+X7dcrXdcrXd8r375Qf2CmPcXsFfwZ3yg/plL+6U35op/zwTvkR nfLXdMpf2yl/Xaf8yE75hk75xk75Gzrlx3fKT+iUn9gpP6lTfnKn/JRO+amd8tM65aGLr+DvjE55 NhdcPt5v6pSf2Sl/c6f8rE752Z3yczrl53bK39IpP69Tfn6nfFOn/IJO+YWd8os65RdfmT9PO+U5 lseHdswtRiSl9KF/t6Ucz2YwUZIVotMbjCZzhsVqszucLrfH68v0k0AwlBXOjuRESSyeyM3LJ126 FhR2KyrW9A3pTkrLyisqe/Ss6tW7OnlVn741tf3q6vsPGDhosDYA/t2t/wvnrtZG0b8vSDxMLOIh khCXEp9QSEKQmk9Ap9hevbb9G/Eosagz2//GMw12gBGnVleRw+QespXsJhLZiXSCjCWbyXE6gxyg o0kL+ZAGSQFZSgTSSgaRt2h7+0kyhTyB6+eRV8kGsocY8Z+ZxImz62i0fTHySaQnkGXtj5EcUkFW kEOkEqWuI23tT7fvw9nh5FqyizyD/79JI9wewd7+fPtpopBhKHMZzpxsH9S+m9hIF9KHDMXRZeQV GuVPtU8jHtITtdtGHiHbya/In+mdtKV9WntT+4n2LwmHs34yAt8ltIV+ye8WVrRva/9juwpOJEge 7jqOrCePo/zd+B6G+NTSG+k8up5u4JLcnVyLsFx0qynwIZfU4VtPZpFV4MABcoT8nfxEv+M8vIWf x7/eXtr+f4iBDEQrWUsmkyZ8V+K7Dm06SCXajfalQ+kS+iDdQN/j8rhruQZuAbeQ+4Yfwo/mF/Hv CbcIe8W14mbJoH7ffrD9aPsHxE0C5Hoyl9yO1r1KTpCz5BzlUZafRmlP2oeOxXcp3codoNvpAW4o PUxPcLvob+lX9Dt6nhM5I+fk8rl53HruGe5V7m1+Or+B/yX/W/57obfIidvFr6Wo/Kk6QV2tvt3e s/3L9h9hbSokjJ7pQ4aQG8h4tHY2pPwXaMVz+O5Grx0hr5Pj2vcr6idt5EdwATYo9dFiOhjfIfRq OoVOpw/Tl/B9RavLDxw6gtNxVs7N+bkR3ARuJreU+4BbymfyefwAfhS/G99j/If8ef68IAp2wSnU Cf3JWmGmsAXfHcJOYa/wjlgp9haHiNeJS8XV4lp+onhS/FC6XVon7ZW+k/4qJ+RB8ix5LXrnOGT2 V1eMC4HmoPbF5GYykdbQCWQjemM7HU/WQLom0VXg12ySaB/D387Xcd0gDa+QWyGtW8gSspofTba3 f8zvIh9BUpieXUqeEvqQgLgJvXMn6QYp6vgmc/NyE/FYNCeSHc4KBQP+TJ/X43Y5HXab1WIyGvQ6 RZZEgeco6VIb6Tcuqzk2rlmIRerru7J8ZDwOjL/swLjmLBzqd+U1zVnsf+Nx6oork7hySqcrk+kr k5eupJasKlLVtUtWbSSr+Tc1kaxWOmpYA9L31EQas5rbtPRgLX2fljYhHQ7jD1m1nmk1Wc10XFZt c7+maWtqx9V07UIPJMEOfdcuTHEkiYEV3Ez6jl8yzYMdu6K22RepqW32RpDGOT5aO35S89BhDbU1 meFwI47h0PAG3KNrl+nNqCe52zgpMunu1iSZMI6lxo9uaObHNzZz41hZ1vxmd6Sm2b34a8/P2Yup 2rWXnWzmov3GT17Trzk57m4wl2XHsdz4tcgNHJGFYrnljQ3NdHlHJVgdZ6CmrLqTI7WsXuNmZDXr In0i09bMGAfmkuENe31JX21kfE1jMxnasNeb9GqZrl0OeG7vGUbrD3S9qutVbN8z7Lk9vf/DXenj 7x5me8/tR36H/cDhlxhA2Z0i/VHP5qyJ2k0iqGwF20yuIGsmVoBP+DRSNHM66tO3mYPM8NFmMdp/ fPPSERerMa0mXblxM2r26rw+1oZxfRpx/bg1lh7oKVxviWSt+Z6gCyNtf77yyPiOI1LU8j1hJ1lH X5KVZjr+YrpJYwxaPc0Tmcb6t0nrU+QjntrLDiDPWMPq3OxoLh44tCHcnNWIA60kv8vAVqIb2rCH 0nWNrbR9eSupCRwgOsLfMBanuzBRm16D+yPTtQsO5IWRKuiS1Q+t7sdkJWtN1pr+k9Zk9cuaBmES otoeJyavaSwEB0c0gE/kGtwx2Zh5KTm5sbEHyilk5eAvuHxNI0qY0VEC9tqhwhQu6tZlIHolNrRh WEPz0prM5mRNI3oB4nt4aEPzYUhuYyOuKrpUU9R4yXRPR52LUeeiPJwvSZcyAmWgiMY1a1iZIxoi 4ebDa9ZkrmHjLZ1vpaTzgWTHgVbCLkHDa1vp0qH4L3aRcCY7EAlHwqhWI+Npd4j0RYlqJaX/nsNl l+qNf5ajtmUahyv+Sxyu/E843OM/4nDPSzW9gsNVqHNPxuFe/3sc7n0Fh6v/PYeTl+qNSl6F2iY1 Dvf5L3G473/C4Zr/iMO1l2p6BYf7oc61jMN1/3scrr+Cw/3/PYcHXKo3KjkQtR2gcXjQf4nDg/8T Dg/5jzh89aWaXsHhoajz1YzDw/73ODz8Cg6P+PccvuZSvVHJa1HbazQOX/df4vDI/4TDDf8Rhxsv 1fQKDo9CnRsZh6+/xOFkZjO5XA8v7aR2yX9dMY++jOWwlGAE9wEOeAL+GE9k0reVjMhvJUphKxFA iqWVkBMglkea/wxp7GXseex1n5GX8C+AsPkvoSQR+25FJdawNQ7qI6xrvfB78dC5vq3C4PP7tHu1 wQduxb1EzK7dk5m489VyHrxct9snCzyNSsSrN0wKL7zNk58/5OzgI6nKyiNDaifXfEMGV6e+qS7q Zi+x8hHeWuKMtL1ZNKX70aPiITWQWsbdduGHE6jBcH4ON7ajLdGkg5MeEnhCcnkhV/YqOjV8sD5d cNuHKVJdlaoq6kZRHPtyY4OLQtsDi0LioVQLN4gRysNHmIPyMuGbfZ/cKSuy2+2Je0YaFwQls9Vm M/GZmQIlVq/E8WYvDGmTV1IEk0fWCSan3iiYHIYM3uwwWIjVYbBn2hwGV6bNqXdn2jyyL9PmlfzE 6tQHeLNTH+TNHjlErB7ZZjWj1pIpU/J6/TaPR9Y7nX6bw2HwepwOg16WFFMm2xEzX24SHsq0knJb 5mIPO6s3fZAZrsuyNB3xVH2NFlZVWc6imZYUNixHrTZ35cqC/CWW11cWeNhOO5LR6bPSUoUf484Y e4k9Ul5iL+E1kiN8CShi1yiKXfDbsWdCZxZsWPT5resXIXXDt6FvkPotjpzhmm74fDRXRBvm0cNq ktE8dec8tS89xGgebVB3AhvZxs+hw7U+iyXt3EM8ESEN6DOvIP7qUoel0lJQPbgt3WV0eHheON1V ECmyTh3LjRc/IA7SO6lzWHV2F8rQHaTb4Ds66LakOUmWCoMsXqfrH+Gbhnta5eLlmoC1+T73tb3f 1lE45ItysmS1uF32SAGNx+KxUkt5mZ0b+1Bh3bDi9Yse6Jdb4TKM6XlQ/EB9575P1S/VL/76oPrH 07ff9ODOkVfTxB/W0yhEhpIa1MeN+thJWdKoWIndifoIgzLsrEqE6FAlneJ1OP8Rrr61QyLfb/v8 snrYbeVlVks8xpcEqTtInRZZ4useKejHarHlqli33LE9X1LH0rJ1H9EwDf/1Qer64ZbJS87OUT8+ s0H9QqvDEIyFI+CrmexLTlkpbRK4kcIC4ajCm4zGcpvBoDcaIM+SUm7T6fSKTgbgJJXbRFGQRA4g FC23CQJvhIMomAyQbA7jkzmMcBVlszBYNhNZsqBV/CZqNm0yeDOqMbaGWM4OTlV9frG3qr2DLX+2 uis1IWOiJzCpUyB2yr9OCDjFpI6Moc5yt+yW43K8PF7uLqWvnkqcWjnxrmVTVn+W+Fg89NtBs+pe rnvtNWxmDflSa+8u9QRdSk6hvV2TLhIx6ycpelZBubt+ElG8GRMnp+tXlbrI58Ho+qJu7rLystLu sXiktMTpkORdtf4Mys38cFzTSeO1XfNkg3zqjQUtTtwC/Xot/YIbyG2CrsxK6kkhT30igZy20j77 wi9puuW05RtSyKTUHnaGr6U/qHpuE8OwKHx9otWPJ5BzmsfrmZzTSez/k8KsckzjXeQcK6EcWm73 yZOnAIyx/+PDzdDGSX7SLVM33QTgheP8Np4nHK+nUFe8t9DzPoZ9dZWoDfIjdAwtoRH67ma1YDPT xEzfJ9s/EfziZpIBFGpO0r1SpP0UZ2mG6C+VTbYKfpanwhCsCzAV8n5bqo1Ut1WjLn0XJbuTTFOM Rn0xXVSMucyeBEabLUEzFaQsElJuozNB7Rw2Xr0/QawCNvn4ULbRPneQMcTtslpkLpwVj1m7l9vC tjJrdy6SzVkdblcJn7xt3Mjb1d+r6u3Tq5to6ZodC597ZH1h/fPi5q/3qG+pn/2P+pffHaQ9z+6m /c59/SMdfpb2VD9QP/90+ZtpHh1BAz8QH8Coj+xRaCstSRoFQTYK8kaR6Ot0rFFHPkhVkurqs79B F5X2puUl1oj1yGtbYusO8z+ssTfuOHcz/4PG7yR0f1B8iGSTHckhZUI/YaR4Y+Dm4OLgMrqSU/KU Ud4bvbd5b/O/4BVJNs0Q/GZvWPZ7MR2IoYyMbLu+1C5mheaHs43hX8gVrlnZ5njGHaGK7Jy6SJq5 Z9ss37ed1uah6jarrbIQAwQjpdJWWWnFhozR2O4XvMaoNWawmRNE55DBXMFk0Seo4sQG/LVYNP6C tWW2apqW5Ug2RnME6XCxzemQpQwq4QAEcsDyXx2+o/vwjUsO1MWE/Xyf+TTxw1eL+r2wekLFJB9v vpB7gNpmzxpYOuLGJevXDlx+sOmE+sPjzy6umzyorGjkjF0aX4ogPz5xCykiR5Kh/sYRXSfnTuw6 P3d+V2ljjA5U8vWefIeJ/6nIUWoCmBNJOqylll+YTEWZpTmiXFpk8myM11hb6YBkhr6iYBYXys26 g49zJXXFl3Gl7Wxa8MCUs6lvLG0Wxh/GG40lZYXdvDGiE2OBaHZMInyCCLzSDezwR0IJ4ot6ElSg MthViE0wnAmexbC5JIyWKiaNd9wBntExAlda4oLsFTMlEMmW5NIgLSnWVEKajd0ZG4GYgYNQxA4S oa6vXzYm+u1f9+wL221Ruz/mmnzV3M2TW2pj4t7kzdT56V/ruvSb8wv17z/GqfvY3dVzNi98sInS R3guq+K+G+ct7LP40dnHXjuwbHhJILRn6W9UlckuB0wTNpe4DSkTGZ3M1nF6xYTx/YpNkmROoqKs AGeV9dx8g/gdb4S51ErdL9CNJuVZfStt2Cdm1Jk1Dn6PGR9SVc0mfmulxjUwjs36TLtmQL1addQa LqUlzIyyck+qpfTt1Fruvs3vvQeIdnVqgSrSsc38ugs3PKQ+xupGSZ/2z6AzlpIscjCZX29bFeIq jf3sI+1T7UIPxWiSiVGfYTbPt9ntNnNGls0uE7tb7y5FxbKTPtMvzOaArUeGIJRmHQ2YrHKFbxap yMquC6d7/Pu2I9AybdUp9Pbpsxd7mg2DtKVC0l2PvvdADSU8IarjYnwQYDkloSzRjzGh82BDQ1gD lzKxUbzpscFUj6WKdTfr6zGwCi7r5zjT0DwGSUmx4HRw4eyceMq2JHnNo1v2Lx2zvHDbTO5M6pFe xV2HTn+d2s6rbbvV/2OhM7f0DL5128Yn6pM6nn9enRuzh9XX3lTfeP0trQ8Ht38qRMSHYS/GydPJ ygU+6laiStzb4F1BVtJVOrlO0Yfj4VKz2cEflUszxXgpxkoud0ewwjrLreeq9DlF7ty6hMaYVOVt A4cvXFzogZroGA9tYBFjUFohR2P+rAwXkcRYVkYwQWPOnATx25FiY4IKfMgSTtCoK54gARs2bExo uoKmBwAbAXewuZa4nBHYOtDCP7Mjkk2sFk0/p4eF0wH1XHdoryVy1bJNe/W9x143o4Ua1T8dVz+7 agkddMc9t++Yt/uRe8SHf1p2bbdR6rfqheu7Jr45/Zr6Hi0C9G54iU469/n/3Hnz0S1bV6XnQ6zf Qt6XYh4akSwTDV6uwtDDWGkaYLqWu06YwO2X9beZWkyvm3hOR03mHiRD0Bk5k0LILLNSoXvWbK2z aGyCGv2aCThEHhIPsaFQnLAfJJhyTA3a7GXl4VKhsPbrhpFdAwVHa86s3nThjLj0ob5qy+GDWyZ+ RrfQjX957gWEU0DOP4Ju24ZVEzeQ+TeTddfRkbpRGY32SXSy7saM6fYFUV1/y63epsjc6C3x24pu K17lXZm1Mr6qYFXRZq+pTilWomYuWmwotVq7iKVB0V3axcRVACRbsd9ckTurUKnIRPoFR0Vh97qS tPhr08DP+q4tPWQ7+rg0r8CfZXPxJldXR4IY880JqrcpEPMANkKIS1BngTtBTHnYyH4xQfksbC5p Ok3Lpfu4Q72xfrRdliawcbtjCKQVHAYIhkIkOwfHyrknViy96855G6esenLX8jse37BNfSHv6jMf vP3HmtjQxpIb1DMn1d/etphPLh89dMWKUZPnpnquXHH3fevvnP0492j+0KWPfvPJ/StGFHbNLZ30 6CH1p68+/sUBhExwpH/7x4IV8wcbI88kC7xivphw1UsN4jRxtXeVb7NP10+Rw/F4qV7vCZdaRKE0 86jHJHNVcrDI0UqvTRpMJDfzjpwK08WBgtFh+T5VuSQ9WjRdcuVACcW8PoOd8rYoF8vOwCjJsmKU 8F6okJgB2YgZAyVkx4b6oD6iRowWNkV0WC7pcULT2sNuphgopd1tJVl2F+xyKI5YKbmMo9Si3Fhe e8eLsao9U97521/O0MoFfa6+Sz367imueM8jty7bumoDHbWhMvgR7X/DYMq9+RpNqN9s/Vb96U31 +c920Ng9zQ9v3fPg2icZr76C8m0RwppvXpz0iXkyn0cwCehgOop0kkDg1f7sLkP8L3oygzFlMm8Z Ch701Ul8hPCp1HrNlkS5sJVbUW4GPJTKZIBEMmAt2/MskqJnnorc3aafZIEadTBPnBn1VSj7otkM J8zyz5Yzhpp2q36ZZkpnfhDqfucHH5w0Dc0rFmXjqTdurG9yi8Nwd0r87W3Cc+CyRGYkkyP5qfxK GLBZsGI5LsuGdTsJaYEXsuCKSLwkwKoVRUolUc8TKnAibG4FMIGsrArf8IJmNFdZfnBXQQOQXtXV zMkoFAZ7VlryLSvzscWPORR26tRRJ/UL91+o4V8+P4sbS99oUTepG1vom+DzaPKFMIsv0/gcTzpp FvmNnCUJxKeTObB4dLh6+MVbVTHzPpVCoU7MoSBh1vk2wX6+jS/buVMd8cwzV7bxpmSfBtLAT+NX YVkfLeN41j5eYO2Do4UWU9LRSooGU9ZKifgUKog8d3kr3Wgma2Uv6LmOVq60eK5spY6W4keF587P 4g9eqBXupy+q5S10Bp3eoiK8iMOaLRHc4gnmv5BtybqErd7eYJ9smm8SpxsXGbmYkmExOTMMOo/T ZjIIWZaRzE/JeiMzR6K2jCJLiE7ieV2Wp0Lnyw4VZXnD2e+FJ16EVIZYfhismbFtZ5mFzSb0b9K+ n2bR2rQ5y+cNCkog6hdDVxGf7LmKBoXMq6hXwQYjjo23tFUWhdQSm6aWJNlMnZHuZVcat7Tt6FF1 99kPXm8buWxc5d6aW4bmuBLzVz6VzBH3njghHKfyl7tnLFs65o7b79095+rs6FX9Jtx3W+2daDli DMVe8KM4ooeeP5UcWk8b6DSKDtokbNY/rW/VteqlBPwpWZIop+h02OiJLNK1FFLp0OujcJipQxSj sMyowSDyOj18ZmrgKByxoKy00sakDkuqkk7Pi8jtTNpMJjZgH6YP671G0/bw2rGQJu+Qs57BqZRX G7L9ajyk2g3HDe4zM9uqmbGr8a2yULOCBmLlRzic2SwcaUwjN+wAjwP8kcb8jmsZZiN34DbMhTZQ O7w/PsxHKL/ut23Lv+ScpzakDj7yFncfN4oZevzEc31pq1qveZWbwBcBKT1iJBLkzmTFKNMo6wxu hmmGdTG3ICz3N9VbuYASyhBCdvAwrgTdnCEYV4SizOkZRRFfns4ZTbi8uXmt9IZ94aYp6QGD9miC wSa4VDVTy6mfDXmbxycq3qgUkz1CPhV9Sj6kIC0EdMwYqlnhsEvC1suSfDiLTVJQN9pkJUu5lDty e7+b5/e5U32IPrd/SNG9g5ao81/jFsCLT16dO3hOxcTG5eoXqfX80Ej5vfcV+9XK1KgZfW94tEco dV60b7l+wd2NhfH8snFPr7vlWUjFqPZT4hzxaxKApOxJ9swUN9GNIh+CdXknXSmutosjFH5FwGp1 Sj0CvLGHUxfkgkEvX8T1tBRZfVm6Iq83lLU9PCPNgMFtHc1HyzFy4UwjwXQzTNkexO+O2mPmaGbM 4NIVE5PDUkxt1gyL7EdOJHwxpYBd9B5jMcmwYaP4pGK4Nthos1PatE1v2YE74M4o1A3oSrPeMHzK y8pLYARp3jaQrHBECNLu1lfDr+/9RP3+b999dkuv4Ku+B3arH7WT579+9iValxC/Vk8dXLdDfUd9 XVXV/3m68f4zDx3a+hv6LK098XvNxsXEJE6EnJgQxzI1GVpp3WjjihVDMIMjQbeiFNl9PlPU7PX6 Pgw3rdaEAKgG0w1MAKA30fAYdVmjzpgki7Ig8zIni5LeoqC1Lmx0NkMxlR2wvzSFkMfaFWUtYb6t hYM0aCJgdcgcuv7E5KvmDejpy/jkb+ojx7gRtPCpDQ1b1RWp3buc8VmNd4+oo1ZacH6zaP/oVfXk Hw+pe7U2AIsR2tAGA6KAhiRz5KAgGPggIBSdEtQbFCNnNHJEms711PnMvBIlXpO5lRr2hTdcbJAm 1GdPY+CxXsWQra7SZDuN+1jhWTCiu4XCC+v5/Asf8Ledf5UDttyi9tmlmnfj1vhomJCwCxkdZmEP q4WuoxbSjdRn0O6sN7TSkbjzZx2s1O7M/Lt/umFkN3/+wlvcyVQhUHHcaHdqEtP5E9s/YXE1wDEi 5GSyd6a0gi7n+AANiSvoav+LWWJSyRCcLt4y03W7i8twWU3CimyLNWi32Zxyj2zeqZh6+HQRLgKw 19ZKByYtvFDE97RE7b6ovijozYm20qn7wjNmpyvYIe8pzWVPi7wm8+CRdqhyTIdq0yShS2aYGP3R LABLxkw9JDyMjUSEYiCQomAImIqJLiQXU5HDhtlk8F06vBfMFJB34EkMq00LfLg4xx4uDVsjcQh9 hEFMTOjj/DebPi16Pef3z76lfvsNFY5SkVe7c8uXdps85K431PMv/+bYK7QgLH419Bb1d9vXq2+r J9Vz6v4/UO7JC385NCt/wNPv07l0zqkTnNZn2yH/hZrsVCfDii4Iu0WgnF5WBDkqiT4T1UcNxGs0 mh4NNzGeWIacZVodQ4DtNHSushDcYOYZlkkY/oQabz/OXTh+PCUcB6i9nbvhXF9ud2qYdr/jEJQH cD+euBGrgIUWisMF+YhzY8syHEL/UE7k+HH8EwAf8HTUb4hWv5eSiyUxKsaVerlBXiCu4jfzrQhp +oNs2MHvgCklJpRc3U7dT5yIgaiIOv59jtkgiiLrOC7B81EgwDqJTXQ4JAoIFWKRQrKkU0RO0AMP Rqsl5UbpVukMLLVLLTdh4LMJLt1u7xDLN2MwuVWxBQgN4XJXKisHF+SLQCPYVCZYmN3+ukWpUsAT MnfOGDoHyw5WGtYB25atkW2vcm9Re+ohbp6aSql/ehUc6s69lWq+sJ778ksGnmhtFgaizSIpStqB hnJBQVR4n0y5KABaSW6lIzAl/Vwp1Ak1Qnekl5QwVLcd5c5cGAYW/n03ysNcKLlRnh0+YGMNHYjJ nOp4F/XyH1HRTv28w5BpHEkb+Pfpp/z7hk+NevDDVMut4IRh3CaOy9UnTBX6ClMdN5Jr4uToJJOe 421gmMFo4yVFWw1gsPHWpEkf4g1Syki5lCmE4bX1RTvxOpjgwOxGDU97z1ZW4uc5zURIWwrT7ARw cuDwRXtMxla6qwV4PVMTu/ZyHL9SHFywOCUsObJSTO/B0zFz59C5Y+bYGUchbt3LSgEKwxN0WiOb aIDuoI9T3yFBHfO6Okp8RTx0PiacOteXn9j1xILzucJHXcs+737hIfBZsx/FPPBFByuhKekopxXw sgFFx2kdbYAYAa9ijXJrmBUDrDgFLgWv11NJQa/g3Aui4DMyG2lrUq8jXoOxY5RcMUiYPZNWrNVV SGLVIH/lEiwMMLwOJg0bMxS/bX/ivjn021TGK1wPVHqUsONcX+HJ89ejfsyXH9r+gXgGei8Dnqaf rEl2WYnA0qP0Ne6Yclwv9VWcPTL4zB6yzs/5/QZbEe8LeooM3kDw405T96WJW1NYxcTHUPAODLyY YeDF8Eg8xQwDL2YYeDHDwIuBgWcWAwPHRpur2YZ9gENdDoEziIXYSi2EKTCHLcwLWw8+8NQRdYP6 3KvPPfgKwj4z/6T+7U+n1d/9gzrN4tfnXlNPqPtPtZPffUwH0Lz3qeXcY3TR91gJqFKPqu+cVfeI Y9FPbH77EXzQo37jk6XTjdNti4yLbUK9o8ExzbHYIchK0Gqx6Kk5g816eoWTbEZB53AUCT5Xhg4T ntP1Lya8FHM80vOdBWyBEtOwFruGj0qYmSOAE7ALA0zdzW048tcPv1CLj/JLF/a5RZ1H1654Sjz0 +bFn21PrhQM9Qio/9z4mUy3QVws1mYqTB5M22dSf1ouNtEGcLk5yLBQV10EEqnpJJvUn+0TCWbFx tjm2+Q7eFgw5/E4+HHQ5hJgtJxokOl2mHDRwMX+mkhV1hqIuvihjeqYvV4lF43pvIvfD8IYrjdKz 8GLfh1kC1cSwRzSnssNhYZb3GEih5jtSBg1r7eLDxcz2ZEBwiMEBbiemnkLKsDO0na9b+/jcXlNU 31Fu586Z78yccN1IUeYNtoKzWAk2ypMqF6s9j/L+2Q88VBnEstD2orGpZTtLInOXvn5Nbj9H2F51 3ff3FWWm1oAn49o/EH6A7BYillNNjs3NiEdisTJzabguNiG22LwgR3ej4jG7o1yjeZp5VzavN/fI zsnW84Lfs8JRWJjv7+HghR75um6c3qxYc7JDiW7drJ6ou78STfiKQ1FrfxIt9BYVPxqe0WHRAEP5 2VC1ATdmdJnBynq+IFUyZo42CgYnCqwhonAxLtY1KmFNiO9C8knXAm0n5sGOD9hD+STT6cmnXg/t KuQTXdyQT6MGWoC0nItN0ObHSRc22gixWLTJnY2Rnyd4htBrsAvD4+MxjdWl3XMYYptGLCUn1o20 vnA6BDbjl1MalLtPPDd79N6Bgx47+tqwtQBv/0D7Hswouv5U85ZRPU+8vWHYWvWhP6l/2bqV5wbT U0uGPJDV+9GFJcXRrl1KR+//tfrb75uqb3lwwk3FWd0Ks3tOPXL23bV3/0UwsHkmjHGFeRYxD92T PioFicwJCgNjyHmOj4rCecmrMOeOQSYMfz97EY9hc40GGbDZvlQ4rlrfUK3iod3n/i6aMVjZONgF O43ZFU7iIlXJiFuMixUWXk84sYdF5+JdLocuavR5aNThdXseDW+4wt66qKSqgH1SbS2NOU9QlNpa Gx/zYiqdV9X4Xur6ojf6r1DXqmuX9+f6iocuzHt0xqPPjX2EX3vhqPq3B9QfqP4BmsFXoq1YjxDL UB+J3JusuY8+SrkkvYZyLkoXit9QbqowTVwl8N4EF2V4BmHesAg7jZfgBYuCooArAsc/LBL6sOSV 14ErMAWYy1tZiV/a7WV2AaYzYLbMImDWACa1JCZDgCJYSKOcJK7EcvERbcNwHDJmzpy5Oo4talIL Jq7tv02deS/1LdR/QPjqHBrEeElJFM8hsrgNI70uuUHR0YXyIt1Cw0q6QhDr6ECuhq8XBit99KuV lfpj3FFA8ccMxgbDVHmaYTW3gl8hrzb8ktvIb5C3GJ7mdvBPyrsMGTCB9IrBq7j0I2XJoAh6rnei NiFGsToDwNBo0AmUN8BolYwiAWBg4GXFzKA0UVqRVHjhrJ7TnV1qIHSF0Wu6ghm+NEPY7hJTgASA K1gOBFvaVha0gSstOizFY0FlSzIDmBEHeEiQZJ2CpXt2TM8W63GYGA0rl1gUZliJ2kL7SkWzstKZ gcMW7QPehHl4y4soTkAhWoE6LPJr5TGWowTFclgji7g45VGOAE1DYolyBD0wd8yYObAn7Dpagh+N 6NATKSBrgz6mg6jzlHr7SfU59ZmT6lJ0ybXCM4wwK796vjd6gyIqnYjdkTKQl5OzE7SMg4HEjxSm 8lOFJm6hsgodZIgbyrlysUKZJkKYgKkwK1RUZEQoQMRgneqQjNr0Br0WpRC14ZFSTlQMaL4ssUB2 oC5E0QO8Y0fR97LOZ+IpcJdWatwXZqxn0MtgzxHLEO8P2KXnNIa9VAFfS/M8HxxgS+jaznLZLm2D hNFs1nzWeOr7K2dW7T/RBXRem2rnxH+o87i/wT59mytOdU9lcKMxtlm769BuPNKD0ZS3SqCOhIBx w/EYN+g2UeEUGfAShg5ax+t0AmExUbyASNykTuI4UYpSBWYseQERUhfFByqm0oNJq1ehBVaipmow Z3mY06UNqsoCxAH8PK72I4iDV9DDAkTkiLZhQ8qudST0kj3vDEbUjm9THxydAhu7N/fqhfWpZm4o z57cgtPRToRb2ifDssp4gfYDdwk8MVIIKMNaGnbiFJk8mdldw7FWyJ6UyMAzMFXk82RFXjeqt8Be 9sdL6i3TdTMscqViM+r4zGI5RxewGAM987mC3J77e3I9i/OiNossKv54ttvfStdADQZCcjxQYOAC pYYquarK75Bz83bm+Hpn5voHZMQrvL16v0w3QTEfoBtJhweanspOp45c1IpAXeCds85lk3pBW0Eb 80Ex12uTWaKs3JlNqDdKyzLCxBOES+rKcoRpOJuUc2HiC7jDwHmx6fA/NTMuDVPmYD2xvKwXNVNt id15xfp7b6wjw1ywYsWlGLdg6wYIKWI7tuRSbqfmuUNuaNwYnlY8c0LRCNrS22m8a/E9PcP6neI/ Hj/UNN8dNQateV1iY/JcuvK3b9tw6KVNa94Z1aX/jvudfsls8hdOpTcpXTxdR48YlDfi11vr6zen NvmzeX65UeoTSdbPeGHVhifs9DSbW5ravxCi4qvECkxrdrJgh/yU/yM/n61kBNGNxB0QZas+GDAY HHHFl+UrsBTQXAS1hbJWhg+NuejJnT7dgeK0MRjLihgFjXsem0vSuyRHjNr02Dhld4zadcEYmAWU irEJvhxjhc3KVpbAAWck59JyCRZkm3b3fGLcsZ9+OLX4muLKHdyU+++/59YDsbpXxVdTfxo8TG1T z6pqc8/I4NVLzrzy9Bcvntw0do82X+LpIP6EMIT4YN8/lSx8yks3e3Yquzz8AMW61cHzDingk00B eGpyZqbbErdRhBlYfQF93O31B1qpvC88d0mHxGjOOVbeGIZzmdGjNbA7FlmiRqc+Rsx2C1rJ8Dkv csDnwho+Z3CZYsDnsNF5pBjD58L/Ap9jpgxWWtPonAy7RZOKEiYOHOz/Epn78Cv3bsvc258d0G3V A7Pv8u4O/vXgu+eo7X2/MKT5o4l37Zz56PbPVi/44HVa8g0ebeqBaYZUtJ/i29CvBhIgC5LF5eY6 80jzU8LTmWJUcXAZAazhBAKyXc8F3AaxwF5gybXafCFDHDB8aGV4bp/Lm586DVTpyr71efw6PaHU Y0Db/NgQLxcj+kwlhgZqvYtW2VhDOhaJ4dq4mXdWyppF2CLZDw9sX7J9x+JVT9M1I7r1eu6x6mdn 7VPPffcFveHMR8fffO3EG1x59+BALnCu94aJDbTruT/SkdAh9e2nBB90iB9P5kWpMblok/JL31Mh XjRzGaLDabZlOB1JY9Kh5ProQMOL/FH6a/5o5sfKJ7oPQx9HzrjPRAxHrUdt3GhFDOdkbHEFciol WXaFA35ZH3AZovIm/1P+/RgDQtSVgdUIr94oWxGfE4iLvnhOgRz3emPx98M70sIPL1wT/fdT6ZUM BswXjrkkJ7DzNGRLk5Z+JIKpFI+yUQTShQBA2Sx2i8MiSMZodmZOjGSRQIwGAzq3HCMGpzmGpe2I L4xDIjaKB3KF6B4wmikZbZ1eM4bz8vPuACpC5oxhIsSA73A6SqUcAgQoXNLwL1KiuSKIYaFcy4cV ZTbLhe/E+zbdc003xx756qLhi64afkz9I/X8noYMiQHP3bZTpBGh7sZrh9004LHHXx9TVtfz/oKh fgsmNSx80D5qbH6/O/etoZ+lbSo/FIlbfBcr44OT+XJAQtgqzXBUukySTe/FZGU2WXPdNtmWYQ6Z OfMFh9fjvRCeentaxFJjKo8wB8tyuUFcra0i2lgEBlypAoiM5GQrlviWlpS+EKlusea4/V7D8Ky9 LXs3bBD7dB/NcU9w9Nrn112YxG9btxMV40kvtSd/BrISIl3xBOj+5OAyR3+lv65BadStMj6duTPw dHxH/oFMA6wwV3au+Yg+G1OKIOUGvHpbQJ9RIBcUiH6+wFXQNVf0dTOa46besbjfW9jtsgFytq2S SUDq9PeYNzo0BLRgGtDU+r1LJOELGqw5UUssEozFSMKHjdVgxhqr2WiKBrJjNJ6ZCz1hhMPfMZH8 HIahgQLu0hKA2hLWk+PpiKTyMm22yLFCPRCEZ3RoDRj2lLttbEnpjqrZ6vHn/mzeb4r3uuudZIwv 27zkefU8lV+iNU/84pV+0fW3vXp1F/Wk0Kd3pO/KC8VvNZ3a+mR9vOqB6z4fPvQfAH5MtEDdfnjv DVteOLR74jKuqzbPLwNTmU5xIS6jC0aNgjhMJS7E7fPl+YpiN3F2BENaA5LsNOpNuXp4JM5c4oJP 0kqlfeEJaZ3C/J2O6aJKmy0qKYto0CYDLeSGTYxAouA5o9OtkWUtyZKRd347ouuBYNHK2S+2QPl/ Nixc+Xjjw6lh3ONN5Q1bPkwdY3LI4SlbQnvClmLx6mVJv/y1AONE4rU1cchtrsyzVfFdP9fkSKqq I4gcoLkWQcwAU7ZYvWw/PkLe+Q/FQ1r8TvspdSit0Mq2MnB1BNBWZvpch5h4yuLeT6Tj33UngL6a cYG18CXUg8W/dyuiEFramzKnC72IST5OK1pa1McWFbXEqptNgZDQduKn7kJktPDi+fL5PSbA9tMK Xwp+M6zGgFlsUiNHeyjUixhbyS2NFKeKi6SF8krxAH+cP4WI0TQ4y3PLuAcxEHiuEkuRAtaRBWmm DT2lAbRiGp+F54iwOAkIrR7QLKLJcokBRvDe8IQD1JW2lFgnVTF8tgOe1daVKawkZjTC7fqVFq47 BkDt4Q50FjPYHBj/AGc12xfg7NLn6NvfqFPonm/UvZueg0P5DD2qzkpN4PxrVPaEPyWrsWHrrTzJ TUJyOuJeuVxEqwriZd0EgUnDm2lMNrK6pSUdsooy0OdSVKgjMbI82RNRy2Ypw624ze6MuBKH2q73 XmeYajBGonpfIOLVc4I7Gg64Aya4ZlKmP8rb9QkoKGsuwkfoXl8uJn+axLxWEMWA9MYTrdR0ueCe tpzFEnZHZeAXAChuw8L2xeDMtBQ7O6TYfdHKgzB3yPJlUr032b1xztIhXXKqHpv88ZC8gzcOnvHL /b7c2VOeahEKN1+d06s6p991I7Zdsy5Vzp25cei6Han7uYMziwc+/A6Tdk3W+TboNi+snLHJov3S UYkTJIcUdzRJ82TRYeQcHgusN7yBxaD3yT4fMebqfH5a4Mn1Em8mTOgrhmR6GktrMLSrjYUHpocl cwOclzWFjUvMK1h5B8667JlBu6adHtplf6Db7cncARVdM1voU6j/2OGPjHyMjc8JVZNMrj6lc6an 3kFl0dM9ESMahm1mxBqhl9yXLNmsbLT80vWksFPZYXna1aocUz4SvjZ/6zD2UKSARzYGbAav7PU6 uXiGL1MXd+JNB61UBwutYwZOg1OXdG9a5RK3EDPYdZgtrVyMym6kRBNSeocxhvGKjeKCQcabsdHm U7ZhCGyOTQP0oHlYNBQC3RDEQ9JG2O+Wdxv00pMbNz6OFwpcUP/xuXqB2v4gzaMZOzaOffDC3mdO 86fUP8MkTanP0/wLMPyTzA5rUq8Vomi6Gats85JdnlaecnMJJctvNUsBp5whmQN+Q7aZi3t8OXpY 1+Hc7AxvJOdfWteaCcbif7U2+l2ZRPTFhBjJRMNEFzbUa44R3q21SWsWs7GZRZ3uMwaIldCStHzi IW+mimB0WyPcr5+K9nvpYG0UW7Vgd1ny+ltfVPfP27JoeLeeLYvee3fp6D0HJ225beQOfs+6/okq hPCl1Mc23lAa7J/6nMlilXotZLEObcwii5MlFZ56T4NnJ31K3OmXEorNzRsCWbJd4gM+g8ssw9h0 5TodPkQ9BxAnctlcqtnamrHZ0dSOlmaGjCbC0RiXifYZQ9gQPw9zKGjosDZZvCLMTRbDmYYD2dTB LE7MmxGrZnHC3Cr5MV679+W6eH7/1vlP0XuvLy545oWujyx4Rv176ji9fexTzeM33T3mkTff53r3 zem34RwQzPprqRFvC6B0wEV9xT2AdlrJ1clYnI+Zyvk6QTArFs6ss+qMcYUNN6te8dkps6eJ12Zv pbVQIGlTh63ZaMtL1YOrj6SALqTj+Tq0Bhtil2wda2T1M84nbhQ9AUumZdUDUAkHyrZy/Cs8t3tu ajPjOeIR+ReFgbBrCmlB8t4K3WZxo+2Xjs3OzXlSIicaLwv3C9fl1MWvyxkZn5IzNbbIuMi0yNwU mZczLzovtiO4s4udh5kpdhUK7MTnzHT7Pc6ujoJEhmE6UPGyKBfNNumFfLvn1/6AXRYCBVvyDYWy zmzhZFIYLvSFPC5P3N07EZPjCV+RORS39CbxAm+3or2XbGMW7aPZRpUWpFhzKwuZc51Gj5nnzVRn GjYeRLtyMSfg4rA5FCa6mBymQIzDBHFtYRqw4VimwxOmWRnZYRLONpuUuD5MY1GdHghymEi52ASt /jBDjdPeeDq6V1sS1obCxQHO1ok03Phy2Bhmptsl/zNunJ6rv1OiNTsnbe4Vv+Xe1VfN+/TA32/s y+0SY71/OWV6bWLIglf7TP/ki++OynQ/HTqq28iR19fmwKvIzut/x+aX142a1qu4bkiyX57XHijs UvvgvSc+eZT7CfOWu/07TieOghYc/oKpQH/YjGcSqpNRwVXp5iWz3upjIA+VconT7MzgQ8CDLrgQ OQG7ucMz7WQ3F7LJCJF4ltRpbfmYWctsvF/EF2KlzHTe+eIzz8ScRaagI9Q3fvuo++8XR6kfrE/V VtgNlFunU+6Yyr2+HrLOkaXtX/FfQG+5UcOxyR6tjmMOTmdXHF6715GQFvAfwaggolmPp9H0InS0 R/Z44O4W6HONBp+P5rLKvnvR0tJCXZj4X7KRq7GgcnF+uQKVjpRrPgtiT61RWuHrdtfLNdGWXVyk +9T1X4/oysImUpXDu4/bOeohznz+5MO98q755fDV3Mc+Zk8AiOf/KBQS2HrJgj70dYCeU8k0bho/ VVoprBKfIjs5BW9F4WqFAeIKYbV4VDgmKv0TtyTYqiOmFM0lAaDa2j67BU5aFjC2u/bz/Ewb8EQs yd6VDEqwpnAnEXAi7UC0YWLpGaLN7+ZeoswCXbaP7sbzeVoM1+9+1xHF9TOcjWbbKmWYUZYhpwfL 6V0+4NdklMvV4PLcy+Dyi4Uj1mc34PJL5f4roFyULfn4AbiDO4glXQ2EpZ/RIM1/Xb3psDofESeb +WnnT4JDFO+mIeJ2pIw0K3l7nbBLh+6n/eT+hpX8GmW5/g3uCP9r+bjya/1xg2GKPEOZrJ9uaJIX KU36RYbl8hqDnl3L1fELyEKRH5lwJeD1Cz1pT+Feeq8gXQ55Y5kXkLe+A/LeCsT7CBDvIwC8twLw ZjyHoXkJ/e+0BnAR7h7DOGQUwRs83ZhrA6oupkM4L8O/707aGWIKrFdkF17CwO9OmhkGbjCi2dpf 00sKliVHPEBy00+daQkGfl46wgDQOXPmwKrN5EoyGaBtgPv70dsn33j30xb1+MFT7x1U3wRLW/hB Fw7wdedP8r0uvAaGdsjhl0gaSCnzFDriMXh4BRJIB88AIUQwTWyVL+GtRBdTSkeKRW1kUjcQZAYi B7/94adP1U100TfqD6p6mi4SCtWVdJGYOp/6lD6g3sxhQYONV6faX/N1mVX1RvLmNc5Vnqc8PPMV Kmz1tgbbVHkBv0Be69hMNombnZtcm9w7yU6XpZ4MdNa5jzuFGvHXIrdS3EF2sHnbLeYkRI/T7YL/ 5DQaMgKKmRlhrkwIOpNDt9Oz23ivC7bY++lRw3Dz054rOi9tkmFRpxjPnjEInc13bBHH5sRClmum DQ/MInyXDSgPAHXWHWynYA/OF3Wbw9Z0aImEuBJOU8Ta4zdl5XgyC73B8+Gjsbsm9Nm2dFssN1iY ZykutIi9zeq8t7AAKxROVe9X//y8OqVFUp4wSWGP8mCOMATifyfjFdav+BboNhargCjccqmejCQN dKQEbUGnSgtEHUa4lMtGOotPAGhDuUp4TIj7rMSyil4We8s+Iz+ABSnsvWSIaia0Fn4F4F174EAL Z9KiNLUYBTqmnCIGyUlZ/Fd37tZUC987tZpbc2EpfWcdT7avT2FE9oeNDDyFX6jhKezp4vHJssyv veRnXCUAYCVk1YfRF5nBXE/on+CVrPC74akdCN6laeJDYCwdngtb0MBcwUCW6jZa1O3/hbNE8dyj DAvqn/AWzt6Czz+jLqG33jp6/kNNHlkb5qENrDUNySIOuIDFFTBRv1Tp1UlE1AdRfZJLfV5/rk6y Shm+kI/zXZARZvGvKn/R6ULVL9YcFQ/DV6dpTEh7UiENFclSAFZuhJ/X0pL6DujQ+ls9cS/AokHe jLTjCIDolQW38MJ2jnbxVi5fx8as9vnrbz758w0ZVd8TKx4mweet+7stvbgHAtATK4dfI6+7eD3b S7lqLoEa/XHyhTbD/ZfOsL+xzzDRRvpwlRC7StLGfUSGC3gbHV1JtnG7yDpQDR8gQ3BuF9LXYr+b XYtrkqAjHfsi7LuD+oAGgwZ2pPvj2q8YCc8SP2i0tr+FbBOvI0HQJoS1jAI9ifRu4SuyW6okE5Hf jv8cx7FtKGebtEu7bhvODWXX4XwL9uNwfRjpXUh3l+8hUezzGOE/rH6sHU0CIT2xrwDVo0w/9r1A y+hRRkBq8f4ppFfjHsvYcRC7vglUhfauxnnGGzfyS5E24H42tgc5Qd1BfkbgYxm+U/B+tiSdQHfR P3OTuI1cC/c+9yM/hV8reIQjok3cIVVJK+QK+W35nFKh3KnsUn7QLUT81SqDx7DY8Irhr8bNxhPG M6YJpjVml/km8x8zkhlvWDZajliN1hm2Mtteu8OesP/dMdrxhXOAy+EaByShwb3CfdjTzTPc87Y3 z/uYz+Fb5Xs78/lM1d/g/0tgW+DD4E3Bl0PBUJPW88PIRkj8jcCfOGLBdwxWm8/oA9DyTMLYrJuW NAnnyNDrGkcMq8mvn3xT0+R50yeOxxUsjhAfrKVhwexffFjcH4/SRMwVLEbdiFjbDJRlRcl2RPSw CAFmsTFUgMU2sUjlEMmCIZ3N8HKgJHFEcOdi1REvB2S+A6JIihBPW0LwoAopJxV4m1oPbXWuD6kh taSf9ha5/mSA9q64wXjP2tXa++yG4x111+DNcdcxxUkaySi8+W00WnuY/Cr9noj+wMWqQaWg/Pyr PJCDHeQ+0KMgnkynd5NFoNWgX4KES6mnkTtA794rKMmX6CLiw9OgBiF0jcMb8ugNoXcBW7Q8HPrE 89VBBP6YyJfUu9dEdFfp6aP0ETKJhOiTWBVYjDffJeiWfbk3hcbh1NNkNmgpiNe2lD69N1gceoV2 IVGEEoRojAQF+mLoD0VdQ18XtXJ0b+jVeKuA3a+CyCUzQocDD4f+JzA19AromfSpXbm44sXQ04Gb QuuDWCrfG3qAgUd7Q/end/MD+OuLoZm5G0OTirTzgza2cs/sDVXi/HVJQ6isIhwqDZwOFcZbFYp8 18CgUF7Rb0I5+CMuy0Kh0aQ15A+sD/XAqWCgNt4DdBDSv5Xk0a17owNCLyGJ5u7rn1uxsZXeuq8+ UYSQ28XJsvrExtz6eDR3UCia2y8eR/q6Y/Iy+Xr5KrlYzsfL5+BgyZmyQ7EpFsWsGBW9AoiwlT67 tzokHaTPkGqw5Zl9CNGD3fs8DgoH6XPawef2KwKWpIniaG3/HQK0KAF09kwLxJkSJF6UtJTUSp/D ez3YoeeSIQxhireEsK0FEo4wA4gxBgJHFQ6i1UzvaZXIcldTtafa1tta2a/m/7UZp525uNVcun+9 8dBA88aBeBvVrkAjXumFRHug8eKlWHf4/3zmzccFk/vks5iTfU2zZ0zRXlEWqZ08LlI7rvnuJrwy bumErKw9M2azE+zdWOMmTJzG9uMnN8+OTK5pnhGpydrTpP2v0+kp7HRTpGYPmVJ7TcOeKcnJNXub kk21Ebyqbd+EPnPHXHGv1ZfuNbfPv7hXH1bYXHavCdr/Ot1rDDs9gd1rDLvXGHavCckJ2r0YC2qn j+hzyzxIJ15jhteIJUY09x82qgFv62usaaU72LvN5pP/Cyy0A8QKZW5kc3RyZWFtCmVuZG9iago4 OTYgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvR09JVklCK0hlbHZl dGljYSAvRmxhZ3MgNCAvRm9udEJCb3ggWy05NTEgLTQ4MSAxNDQ1IDExMjJdCi9JdGFsaWNBbmds ZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50IC0yMzAgL0NhcEhlaWdodCA3MTcgL1N0ZW1WIDAgL1hI ZWlnaHQKNTIzIC9BdmdXaWR0aCAtNDQxIC9NYXhXaWR0aCAxNTAwIC9Gb250RmlsZTIgODk4IDAg UiA+PgplbmRvYmoKODk3IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjI+ PnN0cmVhbQp4AV2QvW7EIBCEe55iy0txAl+NkKKLTnKRH8XJA2BYW0jxgta48NsHiHORUmzBzHww rLz2Tz2FDPKNoxswwxTIM65xY4cw4hxIdBfwweXj1DS32CRkgYd9zbj0NEXQWgDI94KsmXc4Pfo4 4kPVXtkjB5rh9HkdmjJsKX3hgpRBCWPA41Sue7bpxS4IsqHn3hc/5P1cqL/Ex54QSqNCdD+VXPS4 JuuQLc0otFJG325GIPl/1gGM05G8dEbXUUr5lv91Klq/eK/kNubSpu2hFa0FAuF9VSmm+mCbb30K cEQKZW5kc3RyZWFtCmVuZG9iago4OTggMCBvYmoKPDwgL0xlbmd0aDEgNTA1MiAvRmlsdGVyIC9G bGF0ZURlY29kZS9MZW5ndGggMjczMz4+c3RyZWFtCngBvVh7cFTVGf/OvXcfeSAJBtkkLHfXy+Yd ISiUV8my7IaEBAgE0l0E3U2ycRMT2cGYAg50R8HK8hgtJSo4KG21QorcbBh6QyqNDI469YE62mqd UeqzHRn7kI4Vze3v3CQrYZTJH4z3zNnzvc53fud3vt3cE2JENI5iJFLtmlC0mRgVwPIuekFjeyhK VppHxCTotsbODsfuvy84CH0ykdjWHL2t/VPpoTeIpPuJUu23tW1q9vWsqSS65inEt0XCoaZv6rv7 icZnQZ8VgSH1eksO9BroUyPtHRst1eSBHoVubVvfGKJZaDR+I3Rze2hj1BpOK4Meg+64I9QeXral Fb7xj0O/Prr+zg69hcLQz0DPi24IR/9w7x08/jPgexV7GXkyIEzWhx9uvFSGyoZj08lM6dCd3GIa oAzTM1RgilGONI1kzHob/R0+Dq7WPzY9TxmD7fq/RDBEfbwLg+XzaYB20wE6hkxPQS6gW+hhepG1 Uh9bS8fpLTaFbgDfEmlUQy8xXX+Nmuk3iO+g07SPerB+AbXTRHj3MJe+GbobcgNt039FU2k23UfP 0Bxk3UPn9cN6L7wraTUdoW7M/xNThB7pWv1p/UOc3Ark3AbPa3qNfowmUAm4roV1G51iLvEdPUI2 nO7D9Cg9RofoWfqM3cOO6xG9Uz+rnyMB3slUh7aFHWfnxGPSffqj+j/0QTBRQEVYNUh76dfIfwxt AIT52O2sg+1l+wS3cI9wXNpumjT4DXgopMVolbSe7gcDfXSG/k3/Y58LNjFD7BCf02fq/6E0qsYu +U7C1In2c7Q92FM/M7PpbBGrZVvYL9k+9oZQJKwW/MJPhY3Cx+Iyca24SXxDulNKmHaZHjanDV7Q +/Xn9TdpEtnpZtpAW7G703SWvqCvmIhck5mLzWMedgtajB0Q+tgh1ifUsgF2VjjC3mMfsM/ZRcEk pAsThWKhQ9grdAunhVfEFnGf+Ij4nnhBWmASTIdMH5ldlr8ONgzuGHxFn6ef07/EN8iKupkDjpfR rRTCbqN0E/0MuziKdgyndoaeoxeN9gG+QefpS7BAbALLYTPYUrRlbDlrZi3sIDuJdsrA8l8BByGk CJnCJGGyUCc0CO1CTHhTiIm5YpG4RFwjHkN7QXxLvChelEzStdJEabFURbukdmk/2pPSU1JCetU0 x7TAtMxUb4qZdph2iY2m10xvmbea95gT5s/N/7QUWGos6y27cDovomafRS1/+0hsKtDPoDuokXlZ A3XhNA6xEMVRXU3sfvAVpQJ9nbhVXCxMRzWcortRrftpC+0Q19Ih/S/iEfozKqUNKWP0W8lDdtND OJ17aDqqaLi5C4sKC/LzXFOV650OeYp9cm5Otm3SdROzrp2QmTEuPS01xWoxmyRRYFTiUyqCDjUv qEp5SmVlKdeVEAyhSwxB1QFTxegY1cHnheAaFelGZPNlke6hSHcykmU45tP80hKHT3GoL3sVh8bW rPBD3u1VAg71vCEvNeQHDHkcZKcTExw+W8TrUFnQ4VMrOiNxX9BbWsL63KAjtbSE/3C4KY0nVmlR aEvEhoFH+NQcxetTsxXI8IkuX6hJrV3h93lznc4AbDCt9GON0pIWFThpZ3qT0rRTc1NDkEuhtX5V DAVUIchzZRarkxSvOmnzR7Zv1RHJt+sSpyq4KkLheIXqDu4EuVwNci20C1p1nQNphe0Bv8q2D4Pg GFuBlMMNKz6OK9jqUFMUjxKJtwZBLq30J3LcOT4l5A2oVOtPZLuzDaW0pM+2dZ4Tu+8rXVi6kI/z nLatQ+Mn9w7ZXx/go23rmfcxVq9MEsD4SkoVcKqORmMRBWBn84/wbIo3zgZPeAIM22wBnkWqgJoR XarJVRVSY3UjMCLeIXDBVm8iJTuH7yHoCSA+GM+Yi5NCfIbiiF8gHKFy/rPRltCwxezKuEDcyQ86 WSsqC43InQYx2HXEpkT4+XYaZwpdsfkuMUDn1HDMapY6o7rW71QdARg0Ki6p1iil1t/D2J6AxvTt GnntfZRC4q23wF3CS63Fi/WhlJbAUOSEdEOJowK7ruC14og74lVNcUeFI4JiklzGCEc4HpgGBuv8 4IlWYUV3IDcphgOBucgzjefBFITHA8jQOpwBo2Ga9g2CppdU41Tyav0r/GrMm6u6vQGcAsp3oNav DqByAwFElSWRAvGWFtsw5hnAXFYE/41DWeqQAykC8TjPWedXnOpAPJ4b59+3IV1jdLnBPWzQiIdg 4z6NxWoxF4PizOUGxak4ASvAOb0JJT1SURrNvDLDs5K4MfNHQDvLYHj2VWJ4zlgYnjsmhuclkY5i eD4wz+MM//iHY3jBKIbLr8ywO4kbIBcCrdtg2HOVGF40Foa9Y2LYl0Q6iuEKYPZxhhf/cAxXjmK4 6soML0niBshqoF1iMFxzlRheOhaGl42J4eVJpKMYrgXm5ZzhFT8cwytHMVx3ZYZXJXED5GqgXWUw XH+VGP7JWBj2j4nhQBLpKIbXAHOAM3xzkmF3rkqX/g7HLvvZpav+w7z2EsrxpoSXYA/umWdxHxPJ Qos0qivWyDpNIwndmqERnUXnOmTxXcgYLRhFjCnv0knMIqovPolMJozTy27MdGbmo3ukPdrXfzM9 89UiTVp6sRdRw/fGJ6q/aLh1/PwLlGnlCOilB6fHkuMIGsLf35F7JkZz4WAhUTr7Mvz1+bQHkx4+ jT+CaQJ5hDmGbNx0jQiBuoDqdiAUKANtHZHl01Q77og8M8PNbWgFM3y0eHlVfZWnuDLc1hnuaGkM 8axGPtLD/C78Hc+wf4izKvBWjj4Tvbh4oY1i7El6AP1xdJFa2E7ahL4D/RF0KSkdhtbHdiYkq/sk 20Q5bIk7TZJXZWXLttQ0+XWNmY8flN+2fdDPsvEfhXMsOzGOUhamssfZY9REMnuCXGwzboEFbH9v YZschOswRdFj6KLxydjhxJQZ8ilWQi6JYU4eTZHYCfmTslL5ozJNYAn5dL4mYXh2CjT3eHnAflD+ o/02+RR695DrSCEiTsiH7W3y3ika25+Qf2HXGOY8ODTcZcfUE3J7YZfcVGb4a7o0oTshz4G/3p0m z5rtlGfaP5Sn5WtWBr3UXiMXlb0sT8VEhDmQ1OXOlCfb98pz4Zpi9+XPRe9nR9gBKmIHEq4l8kmI 2G5vVeHsLo3d3VtZUObS2Gb3rMqCrsLKfFdhjewqrMjPh1z/gmWb5WbLQssMSzEuYnkWpyXXkmWd YM2wXmNNt6ZarVaLxn6XKJfN/aybykFLd6/VbDVp7GkYpX521DAe/b1VsgpWsmZp+vvHed1kaaz7 OEqGEYQTZkMya+woapybjrpl/F+H4RvDPzNQJcwoJRSbwKwCLcEb727NTNuv6yy3lU9YkDmnwvt9 H0HDM/JZ/P2PjdnVLrxzqUfsAbzeQtDtgZFw24jwvWPHXXCFPcXF1Ss39XZGW5uN13XFFw7irV3d 2YnrU6zB4ehpjQ7fRfKCDY0R/r4YCqtRJexVWxWvo6fTmMfNl7ibubtT8fZQs2+Vv6fZHfYmOt2d Pn5t6W3wbFg3aq0dybU2eL5jLQ9PtoGv1WDMu2ytddzdwNdax9dax9dqcDcYa/HN+1rqPHd2oDrx So9X6oI6tWrFGj9urgGvxp7k7/l30f8BFQlu2wplbmRzdHJlYW0KZW5kb2JqCjg5OSAwIG9iago8 PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+ L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3Vi dHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01h dHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDgyOD4+c3RyZWFtCngBjVY9jxQxDO3zK1xCcWHsfMxM i4SQ6OBWokBUKziKPSS44v4+z07iCbcHul1p13ljO/56yfyij/SLFnwrC6270O9v9Jl+EuO70O87 evP+genugTamKikWuidZU5cvTU45LiVcTMdkutAP+m5+F/r0Xp2IOsFWcS2G35gkOccNSC1rZPyf 7wm+8OGwxl0/GRt2iBy6OFTiui9bXqkJNVEadltz5EA4kzzFEGhaoiw7V9ejJN3SnTsyIoCvK+xF yGTHe4sUhXNfIhZMPqJCza0OR+yOTPkMLHiGA3nWjkcdXAvNG+ViD4u5Y8+oTZCX3rHRsJFOGMDI mc7eQYeudK6AM/0IbzGxQo8vGqWRUi+0jpLXZ2A6tj1LHqWe1Byb1PoQqLc0TDsGb7cIULlj7JG8 U64SV4F2WtJY6NjpIsUVUw8amd5YKXfwPByWyd3A0hZD928/anlF3X0PeWnU5YJdTb6QyYwiawA7 Nhhyc/L4b9Yyi7E2J2NtcNbCVStE1Xxb/2Zs8BZYGxoeQt06/6qE1g/otH7A1zTpjjlzJ70kh1/I IxZjq6/Atudl5Sb1cax6Mgj1AebBxxL6jNdjkhyZonTM5+0KOTyd6SkfdfejCo2QijHryOl5MGsc ni7jGNwOPe+C5+KI5zrYiFPcsWutawSEpH8S8pkp8Zwa+3BaT1RzbMq906/OegNz5mJSuLda9Z5w UiulnLSLLlbcPv6D600qrj5cQsgcprYokUsuJGWPvOSKx1U5ImUbIhpdatz2kgeCNUS3rKH51MG1 JxL3DO3JDHfM8GmiavqG7aFF0yzDESd82t3qWVg+uGRbgJqKVqHEXBLu9FqXuMkmqIJww8KE3RLL Rlm6WVtYHhVPQG+tQBarAIuLGFmYaAWCP8zQc0tdmE/TxKJXYJgZoo0zn60CYdrQkBaNW3qcrQLN 9Gm+OXEs25YwHSNfGphNQitJ0pLI0ovEq773TEcnXnAqR1MCN1sluQRT0qPdDve3J+K2wB/eYWpp Fqd7enM64e7EUXz6Tl/oFb8mvO8IvbqB9JVOH8K70zSH1kEdRot0QfT/DS3r64IqvTi0nNBAtfhf aHKE9vEPVwoD8wplbmRzdHJlYW0KZW5kb2JqCjkwMCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURl Y29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMiA4 OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBl IDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0v TGVuZ3RoIDIwMjU+PnN0cmVhbQp4AZ1Zu47dNhDt+RUsvYVlkSIpsTUQGEjneIEUQapFbBe7AWwX +f2ceVJ7dfeubBuwqdHMaF5nhuT9Fj/Gb3HG35ZyXHuO3/+Jf8Z/Y8LfOX7/Et99+JHilx+x99hK nWp8iqlXXT/KurZpruGReXgdH+PX+Jn1zvGPD6QkkxJ8alor09/yKrVl2kBpa58S/n94imWa6c8a 1qnjz7rgi0aLTnsctDqtfd5yi7JocTHBzVQ55SFmIabB9RiXecpzT3XQlsyiSXVCuVGGWQ9OG2YZ 1y3KkAupi6mIl0vmzMbkYVVW84ftThn+BKe5hzcoDzFZHJzrMY54JbcrJY3EFb64o1nwnWQ5C+6Q UVA0qv5hZNFpRy6jjHA9oLzeo3Rz/O9UTZljUT+8hKcRTKMhCc6XLOQ7Pqft+bQgSd+igUpKg75P sNEAlDeU+VIYQWVbdI06pjWQNVcIgCn4A0EowcMX0VMgxuhp23P0pE0LsJKnEr8dDR9ymuRtNvSs Boy6aDQgJ8GALi83VCenEFwOn3XQtJizwgfanSLBYV0H2pHrCsXhk62OqPW4Lq02Q89qNVot4XlQ du5o2dag6NlxHSmOnh2XFQWFS9BDZil6rvPZNxFCyQKC7zRPkDoUnKBIQbMcWXTaketAQRZvoOdK TWmn2BQ9yLmjIgdBD9eB8ylSaFZ48Jy2C5QihfkEPTk47Tl6Ssb8mZOix9aEHqwTujWhh5ns4Ws4 i56lvoQesszip42/8ocE6pvV9zoSqLgoB/QU5MuiEZzriJ4yalmxCWDJOMKEFtRR7o027DLK4DpS hpyjhxCs+q1X/yp63EGv4yt4OoeeBrMO6AGivMgcKWfQ41l0r4ECy6zTTlHOoUdqKmA/4wYrUp6h wmk7xxQp7Qp62j4AjhSfPeiIWiAI3n72pBU1tAl68owWT2vo4nVX9DCTPbw6e9JWePaUxOghTyWe s82erTh69jSbPaBJfS82e2zntpUgQQOLAAWqHDw2oEBz8AxJK2XbuS0taHEnhQXrOtJOUFAyzqUN dxvgQe+Wndti6GmGgs1w4f19G6N00I5cVyiOniHnRUHxktlDdl3u3IjmcVX0EE2yMIzVSQNl7pBn 1t029IDLaQeuocl5bqLnoqboNGAG65zhmtIumnQecSEYX1T0bAM9OMpoFe0CYHOG+S52bhSUPXrK gpNB2WT2FCCJ16hjWtcuZx9m4gdIv4qekgU9y5YvZo+de7BbNESl1Up3N3ts5CwGI9jCwwGCEoy0 6pgBxdFjGzfQHD07Sa1v27hBuVF0zLAuow2zzlAcPRjy0vco0C7pxaanMd+5OXp8F7Xt/LFzzzUu G7cDh46enS5DBcVL0NNh1+XsGehBOg7o2ZF0qqw2SxebKutAiqEHqjwUJnekjHDdRM+VmrJCMKTU ce7JToOzzqdI6QM9mClSVxSUwSdzZhvnHp89B/QUdKrSBT0N23BeAz20brPu3EoK/vA6egBAOvfk bblAj8+efjz3YKdoswebdOl6xSrdzz3gUi99+PTRrB0+pMsLVYHXRzG7di9vDRjpOtBOUXZyWjMd jd91KXywe5TLDK/IbkPES77v4GOl3A8btetyem2w0+VV4cOH7LqEz656gNRRURKocfDphhafPuVw 8iH7FS0+fXZyFp0jD2J/8+RzqCqvBOlXe1joQHrmlyPleO55zifFwOouzj3ER7OHr+UmQGT2f3AZ l1acdhrdtgGg8rBOqZaKB1wBzKXhNYyuGG+rLhEs3KxNW6/FKHTT1ppL0gPrZE48lKkXcJtYIAo+ KTp5SZz+QX1Jprmk20khx02geRF4hStBUaau5DqVuuAGsq1kFW5EsDdNR9on7FjnWGbasVLr4Qf0 gArHU8cVIkWgzGJQ32wJa3uTCPhL4nPJFkQnxarTm1kjMMS4USXWyUvi9A8yRawRyTDshE5uaCzK W20Ybv6WVKaGNrb3d0f7hC6ZQqt8O4TtQEux4YKVM17QOyXjdaXslIqYyxLwwEIybi9RDioZ8BIP rJM58QBAUsZ3YqhL08lLcI4Pyks2zSTZNNVJ/oo5anjd2oQcSYWUlf2tfX5OQ9dgf2NDL+MKZ3/R LC78xd7JbJPl3l+miIsuSf6KTvU3a36Hv6C4Ts2v+RuaviQXXZIf2E7JL/trhg9/saO48De0QYO/ ZY5Loz0kbffoYUVaqZ7LouW1rLiCRS5oMyZLeLFIPQd/iSPQkMSD6GROPKDhcH5VjCmmEy+xfAjj g0IR00xy2Kn+kjlmuPu74B6/40YTufT8Go07W2klZhgq/vJDUn/xUwDXc145rKVhyPASbZtywfXs L2e8dEl6GFnDtmJTf12MuyLUZGwzqEHSCPEP2kuYNiTdTvWXzVHDzd+Q4S9kCL/u746GfoWW1tD8 wILSkSaHXR9+ZaHbKf2NBRfA6HvMhPmqTDUwE/02wz/EvL+PSR7wH1o2jvAscf8U393fo0Sg7f5z /Cu+KXcRv67k+OZtuot/x/vfw2/3owPLCsMkR+o0ibrPLdP4gE9Mp00rmMCs9pZpMPJl0+qG/aL0 C/QX6hcvW+hx5+lDvGcNxV2HfgTlQoK37M13geyNV0M57MXu67S9dNr4JXtxufSqvcspewmbhX6B OBHfZUMBE+/PxnfBVREL3opvPWVvxq5jJbydsJdwyLw/ay8dK1jwlr1t2Pvxf0lm19cKZW5kc3Ry ZWFtCmVuZG9iago5MDEgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwv Rm9udDw8L1RUMS4wIDg5MCAwIFI+Pi9FeHRHU3RhdGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAg Uj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4w MDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAxOTA2Pj5zdHJl YW0KeAGdWLuOVDkQzf0VDiHgcv26jxQJIW3GTksbrDYa7TBBsxIQ8Pt76mn3Y3oapiWwy2XfU+U6 5bK/xc/xW5zxW1KO657j93/jX/G/mPCb4/cvPDbHPz+R2rQ27r/jVq152iBZ6jKltYXHr7FOM/7S Ftdpxx8Gr8mOXa9N6z5veY3SWFMsMrOGzdYySXyMWYTZteIxlnnK857WLiuZp2ZdNK/BJY7rMV7K 7pCEYV7aGepGGOyLOTMYADRUWeBvHbtJsJbbY7K7JI8xmR9sXjjG7q/kuFJST5gesLreIHPvmyz4 TrpFLnG7H/s+uuxCq6/kOo/xOX5A4OX489WoiogqQxzE4WtFVLnnXDZYlszng57Lul5IEg4brVfU Uy47xgdgfP/pR4pffsRCgZ7yxBHdirYRydSmyQ1bwErcgZ+f4xM49JNWyLTCBX/KWkb+kKXqvRY8 Trusc8r50zzCtbFsnQXqtRbu48/SZ3o0OztN0nENPHCsptWRXkr6vODxcIM/C20MpZIr/BnyQbih 5ZHiOlf403kBf93Fn9aRHbv3/Ru+k+f8adHtdv4MMpvXtUzS/XWTP1eiyiIhGlfCwAuTDR6IzpVB z2XOH6BW/tB6r/FnLjEvM/OHaCJtoUxekaYaAJS5BO+8zp85MX/yXun8GfiDk0xOkR3I1H9dhg+5 TCK8JNvBZizYLOv4WbP1fO2nFOd+yfTOH1BQTgNbFKu7xHE5D5JjvdS6IhnmWRxR4rEvarQVO38u +ZN63Pr502VB2dIllmkHifNnkHlUwF/KH+DS8+e6nnPF+TNwynfILLJzJHdmOH8Gmc8z7/S9Ngn2 8cb5Uy6jSvmTjT98XqjQziSKBNdzrjh/UE5ZHhv1lD/9/En9TDo9f/Ky4qzZmD95T9o+Rm4vu/CH lazzHF45f/LSmD91z2f8iWShehLto/leWdKq0aXGalajNcRTZTZzLbRgxONT+NaqVWQJyw8hPXDn pDmo5JmWPot3JG1jYa5DxJ5gOhvpkU5aWlEhUmuvpfAdfKwHMVmlmww9dMScBZ+EJ6RejRqwzQQB iD1SIzqueNK8GZRnW0WltuFIc6+GEGXkHR8aCiUMjehRonvORsxR9FK1Q/XKRZ2ySZmf9nYaJsjo Er+4NVi4IIG7zNIs9MRP1eqVxZIlZgrYGTHCKRsSCiPvUXKTrR00sC2+Itr+RQqT3nuhzSW8JZEd hkNP9wyfsG9pctoJi7cZmffyZmXHuRb86Vq2HWShJEb6ZvKUSD3zQV/PQ8sT+K5xQ+eoXDIs5CDR 1LZ7oGEfXCbxNmpdSm5G32kA9OCDSVI9cADAUd7rJlne2zlKe69rWMZjDZiiu6kR6fU32V0k/3H9 wG1sHtUSVfIfkgCUtHNH/Z0l/+X1PP+VMCTAQhnQSGuhjKpfuU/pTQlXXs6BAbtvd0SZiBVcMuRA EGKUX1WhjOI50IMXpctv58CA/HWSAz0oE8FE72oSJG9jzD3RsyDqOAlST4PQHfIg9zQRXrRvBmM5 3bUejUD6ci7E2IvJEGPXsyE/jUwL3jz8HzyI5A2n78oRR8c7Ots8pVbBVGrMaNSNC9q87kGbyBzr Om07jk4fxIHuM1d0ZE3WRAc0qNDu0yDBJRNr8iDqZcpG9kEeVGg2s+Mkhz4NVpA9AU86spiZ0iZc ZvEKVPd1yvtWsLM5XcoeIi5jCTkBEL5Ku7D9AfNgflsxiq1tcV+s9RhRo5P15GsZq2jJPIyhzeuR Htoz2x6GObOvxy3o9W/JGGGSeQM+MXxfcMIpXkSPWJm2darbqZWD7CGWbY9LoZs9zJQO7hmtotbY NtnnpTQaLtsKTW7iBNqQVWiffRAPB0Vm0qCtyZphoTOB9nmYxrEja3KTNP2DOkjQfKbh5ML2CdoE R4G3bZkQm1Cp69TgBuLrjnvYmeyBKkqfFqSjqLGlJ/bWtkBT7QX4E3vJGLcXHZjIUFAC8YiiHqax SbKm2jt8UAcJmsxUaLomxbVMvbA3w/Bze7sM+5tW3HZ4fewv3g8zYoR5XBIeNInHGRFK+5twxkgT e4FCnvfXB5G/dCaeDqijVnAHpJb99WlCc17TGN8/aIOA1mcSNF2T7BU4Ctz3t8zY1Mbx7PtrMhRR sLei5mhKdu7gOi72Vk0jeeFVS0FBI03YWzRviSSgz5d3mUkdWZM10dHs06dBQj6kNaUJTf1gUIlA s5kdp9BXpipwtzevC24vJ/bCZy57wOti3Rc8L0Mlz0b6ld636V6kr9s4spFJWAk3AM0MDUq4PNGr OD+BfzjQyUI//IcaFjdEnnH4Gt8fDnAZVjs8xb/jm/Y24m08xzfv6tv4Tzz8ET8eQj89uEVHCHLV Mu2UfW5Bo3TESgO0wPhfgpZ2kISWvQUNIAla+Hg4OxLoub9te88NeMlHefGi8zzOlooKiHTvBYob pySghrRME2/hzW+DuvImXnD7brwZMflbeJGEXsWb7sJL3JyJr3f4l94kWPdX/VtmytKvxEO5Cy9x qxDf7sBLRQvr/ipeynM88VY8LB3v5/8ByDBPLwplbmRzdHJlYW0KZW5kb2JqCjkwMiAwIG9iago8 PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+ L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3Vi dHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01h dHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDExMjQ+PnN0cmVhbQp4AY1XsW4cOQzt9RUskyITiaOZ kdoAhwDX5bzAFYerFpekWB+QpMjv55ESKXk3XtsGbIoiKZJ6T9J8o0/0jSJ+98R0VKbv/9Hf9D8l /Eb6/oXef/yR6MsPqpXWXJaNHinl1OVLk7e6xC1c1EZlutBX+qxxI/31UYKwBMFSy7Gp/p1KKe5L gWYtvCT8Pz9SXqL85HAsFT9FVjQdue4ydNty1FjWQk3YD1rNs7RYW3DNmbgpUYJZXWiNC8eakIfp Vu7hEBeyr3sO8+g5+Sw+qbZgaAZGzLrEOtbivljwjExDU5auu7W60YQzJavO/S5kXaA1aUYVGaVE v7MwHTbTu2m60XGvxffFaz0PK9OFW6tbzRmA+QAwMv18ESUBKPGaepMFJd4P1021p9btOtuZDtV6 vNS3WuxWhQ+oYLoLPSBHo0SqGzY5Kyc41SYjlsgcN3BCGg0jHwgpEip8ng91VT4wagEfpNLeq9Ix WNPgw6RzPhgNcrYdNKTXFHqVgHQDQpqR5jrnwz7sVu69aLDIGTzomtYc5CWov9a9QgPUulXHjCDU dR1t2ZizG3LR5VaQY7ki1o3uVZpb5tSBCvRrZk6vsfNCcvW+TrrOnyk330mvyDVet/On2PlRBwLM yhg12dznz1NUySlrGYfGFUWVd851U2XGld/xZ+pA6FxRnl3xRzo18ycXcKasyp8tHl3GySMyeKV3 ihrpAN4v8ieX3PiDNJ7cJ2zYZ6cPWxMYkdtO2KG/GXkOtu6nbp2qdX8iz2Tl5DmGZ4fyFN00Iysn wZSWWY1EbzXDL3BEIW7RQYY7rV1uB3E2KuA6yoP6Ouqb/0QOatWvFJ0xQOCEw50m14iS4XoOfnaB oIMY9fYGT8r6jZwN8jCMZngl3kX31Z6P20GO5DjwihtZGtSPDMzlJ3OS8pgrMtfwyyEVzAly9bG0 7HjB+B88kRIzrbu8geCkgyMuacs7BmlJEcJ6oFG4LTiGLuLAQWNLBdRsEsus7imDFlMtMcA5m2E9 3KABRRBTJxEelr6gTrZs3HPkKQ3F+8yrECngodaC9VJ4W/K24l24HvuS9rKiC4h/o3vAbuEsTnrj oW2xBk7wkA5wxEUmHWAwEikyuN1FHNW4JLUDPgmD4SkDiSmHurjKESQdmNywQxZTRbH0BfukpOae kprm2TrQ0rHErV65fXl7Wu+ke8AJFbGQnlCPfbC1enOtvV68bJFbrgWWKgLnFa9d2fGuwRiie+5g sMQURugMt3onN9yvFlNFsfQFVdNSa55h5ImYsuMtHV0EiZd9wR5Jf/AYz1rvVuONDvsLCGzLLhDg 2AGQjoBvBXnP9C8FPG2BEzUCshtK8KRWI/nC0M+JDydhofzin7z7gTyEDadHen86gSSIdvpM/9Cb /S3hG4Hpzbv0lv6l05/0x+kKsfJ9glODD3xUvJCabJ8avTo1xkkqHndT43upbaWOXrL09/nmTX1P i9q+NtHKtsimjnfzXUe+n34BsMDGJwplbmRzdHJlYW0KZW5kb2JqCjkwMyAwIG9iago8PCAvRmls dGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+L0V4dEdT dGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9G b3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsx IDAgMCAxIDAgMF0vTGVuZ3RoIDIyOTg+PnN0cmVhbQp4AZVZy45UNxDd+yu8hAUdP+9jixQhZUdm pCyirEYBFjORgAW/n1NPu/v2NA0jwK5bLleVzynXvfM1foxfY8LPkktc9xK//Rv/iv/FjJ8Uv33m Zyn++YHUTmvn+Tse1dROGyR1r6e89vD0Etsp4Q8sbTxIPV6TPQ+9flr3tPUtymDp+ij1ICZgS4zC 1lMsKhyy51jTqaQ9L0NWi7ihRvsWXOJ+PcWj7A5JmNaVpNvAB9uxFHYGSTGviuZk+G4S2PJ4THaX 5Clmy4OtC8+acuSrlvgcc1bnTAMyz+gk87ybLPgZeixDYhE/abKxm2fhoDVZGuu+xPeAXIk/foqn CDyZxyEnIMmzhdkUTW5nz9rZM0sUVlfJSPDkPccH+PLbh+85fv5OMI5LX06M2bzqGFil8bKeAEAc NCnZ5Ev4BJb8IAuFLBwZsmdmyLInYghFpFla4nra6U8dDFmCy5whi2K42WDZY7WVGtsyJI6oElxr YojLFK9lWHeJ++BIL8Ovo9ZRMtbFvIurlDhhSAmKqjYxRN2y8wWmTDLiGTJFASyZlkmGjjNksuWI Qb6y+6U8maxNer7Ds9WnfezhJ+kRmSR43M6TZeTCtG5JnqLyJFzjyRFVjgRNOKHKs2KyUSPgjeVu 0nPZlIGscCB7wp8STQZ7M39ay3GBEvMHhVzGQDKNK6Im/rCSTb7EwZ9wjT+t7sKfvl7wZzP+EPc1 o0MGz1wmBa6teoJrNrY0qy7bkEx40wQ12NJavg49Q7PxB48U38OviQeaxGb3EG5aASBYcGud42jw JxragnvlKPUTd8kUj8sOWuEgwU2rRfIaf5CvI3+cFwNlm8tw8HIMyL774SdkEY0zs7hxQ7qWye6S OH+u3TMXqKK+RfmzReXKdKOUIXNebDf5M2fAuHKNP8jKzJ+cAc29MH/yVmUMWzRuCeQj/pCST2b+ XL1/cq3Mn1aW8w4NtiTkNPgzy4w/kMnBdbt/0KrJkaSqHVryzqte6dAqnFakem+H2KxfMuvGjDz8 cv5MMl/n3h8k5x0a7W57Kc68N+uxNKuSwGWbvZ+ehGksWt5A4IlhAlm47LvmZ6ypwW5kUZMIH6xj HJIET+bZa2OgPLzaTV2c/eim4Omr3VRawqvdFK3bBo7xgrAhwhnBO92OmwC4VNzPNAZmS0XedgEw 6dj4p/jdV4ZvWcsFfFG7ve4DwuSIJqkZYKsOljVapYemHHKgc1NUkgwnp2dD0IQ5wh7+G/+woFDb CZkfmZkQiBiE6P+C4mf/UjGlmUOFNyQuX0hJJ4gj8Bozj8l3HJIJJNgoTbpjHCC/WQrPEzxhpBlG 6P/huKEjAiVDari4jojUGRG1I1weI4c9h5KXgQgb/xQRBf0avXMWdAZnHXXatUudgLHrNTvBY9eD rg4PvC/xXbxZ5bEGe5vfz0zHYWNNN4Hk7G0Tll0itzzgNMqbiQ46B8FU//TuozhMzfpo7OZvmuak 3ud+1xKejzKTWB8NjOo1aHc0rRu1zqz7uSNR0geQX/a+OaxNenrnk57C2/sKv05QF6QS4rbjhOJE PW6vh7t1zdM617J1Q8fBf62PvoIlvVZ2vfO3TPXOsiK9wZb9fk/wxrIy6blsyoD2Aef1U7EAe3MV LRWldW9KmlXHRBrUBBCI+wBS8snMmqt9dEVqmTWI5Yw1uVonSpFK/iYZPHOZHFyz+roYAXa7nrFO kgHJhDeTwZYj1WSGZiu/sK749g6ZbB1kRqdJ66Azr/Pe0fnjRRw9+QV/AEQ7ce9Vp3hcdtCyPtp5 t1/hz+51k/J16KPHWkcZ9HxP588yZH5Cyh+7NrDO4h599JCNkzWtKxLnz7U++gJVUx9drWe+wh+g w3hBHioUZp6ZbM7AsY8GSfQlCvaIP/wh84SXzeT/4PNlbju+4FD3HF500k6543tKbiBDwqBlJlXG O6IOUfZaP217Ry7tIbrX7Ct7EJt0wI2e4CAbtKdl+P7WMSebPCRN31AfkmuyEher+QmbROgRBY/w AVaM8YsAqk0/tV7p6yiOPXW8IzzHkkUWJtkDKjMA1Ln9QgZosuBrFGcgo6+iDJRFHKKORIbwNuHd GxkI9hDVbqykidhkTUxwGJwBXcYSygDZxEMMn0L2DUUirtnK4adkQJaq4x5vWdBP1K0CHRYv/BIZ I6EU1Em88GBHpIkn+HpA8ZJU4iXuUutNf2lIVz1IxicuEprjr6+kCdtkTUyaxDstAxHZJq5mHpKm b6gPyTVf6X5KvOKOOa7ni9YynTq9A87xDtkDXgfxfXLlDKOE8wQ46wTLpNsvK2UxNPgnQ2CM3iI5 XpVgjoe+kiZyaqSJSZd4bVkgCeyJTR6STd9QH5JrvtL9lHhlKW0CavYNX14bvm7St9LSN/qG3TG8 lCHejiga5xPx8qRrvB0EBZ7D0jiLIAg09dRaR+dIjPaH+FwFlkum0JyqTUTBk8LxhmkZ8QwPySYP SVM2NIl4IyvVNUUCGA1TtFQdH/F2Ogc+3xHvkD3g9kuxbviCTniWSWY8h4rKzXiuGztU8Z6hQ1ya 6Kk5Xn+IG3uTlfTQbLJmqDh55u9YBgm2ZJsyJE3bUB+Sa77S/QSbqIKJO+q4x1v3/VTbebyTDPFW dKJSdV+CTIAq4m+toCPXK5R+8q2C0zKEb/iqKPy1h3gtQg50JeqY2GRNPMHFQ/VqWsaVVWzykDR9 Q31IrslKdU2Rz/GyOyyY8FzwDSZt5/FOsgf8LqShkHUq4fhdihT1vAb8Ho6+jupv4dAUo86zEjpy Ver0yzrcFPyDu+79I72t0Q/+A1RRfWhFeHyJvz0+osTD2uOn+Hd8s76N+B1eiW/etbfxn/j4R/z9 8fLGgUF0SaisCdX2pmtlAcdI6W7XygpYUBG/5Vr/iWsogokK462slYawSel+11ATaMVN15ZbrvVt 17KFwUql7HUPB+VR61j3XkfpS6HUy8YLb/pb7vMXZadSKbrHX5Q+1v1lf/vGC2/6W+/yF/ufNiol d/hLJYZ1f9VfvvCwyU1/813+FrykdCoFd/hLJYJ1f9XfgppFC2/6C/4b6z/+D5qaVZQKZW5kc3Ry ZWFtCmVuZG9iago5MDQgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwv Rm9udDw8L1RUMS4wIDg5MCAwIFI+Pi9FeHRHU3RhdGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAg Uj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4w MDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAzMzMxPj5zdHJl YW0KeAGVWkmPJbcNvutX6GgfXClttVwNBAZyc6aBHIKcGrFz6A5g+5C/n4+rVPXqVT/PADMURVKk xE2q91v8Of4WZ/xdUo7rnuPv/47/iP+NCX/n+Puv8S8//ZHir3/E0tZY1nlq8TOWLSn8IfCWprkF DIiIB/Ej/if+wpLn+PefSEwmMVhsWhvjf2CotDZtwNS5Tgn/v3/GOs34k2pYpx1/loolDRcd99Fx bVr3eUtrFGCBEsa5mSzHvMcsyNypoPk85XlPS8eVzKxZhUK6Ybpe747rehnVHabzhbSLqtgw58yZ lcEmm1ZZ1e+6O6bbExznFt5g3mOyfXCqj9j3K7leCadLBxIv6Eac777T2akFt8gw0e1+7+fouEcq w/T9eoeD/Qj3zfF/L3mVWRZ1w2v47LtpOJyC0yXb84HOcSOduiTJK+ozSXGQ9w06WhDte1zawjHU UlH4IzK8rIgh0BMNw4gnCiHE2lIb89QNcwzD+QmGLOYhGoONp1RZZ17jQjDENYLB7zwGGw/0p/hm fRhW3cDvPAwPuqXc12FY16G9IHtIN4NtnTkxT06wgWCIYxj8zmMw8SSc8dMMkrfCGWTZZ8ogoWeQ pDG4l55BBpxnkKQxXhfLIFXzwF6C+gOCkQMCsjziBtxDBgGdxnOXHhwj7sGyHnEvYIJnECRqcd4d e+2cGm8w45RBdvN5j+YdsjRfdNxLGM8gnQ8H2fdLMgjpdc4ghHM6OAelecJpBqmWVfagcY8VJCdW yxaD3Z5BBpzz2e50SYbBOd5kkJNXUV0yjYNuOHmV75zjBss0W+wjneM6XdBswXSSQWCJugh25ZRB 2rpz9FQqeAzDkQmG/3MVxlYKDN4vo6esGj1Q7Fh/m9a5denR0zSigPPoaXpsGctyIV42jRVQ6Z61 IIcMjHub1V+W5X7qdOrLVn8h3TBdL48C9C7sRJBlVHeYzmf1ZIM9zqm+BgVP0bPZeWfz0G2wx+rv FdW5IhPfuf6SDn2/JHoIp9EzrNnpuh4ePVheNnGzWGlWf7NjLGuQHhorreOeY/p+3UbPhVeZZVp/ 1+Wx/rInOJ1GytajJ0fHDTugkbJd1F/avTF66gJnzVIY64qQYRieTHDRwgii4AOtWKiIHHNphwCG cSwEQ4BVLIfHmAtXPW9q81TyFlvdp4quc2h6rTytlAw8ialz70ivjpNYK1Zd0CVr6GzmRFae1sFJ Ow6y3L2dU0PAhEK6Y0wHOMwD7lzYoP0DzcinKXgIOk/wJbhW7saeZB3jScRLjwddx4QrPg26TtWD DsY+BF2nG0ub6+FB5yXLgw6cUrJKPzOzGyXXz9FwL2Fug+7sVtQJaTQli7ohmgacRxPqjuWOobYZ btwCizqKzlPNOkddQoTUXVq+1HaBIYvgNmvLR0Q+GCPo8taYcIx0a2y5HXs+SCETZXd5YCFD8rk8 tdLrVNUNwmSFg5rDhAqvUD+kmWJVCLyAKZ74v/4PI/JMbMjTcvDNRYQM/9CjiID7SjQaZ0bYKwRc iRQSASjxWIKqwhErI6/A4PBNcH06ZoYONgrQ2+B4gu8d7ngKSGPaLWM709zzNryKdsb0j4lu9G4p RuMce6h6VEhnX0JvY68QaUXA8osENoNge3ggGoNHT7rOxWW5fn+YF+0ghveHAQf/1T2zS4O/PzTr f8CpNg/vCsPZS6gtFbLc2QwHP9Jbtxxpf3+wEgHpD6kYspxPEjbVBZPkmIFP0w/1c06n/pIsFTfr KJZ+apoCh37OU+UF1UMqJr5zKiYd+n7dvD94HsJ5uB6WirH7jvMTMov6mZndnoohy3CPVBeY+8g4 elXPxFjF3xqGGHDcsAOadan77rGi7jHugGZipjtlYtrRsf+hliXv0sqUgrsgweR9gAse4BC30tf4 YIyfy0ycm9wfSl6PmdjcFK2V5eMBZdHjnYblZCRY6eRXu3k7YkybRkRua02649yRtUc6xwRUGiJA Gxt/3xu0dEFGc3HvvmxiulLqi1ftyZAJnlP1s3eax8jZ3B/uexgPMI9V0l5rRrG42eyubIXMOxiL kOHW0FESbH4H90boxSvDyZGGC7f1Lmu/MXjvsg4mWZtyETBkpqQWv1kP94WOA9khXuApGY5Nj2L0 4CYwfJfgAoEcL+uKm58OKF7w4pWTvPKVZjD8lGAIYyaiMXiMscsaVfBGRt1Oxr3heEenXsSjiwYe VznIsbZq50uNjO4B7oFjMA3dzsLdzqHytKGmSOej0yhzVlkO4BBb2hEpg/UhVleQvY/dzxgRxxnP gOAY/Z9qpxulfZGt1vsKfNvgDko9HTtp3RHNaLdmXg9M745o3rqjR/i2BpxOrdcAyHnaHdHcs+6I 5q67I3offfiykmbpbDIKxMFrZvODObvzzNVaN+ottW6a63QfWm0qWaWGV/F+4/NAPz3dSuA8PQ90 OCb3TcByfNCF/KaPBpga3iOV+pWfneVbPtmjr4wjgx/78d6LdK9BoGLhLzptxL75EvbVfMk2BZju SzRvvvQIw5fC0+8ZF2epG3LbaYenvgTbDr5Eo2PuQxedFr205RIExmbkgm5bL21EY/CYxS47hX3l JIYe5NgoYCukvOLro+WyEffgjtVucv6hb8/mvfYKAlnkjto7YOSOOFDgdMURIRGwacFF3kfjzAFm d9WWUR7f7fixhPQk1Z4E6dndyusummk5P84cqXAmTvUxWDg+rA8UFiNwM2mFhid11DHDWXDbo+Dg vm6NXw6r1Xdc2yXOLzBW4cmymyf1owP0Ao/D1tfzzBXeRzg09XIsaupTN9xHI4WeH5yIfVS+KqA+ UEXnz9wTnv9m/wcftzMceFm5JIOJB9uUGtwh7wBmfBBa8MKOYMn7GhSEX8GFtx1Z0ScbQOekActk SgzatFdQD2z01Bggkychnih9QX6HFG2c0/WkHcZ3dbeCoIAP7CLMTGlTbQX1YtnRh7StYCdzesR9 Q4gzKV4/lylvNeEAOmqdyrbhWrTgxbThcbahyyEiYAoJ6wiU5CVPpW4oGUrEGUOIXA6r4GvBasoq QkNJAbeTQUw9rIUnWUUQlyvkRGaGyzGE2MWeiQ+JojiEKRrHbnvV6jLVSunft6qjsFMFtslHSewR D/DFBL4SUgFAvtISYgQ2UF4RELoiFbCv+OTML8jsZZg0mUwZWprFVwY2+qqjMhkkSl9QJ0k15zQ9 kcc4KbM6nLFHazNY540SYze342Bvw/cPvNph8c8gg0z2wh9aEnsLro+kW5tBySB0q3iZo9iwyYok vBtn3YLKZEq80yDyKTY6GzAmU0BQ+oI2CdWUU1VjPdVeVkcU76dbZ6Tk5RgJA+5bzMseipwatmnB hTjBl8hesKm96OqhW6a6IyDiFgEk9tokaolyBkxiwE7BlBhkzQWdjU9GZDJIlL6gTpJqzkmqqUw6 X2FlxHC+BW/Z9RT5huOcmDK1tsomA7U3wSHYnzM6SDoLdC0K4izozY/OVzABY4DGyQPVTWZU64GN TRKZaq8tiIdInSTVjLPrqefL6pztzfhKlo7nGwYc/Bk/uEgby0f88oDjF/6MrWV708ZSE55WFYS9 88724ilSJmf0PPjFgUQCD8wKHlgUKhtoJURZpsQv9swX1ElSzTi7nmovs6riOFX8MgpulTb4SKUv QnSNHFGI6G8UHvhpBUun32vJ7yw45yCli7WLbHbZUIUYpL5ns8pmkyhmuH0qJw3EBqLEV+ZNvNnZ CAOPgcygIMnUBX2Svk87p+sp1oo6qnjbUL4qAnOBwzecHmyjT9uEwy/WHAd76QFYs5UONOfQEzGf riSkUCi0LVsV/NJmzFYY92wlA80sPNCcE40tUBYie0mmgLDXF9RJfpvWPDfoqfayOrQISq/Zi1/D LdO6crZyewcc7MV7cC5a7mWAXaZsRZmJ7EXrKbolZCwBoRvaKIlem6RXH+ekgXYuoMRA+g8kH2fj 5gQJjidhOsmUBQ0j2mjnMujJ9kIUsaribm+mX0VJtnJ7BxyyM7cyM5GgSElzk9aAXyvSr4P0t4r4 RRV6TCZCllKiRj9ptF8iouf78Y1u3/QX/+H3DPBu4ghvn/Evb28YQNrbL/Gf8bvt+4jfKOb43Q/5 +/iv+Pa3+Ne3U+dFv5BEscfvqHZ0Dnea4WiY5mXFGh57SOjbZ3iqV/1CL/TzjWr8rWKYZKLXNaOv 5hB7u2XtXrWy79NK6fpONarPTPSyavQrUuK4VW35QjV0bPtXjkallIleVq1QMH3laOu9ahlN3vLV rlHVY6KXVcvoV4jjdtf2e9XStk5LxW0WLYNUo8fopJrFNKikQvNFcCY0jsRwFwPJonS+U7AhF3vV mKmSPHc8z0AL9oVpX91JqKuLIPVikdsNLS/pS1k/UyV4Qd86r0L7Z/WtcBla5FZfbPTzJOj7S1n7 izTt+5vbn8zWtr8Z18YvkzbSt+n78/8BgJtP+AplbmRzdHJlYW0KZW5kb2JqCjkwNSAwIG9iago8 PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+ L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3Vi dHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01h dHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDIwOTA+PnN0cmVhbQp4AZ1Zu24dNxDt9ytY2oU3y9c+ WgOBgXSOBaQIUgmxXUgBbBf5/Zx5U3elqxtbgEXOzpAzwzMPUt/Sx/QtLfhZc0nbUdL3v9Mf6Z+U 8bOk71/SLx9+5PTlR6o9p5bb3NNjqlvX8YOMS5+XPmFCTDxJD+lr+gzCFlLrEVI0NkZmsglJLRNp 9PsH2rzQ5lBxxp5Efcej2tZ5Jy3aPmf8vn9MbV7wL7e0zQf+7QWKGm1y2oPTUp+3Y9lr18G6pWqS u63llPtUhFgmp8HeZS7LkdeQrIVFS6zuFNfhPhkt9DJKaH+mhFzKh6gKNxvfVAorU0Oroqq67skp YU/Q3ELnMkrw3KesfgjaQwp/ZdcrZ3Hi5KsNfANNjgHed5qdWnKLjDK53fdxjk4zrvDOmXIPWL4H 6Mv0702ocsvU4RWocq8YDch3vmw+H/icNvIpHGi9qpjJSsN6n6BjTs/ouBcGfq/rU+AvVaHTDwf+ UhVgoBnwwSceR7yr6w2+4BIzlqaABoWA4jMKcYH8wFFtIayIsdjAkuPshfFEoLYDWxnOduw59lJo rKSLj1kzn5XdgHbJlQcZOwCyUKBKe+YcqwZHrPcQnvL9BFrwpoIUiY9PERQF5ArfGc2AuzoluIwn KA7S1wEwIfP5oQke4XrCXvJZmJQUiatw+Cw4JsUgc8AUOU1yEiHSi8EOc5fKxaAdSMM8BsRojCKx 9PQwVWLSCRcDzOtRWKg0pCkePyQa0wIklHRhHlMpoBigKjA9VwVa61IF6vY0GHDkqvhQBYIGGIvT wafBYFVgg46cwtZiMW3wB2XImsYVIWH1A3yWk2N1p7heQzY32nTmOlMGOQdaVAGH46SB6nmVwkLz jIN4sMdpJ67pRIEfLqsAIURzIPw1htbFnvCX8/meFmDwvtP8hC4CDGdmdiN5OJfRbqJcDbALVEWE YWeJqfWZKgDaYJlH1rkKrKMHPL7OVeAUc/VAO3VIzHWED40JyTTeFgmfSkw2GePn2S6qZSkm9agU P2Sp+nOzpELt3pnm8bMpwrsFEvV1kgf7pOfsOQ9tWmDQuOA176Kc5qiX6Ox7RIYsivwwxIHTXO5l ChccwyS8Rj0j6WB9m6Kth1ZF7Q/djYK1IjZe5HqGZ4wflQtUoBwXaKT9U0F+dC3dowNNi/jhfJPy I/KlI0ROlhVAMYs9cgbaiWtYKeS0f3quNF3gibpy03jKC9cc9TxmHi1rQtM+xkl78k1XIA7tkyZN PnRu0ifRxQB3lXIgB6MW8B2lIJPzmA6XxvvcO5UY4eIZnC5BcnHZuboQrhxcnpjJJl+nqFXPxlo5 pFbVLV/UKmuZDqq5egZFGzfQPNaszWoeawAp1ypUXfUSSo9RHJtZbyzgGmLN+RT5WSMZqztF6hJ0 8FjLodeZ60wJOSCPdpcoQ5YXZDarUihOzeIEX1tkCp5plJ3GHkf0JSKI+1CPIJZytFE8QRONmk4z 83loFZQFmoyzl8ZXK8rF2Q8VpWhF4bN3K6XK8Nn7uY4xgsv5ECMF8RDRgW877Bu7tYwKUXBvoLAg 0MpYAqEg9TOamYknHhTSeT2PZkQT3b9rvriGZLvAkkrqLLvlkl5KMrAZ6lA9BZD7blAOwgnJYDoh GTRHlxxuQ9Ab3gTJ4AlEhlZnrjMl5Kz7oCuV8dndG7cKexHQPgZp2RKYU8Ie63aCyy4dQQmeEe0a vtDBltemi9S6vHoTzdhcC48BgMNWs9Ox8PTj0u7qiI4r3GBCxnMSgtOvFI3yFEpDcGhs4NS8OuSg hUnabMm1R2ul0SIp2F2G2aSSIFY0xcFBFDH8GDaveGny/1BWDiRcuAgvXI8ybnPuracDt46l4YWr y+MVAlZH9+lo83503GzsW8PI5GjM6xEfxmiXW2+jDN5OsD6txyPwxV7yjXQyOdePHI3nM1eeR3hH 45U40OHJPqNlpNs/kNn2nfpWrPSUBrd9Aifh2cVowhYgWXc0jEtDp7LQyx/mSLkyBLj7wrYrZcJ8 lKQJr8mcmKgVgxhbKGuq+bYh6oV+JG1c0vUUB4ioK662VQC04cFvsHcaaJ9Sxc2tVTYIb5w8QXbr ZOaKok32NnQUsLeuiw2RGDpyIc56so9ohhs9z7AkT3hN5sQXBBudtokxxdcUz0zDhkwRbUwy9BR7 RR1VvO/rjJ3Rh3ecKuzFWfZjeUpjvLeVXmsRvtzk86SL1m1d1N6y0ueGN4XGQ0oAfZPzFQrN+S2X 7ZUJr8mc+FLE3kEMWZnXnOgjhuCMDeUja2OSoafYK+qo4mYv3L/Y+Ya9QfsEVVAjdr4poTbxBMdK p9QKhxcOGmUScQ7LdEi6wUV0vkbBHEOXpAmvyZy4fe1qr4pNRCF7aU0ZEqdtaB+hWki6nmovq0Ob IAOZvXg/yfMm8ev2DjTgGe9ahDJsDjzz5FBUZjlf4IxVrwuujTIEShc9X/+IrhqXTcHzQhNekzkx WdleRKaJgYIteU0ZglM3ZHb6yNqI5Kgn24ul6Kqrioe9uNee7A0a8hVSGvI5uQT3HEloeZvwFw3q zbXFp4yMEyImXCOUqdOfPZA4+QcZ//1dwg2FfvALT0Oo8yQx3T2mX+7ukIGw2t3n9Gd6c7ylv0iU 9OZdeZv+Sne/pV/vLhMw3UxgJHal7HNNNUpHzHSzapVqNwX5NdXWa6r1He8Iki+W1zR0nFFu+V+K 0lufbNJf1zffpm9RZ73s0dAXeeDn9K3tdX3rTfpSbJbr4HR96W2UeW8Fgvm3HisLXsVDu01fxNbN +uJW+3P6bv11fXvo+/E/taiyngplbmRzdHJlYW0KZW5kb2JqCjkwNiAwIG9iago8PCAvRmlsdGVy IC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+L0V4dEdTdGF0 ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3Jt L0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAg MCAxIDAgMF0vTGVuZ3RoIDE3Njc+PnN0cmVhbQp4AY1YPW8cNxDt+StYWoXO5JLcXbYGAgPpHB2Q Ikh1iJ1CCmC78N/Pm09Sd6fTSYBEDmeGM5z3+LHf45f4PSb8rnmJW1/ij3/in/G/mPGb4o9v8ePn nzl++xl7j3XthxZfYt42bT9Le0+H1MIz63A7Psd/41f2m+Ifn8nJQk4w1WFrLH/kVl7qYYekpXLI +H96ifWQ6KeF7dDxs2JCE0UTPQ9RO2w97QheGm2PRe12dWSCcIqLyLKJEGdJhyX13FxUFrbL6hCe XWLTn8KF6H3BafjJXUPE9DpbWBaOA6FZQIsl4lG7ZMrEZaYVLiTRJaeYbQVc9hzHQmWPK2dZheFt 0ptsfdVd5sXyjEwSPO/TqJ/LTCvekJwAq0+A7BJ+3YUlz8wW/GVAQEWArWtlW/FJzWWzngEBekXR klUGf0+I0GizbD22npg3tQJU3AZ+0V4TFrkBg6TkHSJOjr+YM+EaZ8q+M2dWcOcVZ/KqBJlIM8kQ mawxZFK2itiYPquxBpYKECMEJI42UIEB0lf4UpyuLjMsGxXhXdGNnUXt4OtCZmSatC50ZrslEW2F N0tUlFWPJyzViozROkd/NqKMUS1lBves1rkhOMymbDgbI+/PYwXR8/X1qIYkYf+Zem+2HePAwMV+ eVb7gP3S6yWA5tp7Zi4bGcVcsaW6BnpjLOSdxgTTCzYLjM1oLnuOte2C5t60DVxRG6cDo5mVuAOU EJrJqG5sVHYcHdxGCakNZ2ykjrk9M+DqqVHawgyoeyYG0CroylZFGtxdkzkDqpatWGPdFMd7Drqi gBSjFr4uGADZBQMgc1QKrUo9xzb7ci1hxWz3tgTocTvdIak6LlPEFeeB7fr7qLXu0fs4CYFoTfJS 64rEz49hhxqP9ZLzg+Ky82P4n/R8TmfP5nrBK+kZucTzdiZVOy32gQDTGp5Mgjrq+XGVW69RRXcR yywIj1CpiTkumzLT04JZJMZgka3w0At6Wrxmmxb/jHMdJa1CuSVbG2cGtRtRDhUgHW7D9l325E3Y U/bl9fmRNr1z7XTLk1VPmzGKDiqXKb532/2MKk2XDK40a9zpDEh27YJ7J48dM5AplO3iVXAm2eVI V4Z8mWyEdY9k2NklZCJPtkMEq3h2+XLyQMfKOPKxy9E1LbuOzXbnly+KQVBC6yXk6ZC9TR6Uw+Nw 8gyR1cduk2VUbOKAaZ1zB85dy3TGct3kzhVMWWJRedKCcye7bFoA40kfHMMjRBadFsX9GXfI39nt ixaUziu6P12cndvKh0ZZ0xnsi8J+m94aRfEFmcO+KNoXvzbZ5QdaGl5R3ENCOFFesBfFlh0rkOFu IUSCR7QF5Ww59egG4iNzmzA9CkZHgeEY9zTBMW5ChlrEYm3e/r1HUdrIqzZt9mPECwCS+DYf8sSL ScP9OUbX4UmhVUa0JpnBZrKR4T0SB+m1B8IlAKxoikcsPWF09EZKwXdx1vDe0MBTWK4L5KOMniCS n9mHFW9f/An0hx7XuSbcnej1DCPp4EbT6grg90NOaNSOTbChjxNOmqhLAZR7w32TJYiN9NySOuyT NWPFe6FXaA8zSMynNElTJgykToMUmluOOGmF8bK3VKSFJ74EqKkAISlXJFo7nBWi77KJCLGZ6AkA A0Pk3oj8qbOBnJz/vkn+ZeNHUt7XoE3CJb4aUP4+SE23REd8siY6KAzn72aQ4NyETx5EtqRpE/Kg huaWHqfkL6Z84X0hPki2BR8/Cj6UTNkO0VPE15WCuy+me5H2LrlS5VJtuIFW9thT0NYpogKUKUgn Y7RGuA3wGnGb/ZEe5E3ynGwa5dkTj3Ga01w0JnGo3YhPkmQ7jXfk2PJhxXt1ztFFT7Gmik9JXDJc IbiDW0areB/QJx5C9AryYOaalqBNXOdSkor6IH+RMkvqsE/WxFsZZwpVdJhBgkzhkwc51TEhD0IZ oQ1Lj1OSZVMLvKGQfW810Bs7cbYN4CFRHKInoAesXJkvgAF3wCLCL4FO+AtcIpyyrqFKE/v2qvhV Cfr8fFJL6rBP1kRnlWyHGSTIFj55kLMdE/KgRuOWHqdkK6YauGdb93JojF/Pdoie4gLu4hkHOi+Y n/iNXY4+GNIHC/1ciBsH+M06WDnRaYF16Csjf1L8dIxZOvhH3/4WNji+xI/HI8oMX8ev8a/4IT9E fCZc4odkjcf8EP6Ox9/jb8fzPQjbKfi1deDodoBESda5N8DC+0aPdwVY3wkQXMkA1K0VpOct69wd YFvZ4K4A260AGxCgKAcUbsbpECFCsOqd4e4ApRAJQMEUN6MOAoDH5SG+XXePmtCa3ih/YOx51BVF ZdURtUD5DZha1Hw89h5uRq2wfSwj6i//A4NCqSkKZW5kc3RyZWFtCmVuZG9iago5MDcgMCBvYmoK PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFI+ Pi9FeHRHU3RhdGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1 YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9N YXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCA4MTg+PnN0cmVhbQp4AY1WTU8cMQy951f4SA+EfEyS yRWpQuqNslIPVU+rQg9LJeDQv9/nJHYGBtDuSrvOG8exX/ySeaJbeiKHb/aBSg30/Jt+0F/y+Dp6 fqCrmxdPDy/kS6GwVJvokXxNwz51OzvrksGAndqATvSH7ltkR99vOEzgMFjMltTwy2b5EuwKJKzR evwfH2mxjj/FFFvxWSuWFIwUO00s2VLdugTqRqYoE1cJpcgRKzXQT68TRWeDqz5NLIbhpcEFmWkd SbCZ1jnInGd8balW8KUzQ2jJLDOr0NOvM3dFZj1GMa3wE+RIXnhQrxNNvrzm5f1g4h0/2mBCvkKy Z0YLEgRdM8If5y4qtvcSZNJ1RHtdo3kD/Turp6QwGgubx8ml5DLLJy+Eb9wU2/r1dqwcLg6a/MCw pXfIUAQUXaWU1yagmMqwse1slwoBcQ+4anTAAvKo70PtRFDG2skuvNaOj6MhU0Zmnb0NhoUU67vG uTURZRFPyqMZMK+TgViz2RRrSbd+3cwcrSyCRHRFOjkt1g7be72DqHiCdFHGyaOxRq+JdrJ0KIw3 /Z5pU85o2mz2Xntkr50MGkZ40NW1w2m91c4rP1kTc5V8xXSDRkFGgaETTn+PnYFgFz/Rzjs9pYV1 oaAzpiqMYhsChlK2fqKoVwQMpTS/oR6jWFdPu55sxo2hP7iU/LpSKHzp8G3UBt76tGQMivUORsC9 gjvJr2KCLr8udq1pGQ95DFNn8qDFbJ64yFZbF3jLNMMIlmwxu8mesqA8RGpzpubJpOM+lCpMs3Ax 9gRHKXwNlRKRyOrtkhyzFfIeu6MYE6WVTw0IvA2qYwZwg8WlM5AqDm4eRxompIPebAzoQ4+HOtOb HhNcwRMLQK3MwJwGRGJ2kz1lQXnIqfWZZuaJmMxAS6cljq1LKLOEUHCCZVvxw1JYIYY32B3O+bA6 W5mSkAYhvhi8rfAZOd5VYuOtO0VxSvxKI28i6J3rA3l+4XH8x+8dqYU1h0e6OhxAGaId7uknXfgv VKLNzcDLSqCLS0C/6PCNvh7mVnYLkRPaSzNfuJqPU91UWWz3PTNjMNsXwdnCE89LPMzEb/8DsHP8 fQplbmRzdHJlYW0KZW5kb2JqCjkwOCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNv dXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dz MSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsw LjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDE5 ODU+PnN0cmVhbQp4AZVZwY7cNgy96yt0TA7rSLIlW9cARYDe0h2gh6KnRZMcZgMkOfT3+0iRlDye mZ1mgaxEkzIpvkfK2h/+s//hA35KTH6tyf/8x//pv/uIn+B/fvUfPv2K/usvn+bo0xqn7F/9HKqM z228pSlkd25KPPFn/81/4ZWD/+MTLZNoGbxsWjPLn3iUcpk2SOaQp4jfL69+mQL+RbdOlf5teKOI vInOJsrTWsOWo2+DMvtZ7ba2kAnci0+XMjg6hymFGovp+RnxkAuyJhY3iXqAtQ6yhySDXQr0dnmX S4ndoK0Qf9LS/cV48P7iiUXFWlFidJidvQWcMIlRAts94oltH2a63eqSM0GAF8Pk+vAFuf8IZCX/ 75sJd0i4ulg1ca89bpP1SOICRFjImNkjFwksaZYgMTv7ZzhiIK7Rl9BAvKyrjIElGkcCMQwSKfEE iCYQR4RxG781M37LfIlf8InjyaCMbuAgMwQnQVlYFcKAQLNcdGuSSY4YzrQBhhmzVFz11U2ifh0x DF8PWlckA4ZjSxCx3ywFNt0pZISYnHvWTDKCWrSc5da0jpIXrzCnfLfVDQfYrsiyArc65q/oDbZC ADipeoLu5CWgnkWNurMheZOZ2W0Jdv4eRY6YEookL9tNZVg3xZls2IDYgiiDnjfZqCdgGHjjosr2 7IlgSS4bt4AUZxmDMDRea2MPK+nkm3uDPXGLjT0h7as/yCBOUARtR8MqLSEXIF5liu+q7FGqFCFP 2Lqko81JkmmpS/KgE+wbAPqdScytToLu1lHrKOl2Chn24aINdKcEjsXyrQAtu46g+VZUmNaBTmR3 SR5yoWGMtkvIA9kleYhQpmeenW3vTWTp0WJgAmFFAQcOsockd7lzgajeXhCX8GTHCZMNcRlPOseM O2P8whNez3pOwwft59h55g3Hp6Uyd6jb8Bhr8biExh1W0gl1HjKaG+HiTIWJxkgKjbEYtytZmM9f b3areWvdKm3znm8xC9+22rvVIFO+Qa/VyUXbVlF6wVKqlPavrfZupR0MWgfCQSY00UWxuknahvJa B9lR64rECGc1umLnbS0B6HJgHA65LSA0gMau2hnXZcqvLrlqJ4wbtBRx2FNhHPkljLuuZ34Y47bu W2MTVtOItF9lLTTkv2kJD+sjkvv96gqqDAmNXwCVbYq0K8KBaQnjRjVl3F6vgYH1GuOSdivSI8bR ae3wlYFvEvrIiGisu4+MMOsnRTLYjzKFPWQCe8V/sc+FpAURCOJDR00Me5t1wHcNwK+viLHElZCg cTYn/QoiQlxoWQIJzJZ0hTG+HRS0qYOkeXbtCfLTLahB9JkmKsD/1hqw2S5ScWoBWyqhMcjkRIXO pXpS8OfurUqcRaMQxZ6bTLXuSawtuIcA0LAHhwWhAABtgc160G6HziMusYZ0gobLPruDyLlOW0Ef qGGal4XalMWoBa8ffBSlXDxN77IQKyJRKiU4/RaGHZ18BJFjCVZEcglWRA5Yk7Lbm4OhsFmYr4xb y9d1RDrDwR5r4+zW+AKRQ4SGSJTOjjRLH7Cm6LOieQWR+vmtH78j+v4fIkck3znk7wFA9x6WtIZB bP2ASE6aabyFSFBnrJQ2Q3+hGsmXPlPBPYz9h6ueWHG+3/hY8domAGfMC9XNMsWwFJ8rLhC4jjoZ Ii91nraKr1B7iGLZLTFpa7ImJnBsgXY3gwSnF9RmfojlSVNfyA8xJ9fM0vwkzuOWyaKgkcN1U1tM QkHNCnFBtPTpHxI1ioRXXoieIUQVrXwLgI3nCU5JeSmOLr44/lTBPjTYNUCTh+AVPok4fn2IE1HC npAlPdQ1WdMR4Tn+wYyPf21NHkKzv1AekmtqaX5yW/4i7ojjFi1u6aa07qLtomefF9RurLquU4oE NRNs05xm5Brx1ZJRo/A5BxWfk1i06YvP+Hjb1gUMUw14iO6XVl2C5/oO5DWrAOmNCyDTV8j7d/AU 8Q1eiIb6rUvonOPAOwgR5moT4spSMADf4H1e6c7EQDDInj3uG2O7wnxtY8lkXQkC2I64ceJrwW2T QABQIASAdfIM8KYTNiGg0phz89LGksXBhlLsaoGepH94F0vYJ7Uz/1qobHeRe3gGgNdd7rvoGbuB Ky6cEgFl2hqasLd0EAXlieklcWxAjJMhKnxYG9LtIa7NzBKf7LIma2IiHg9mHCldH9NDZvrwQpY0 b9Sy+9mCbabieMZ21S0vriy40uMCmbH/JPJd9OwXXOSCXS3aNgGdKTdLkGjBdno81wqA8BAxIAuN 1/qQqCCWeKhrsiZXAeZ1N0NdQF6xJj/kaPsL+WFzDUO2HPyUaMlUHbdo6dst7aPtIlQxlLkwZZS5 VKTIxZWu9ekqRi7153bzSTrIMhfCmB3r0N8C+OL/48nHNsEvqp2ZFz29+g+nE9iEtU5f/F/+XXzv cZWf/LtZB0/ze/e3P/3ufztd1Gb6iwJOF2GbVlSmew5SqWKdRx2c0RPJ4CEH430HqYCtVCTueUhV oyk96iKliS0e8rHc9zFuZcqMLc3gMcvEedZ51MOI/k4GDzmY7zmYEasxMQCut7dyIC2oR6oPuosd kFcA6bC767VrIH1K7/1tbJrXCSV7veG1Y36Y15zVvdeNbjeopF4nJAevcHe9Fmo9Ld3rz/8BXiKD iwplbmRzdHJlYW0KZW5kb2JqCjkwOSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNv dXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dz MSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsw LjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDE2 ODI+PnN0cmVhbQp4AY1YuY4cNxDN+RUMpWBbzauPVIAhwJm8AzgwHA0sKZgVICnw7/vVSW63NJ5d YLdYrFesIl/x6G/xY/wWZ/wuKcd1z/H7P/HP+DUm/M7x++f47sOPFD//iGlpMW1lavEl5lpUvom8 12lu4SZG3Ii3+CV+Ys9z/OMDucnkBoNNa2P9E0tpn6cNmpzWKeH/9SXCGf1sYRMhY0jTRdfduq5N 6z5vrUYRlmRdycy3oA5SvMYsPgarWyzzlOc9LR1ZMo+e1Cm8m6bHdXWdDZQf0nRcyDOmyjzHnDmM 1uPJtccLeYj+0GNZBbZKliNaNwtuw0BopaSZve7jls8gWjbnwaMyTUTUV++n1tgzylfQ4D1IluO/ /7v2AWuvy7vFNBPRLAu0hixSfdX3KsO0UV+RDANat/iM8Z3GNcWlLULjdVcZNCZ5WUFjmiAysgbR eEthqU1AyxpFBohkOGPQJo5ZFkxcStV6gXOWqV529uUY+H2FQexcY+SbZR0HeMeY/CVQbFS7HcOy YmgeKCGyMdlimxNjSilxIRnlyzLwjjFZMQ21SrGRnciKAd4xLMOZYdZdYitrbCwjNpLhyzAuG2bZ BFP32EiGO8wb4x0DXywbpq0SG/aQxjJiIxl4x7A8xFaFCKUhHpaBIRl4x5hs4xTlQcHOQDLFRjLw jjHZMFl4UBbMG8sYh2TgHcPyEFsSHvBcsyxzTXjHmGzjzMIDzptkuGMZeMeYrJi6Kw9SiyIDA7kB 7xiWe2x1Ex4Q/0UWvhHeMC7bOIvyAIVWSaZ5Ixm+HGMyYRJ2jF+eGrlWPjXaXOjUoJ1Ddp0U12nH zwKaHjV2YtiWjhNPt7sSi6J0wwnWHvZbU2F+7LAwle/f4g+OXaPhhL7le4RHmxMIe6zbpF0jvAXX 6b6cekAocsned07XDJmYLpytzporjno7L8y77cUYOcmAWM1+rJzNbETsRT7lrrN1snT0rMYVxHK2 s2ZQGchtTgocPeGXR8+BQHTtsCxt0OH4URWSNCNUkdHMp8x1g1lnI9KlWw1SMEocTqYNLMx2MplM RQK52MlERtYYqyT87G6Va+IqKcv8+m5lVbKey2RdkKXNpaxVxs7LNyxsWZI2cDYRrhj4ZTp4OpQK gM5ed+4amRjYDLw3XWe9abon1ww45QWd/+5fCZaDR6Uc3PpNwzVDPq7zpTbNqYI2xH6sF4rBp0vq hVTHetkGepn/n9TL5qtj6bjCc74eS6iD3MbW2BV3r2oHKvWrWopSHEwlnx/X9cy1Ovh6ZrNhuiFz rY7xFmcVY3c5OhlO74iyKNczvyOGE6Hqhruu/UwYdM52ez7gXBa2r8b2VW/8uHcqtVcssyaLvZ63 Arg/0x0u5BlhR00xHuO1ZTBn7aBzmFudNP1IybZTDmzP9pZAzdpx5azy0E0DXyfdQxpnO8aTeRho jOm6Q/deFXjiKLbzfXWdcRlW8joqRvja8/YTYtApw7ume3qM9AdODYdEDcpw4pTPnOuc9RjbMhvs XNftwpn3WFVZfOM9P9UnvMNn/4MHel7w+pLLNIZY5kA3r4TraMxtn9IMoe58l8sN24CIWG68W7Yd r1rvJDtHUoMuZkSMhsa2TXuFdYdBg3sb+xSRLG1A7aTQHMmh8WWPdhp8G/AsWMJHAgmQTfDIwF0y VWTb5mWqZQc1UNqvVNg2ngFCkVU+H5E/NzbLf5H8S+W3Qm54V4tIsRbJXzQBbXQ6khrsky3RaJa/ w/juLj5Z5JniAQOZ8+RQaI70OCV/gWrgni3eBVPGiduzDV2FbGes6wxm8xuRG02znSHQasOEB5+x WiIiMtzgabXxuUE7Ua8EYJ7M1GCfbMnWstoKYw0lxD6ZTFe48gGFXhxN1nnqcWq2DNXAPducFrBg x0L62qoKE/CMxwvmLBmIGxpzWW1t4QGR0TOnsEjb4mqLZJ1YzuRIami2sERDYx5gnBB8BuqEe/Lp A2onheZIj1OylXA08IZnzY7PU9j6UUULrW3bKqtwPJgKawuqgyygOq6BQvS00gc5egzp5zgcTlhB toF3ro/UAtvQVzz+ZPf+Ql9P6Bf/UD8Jw8Pp5SW+u1xQVfB1+RT/im/S24iPcDm+qSY85bfh73j5 Pf52OdYnbTV4teZpBTvvBUh0ZZtHAyz41EKAhwIs9wMk9qR2P0D+1Eg2jwaYM+2LDwaY7gXY8AWV qMDrjmfwnYkcKLJPbPpguBv4wUOUwri70xqEAE9ggK37x/8AZ5dj1AplbmRzdHJlYW0KZW5kb2Jq CjkxMCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQx LjAgODkwIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBl L1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAw IDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDQ5Mj4+c3RyZWFtCngBjVSxbt0w DNz1FRzTIYpJmZa0BigCZEtioEPRyehLB78CSYb+fk+SRT0kRVAbsKnTkSJPlF7ogV5owruwUMxC rz/pG/0mxjvR6zPd3L0xPb+RxEDKwSudKYRu782W2U/q9kaqA9rpF51q5Ike70oYKWGwmI9a8etq SQo+AdE5esZ/OxOC4WF20Wc8MWPJjpFh+8DUxzylwNSMZabQPBOlHsuQjeQABwtlTF6mzMvAgjTX Iyiid2TktRk28uqsz5Dh5zjXVBMEM0+RmkwYWUlLP43cDRn1OMOswk+QjbjrYKz9Qi+2vJgPJf7B owvM1Des75qzijpCVvc29tGwj6yODL02NNgt2lfoz391Ve8EaoLH7M5DzY5hF4yHZi/tl9B9pqdh l7zWkqnEC4dSfGCI94Qc6yHzC/rePjhakjNpQGXlTLWBetZZneTkeZoXTC9lWnLsJrY7q09Z545g DLN5lkkMaszKdIquyjPYF27o7B6zmoVpCx6TJTXz7Hm6IjpOtVVRLRzvluBRSkC/8IxqVYPnJWWo IPEdhtviCXunKn4pFEGh1YljuYNO4wbCXYM4jYQVGkkbqdxck4OWtytxHZRfWTk2j/VMN+uKhBBv PdF3uuIvhJtH6Eq7cQ3oB6339HV1D38BAx8DLgplbmRzdHJlYW0KZW5kb2JqCjkxMSAwIG9iago8 PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+ L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3Vi dHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01h dHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDE5MjA+PnN0cmVhbQp4AZVYuY4cNxDN+RUMpUAjHs0+ UgGGAGfyDuDAULSw5GDWgKRAv+9XJ9nTs6PxLrBLFovFOl4Vq/ktforfYsLvnEtcthK//x3/jP/G jN8Uv3+N7z/+yPHrj1hrjW3ZTi2+xNqyji8y3tIptYAJMfEkXuI/8UusZem7ptZ30dgYmckmtCsF 0uiPj3R4ocOh4mlprOc7HtU8n1ZQ5lxPGf+fX+J0SvjJNS6nDT/LDEWNFpx2cVpsp2VLa9l0MLdY becqskqnPMeixOBcsDedStry3Plq4a2lS3eK6/AMtwhX18soXfsjpe+LeWNVV7jZ+EIprAyUNq2K qLq67tEp3Z5Ocwudyyid5zlm9UOnXWL3V3a9chYnBpc28A00CQO87zSLWnSLjBLc7uceR6cZV/fO kfIMWH4A6Ev4+RCq3DJxOKPKvWI0IN/5AEiC3wr0OZ/TRj6BA/NV8VTMSoO8J+hoqZdTi9OaOPUy 8CrjS+TxBjc3wICZbEJJlONPzp9wK39yqpw/LU/7/EmTIpAUE/d1EvRykoSN8p3TaF40B1Z1BZQy TwxYM9IlKEgn56qWM5CJsbmHQO+Tm8PALI4CyghDDiRJLkwdXR4Vx1vXr2P1yHWkUC50uRZbMlyz AP7K+SaHn33p/nOa+1jxX93rR/wjOG6577tDuYv/G6gQXMMmKzgDrJXk6AeXI31gc9rgIUM6ZckD 6C91dfTLWNBfpq2j3ycPo78s5YD+He6pvppXgwC9DYifOtan2FEUJyrLBjwg3JCNvRivAtiVx/KH EVwSV3PDLmBkIgrgqwUmYtxPClcrey5CJ6niMcThgsgdlXksi0miWdw16ZSE08fZa2PgLHCdRRU6 3N6Gs8H/rmNOu8pJPrG1kKfd2s4KGDtiiSI31tCCxqDWhVEEoAQZX+CgLdYJJ1ANZSabjCi62YMU gJh6kLpkQlHwHiRtWrC23oOMNMeUtR7TalXAOo6tBbUa6vGFsqHJ6ShwmgPNehDwaUeAHo1L87QG p0hVhV7eS+Su65HrQGHo6m2leLWZdB9Au3cfr6GWUGlIvUbw2F8M8YUXBLt22m5tRHAZELwZgh3T oAwI5pki+DC+i+Cr2FP/6fGSssixNyu1em5zr5VbfB3NWLuNZrrTD9lEBZF74Xnd49BCi7Jjd/lA MhQaTNJsIESmMORaVRBmJxwxCOEHDHKd00gJBtN8jUHwHDA47hOk3qKMGNSbjpLXsaq35gBENcdB Z1cycvZIe4gywlSle2jhLbn/uS3TLtiPhKaCFG8MiE3Lb3W2ILAEk+SVFl18lgm8qBoYi5NeI1jb QJu0/X0ASB3UWfELQAz3uipC8TeL9Kqnb0SHvtMGNg0uSbu6/ckZVLfvI32a9/d2tg8pOtm8IIeg QF8jnb5JpWk1pC92kxvSl2mEhkQYTAekg+a4E5kQ7hTTYESs0Y5cNyhDhlhPB5i5fP8+6jVXVH3w iy94kLz3PFKOUKe71SK+a3WtOJsSnc3lH6G+esDMHMe+2XzEet/kPBZ2J9wv4FY0O5TMJME1IjuA 2GhDkntbO7A5rVv+QKfLTzAnfAEn/4OHl9KmOLdGnQlO4AlQ3/BwUhoePdI0Y3mh5dJK0CHqWUun dWN2XcTbTvOdNGGZzIkJYjWBe9iGjGwBMnkR4onTD6RFzEk13+l6UnXB641bQaOAZxwRpqYAMSlP sHZG35TyBjAVaHpFepJDKp+n9ld8q8J+6GbqVJbJ4mU42m+LMFl3QiZNWCZzhpnwu7ef9GOfgpOH o/22CJP7Tpqw08R+UUcVpw1iGn2qXFnrpCd8J6IZTHzeC01CS/g2aQhyxoMLR7vhmx2a5YzyJUOk Zm4SbV/Eu1rfSROSiQIEzjhtwDFZ69uIojJ1SJx6oC/iyaHvJNXUL9wiszqquFvbElrteRfbTkJs 6Ru/IeEaXwE02cTaguLG1taZ3hTBiZIsQ8ShbGKtLeIxpO8s6OpZJiGWV2aNrW9DHphMGYLTD7RF 0kZ24jnA9OSb84uoI4fgGRRWc2wrviMbPiQGJHcSxxaYZUdzbGOBQfvYlpk9SLHV4RBbX4Q7dGeg cKpMiW1BLdjHligaWx0OsfXFDar5TjTBoqcgmdUxxd3aMrfr2CoJ1fEJX1moHImDBxfxBN9HVLcq REjdAkKhWa3IRhnSRYculusWU9Aurli0nTxhmcyJt+NVrPVtRFGZOgSnHhh8EV/ivrPrKdaKOqp4 w3vbtlKdo2zgvG3rxKTQSUAyyhhe5sBQgC1GA2KIR3R6gNMn9MqljnlwSQlPYx5+5+Zn9g9nvODx Azf+UW2EjyH0/BLfn8/ABmSdv8S/4pv8NuIJvMQ3sw3etbfxczj/Hn87X9Veer+Hgvii/aWCKEVX CgY2QnSCnGsFUYMfVnB+Gz7H1xWkypBQLO55sCWEl3i6B+8r2DIwhg0PebDcV5CSOSG/7ylYF1Rn 4nlUwbrAamx4SMHpvoKUf7/yYJkB0P/jwQJgP+zBek/BtqJXkGRaTvPdXLEk47xj1gf9uaJk8xHo ImnfXbcGSaF3SCYD5qf/AJFbWnMKZW5kc3RyZWFtCmVuZG9iago5MTIgMCBvYmoKPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFI+Pj4+L1R5cGUv WE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAg NzkyLjAwMF0vTWF0cml4WzEgMCAwIDEgMCAwXS9MZW5ndGggNDIzPj5zdHJlYW0KeAGFUz1v3DAM 3fUr3pgOUUVKsqU1QFCgWxIDHYpORi8Z7gIkS/5+H2Vb9gUBegJ8fHwkxQ/xDQ94Q+AZRDFWxftf /MIrhCfg/blxAY8/zMyPueHbJmkovlCjOXgZs5svSD7Yr6LgCpx3JvuxhpITFmEQJJTNLWGGLkhc whkxeA1VBhpFbVayOjJC1xS6HcAXorsy0WCht3iq7Y68X6apZwHKe05EbsvPmKM8Q9bMjTnvRUUl Elmzv+JcQ70TRL2DPatdE5jJEX0lO9Y24wV3HKzi479TA6fW2y+BY9tqckSHKiQdOBAdORu3xrVC KeSeeH97Wn7ILvDD18MPH5SySo2jD9mcGihechoIopdgQqxGq+omcgQafKmZ/d/IQLJ7GmgxmyVB 9jXxjWxuTdNjZgs/u8OFTbNk0z17ntbQ01LAXgpXYknQrnUXRE5YEmu0fahS2QQl9Un1xKmYQaKB Disto63daVk6xx5F2shiwyG3EMLmmY3talvMuwmckB3+2a25OUwXfJ8m5gJx0wm/cSPfwIVV3Iyb cEvVH0w/cT/h4R8KV8grCmVuZHN0cmVhbQplbmRvYmoKOTEzIDAgb2JqCjw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4OTAgMCBSPj4+Pi9UeXBlL1hPYmpl Y3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4w MDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDQzMz4+c3RyZWFtCngBhVQ9b9wwDN31K96Y DFFFyrLlNUBQoFsSAxmKTodeO1wKJEv/fh5l6yNIi5wBm49fehTJe8E9XhD4zKJYVsXrTzzhD4RP wOuvYgt4+GpufkkF3xRJ1uAzNTFmL0typ2dMPtgvY/Gr/Rb8S3fpfskva8gJ+3cWxCPQ5ZqqanCC 7sruhQti8BpWmVskopZQOZIm1xSN1ak7Nd1Hrw8aN8RpsMPrUaqFxdTp6NTpUh7IDxY3yCheUksk uqBfghKJHIW9txVUL9Ayti40Vl0TyGRE/5NP+O1uORyKv592Hux8Y7r2zrd2VZ0bKpKJs9E8iEZb Nls8qpVM2yO5lFH1M2eQL2cvG1AN7L0mH5IFFTB7SdNMkLwEClEXM2tgf3aR7Qjq85qqxhHT2CIN lJzFk4BjONF7CCO/mrOI5rkfyIk7jHZ2i2w8ebk4lyqGF1dsJ3iUEtltmVhojAtLXXkJxt1UXLmq emSHDAkdyH43y2JrfO5LHPclNR82vKSQ5IqP7X5Z9NsNsgN+eMSkJen2jC/bRi7Mtp3xHVdyDf4B KK5yFW7k2v3A9g13G+7fAHKD2WgKZW5kc3RyZWFtCmVuZG9iago5MTQgMCBvYmoKPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFI+Pi9FeHRHU3Rh dGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9y bS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAw IDAgMSAwIDBdL0xlbmd0aCAxMDkxPj5zdHJlYW0KeAGNV8GOEzEMvecrfITDDnEymUmuSAiJG2wl DohTBcuhiwQc+H1enNjJttuyXWmbvHGc5/jZk/6ij/SLPP42DrSXQL+/0Wf6SYw/T78f6M37P0wP fyh4prD5JdEjhZz6+NTGOy8+OUyqkUzoRD/ou3j29Ol9dROqG2y27EnwOxmFsC0ZSCjrwvg+PtK6 +Popbl8KPnvBloqRYaeBpWUvPkemNtgCxbYyUxZf7Aw4gnHDhtGJol+CL7wNLIZuZc4VGbSOpNig 9RJkrHNchGnGednKEIRMHKxCo58Hd0NGPM4wi/AGciTWczCr0zguNlqM3OKDxCoJM5shO3oz05Q5 i0cRsqiPI4mGXVopMk7rCHW9hXYD/X2RpDTUdtp7dlXEPS7FkAKFWEOdzAybzJoYxVvs3rhj8HYP glo+MUbiWKR84lb6GEmv4+RRPlUBMTqb1PJhhHe1cmLcpXJ4j08rh2OXYymIsx3ehGEjw1rWklWO FkCxyoEKRQoluyE1wyrpp6WDlV3IoZcjvBvSDge8rATQdZr/cmn1DDKtC77u3so0qMjS4BPWkWOM J/ZnT0wJYqVl4TCzVOMUAmajFp48E8teABthZufbpZ/cQDyYzLNr45sSP8u9Q9fs2o3U9Iw8TOI1 bIqI19kCs/HMsaw2Tdf2VNVc9XjRwZVL4rMObpqrBWJhjvowqLfYqP1bVXghwkxHZ9nSGr2Q4IUC UXuqk642ODKo9/NplVK8sWi0sKFB0kbnrCasGRprQ2Y9aigXViPaaZ0qdG6/lv14o3PjDW125u80 Tt0wy4xGNNKnbRoVbFaKvQh5ka67lp7R9TOyruq0uKxNT+pXbI7f+jTsTOea+MveveZ29an9Wsbw JeNSrz4gUBv8qpPau+VitWy469g/XKfCGtCVZA02lklYOK0b2g0v7Ff0jww+uBCtXoeQSsxLLql2 tPYw1rtAW1kfYiI+xdKFHfW+VmtbBkR9tiEsbUN9CGq20ngi0XKTsygkHlzpGsEeCmTneUW0oWx4 GxWcSNjPIXdPMaHKvS6SSY8iJgxq/MlLiLG+ldoQtbqWFr8+XItLXleuRX2KJfLQ47dlFUH81Wcf wlI3bIir1MbKwbPF3+h04glqKBkHnCCjDdujiPL6BII+WrSMSzO2fpTQeUOSke2xOW94gzVmfThF 2xCHMGislIn4bNFyyi3bFm1F1GcbjmhxwegPcSGxlYi28xzRGnGLlvftLFo3oHtcxkJJy4bk407f 1MB7/UFRLzL950QUgYgN2ocohpPYuPorRH5yvD0Qtwm+6gsdioPTwyO9ORyQAfg6fKcv9IpfE35E BHpVdHAH6Ks7fKB3h6nuRLEovoTisbQxzvE6zymdeRHTQddJSFfo5q1vgdZZ191k7Rr9uwjW9F/W 9ayvscbpSYBdhLzv56xbIv7DmtFGsIW7ybof+l0YrD/+A86e1mYKZW5kc3RyZWFtCmVuZG9iago5 MTUgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4w IDg5MCAwIFI+Pi9FeHRHU3RhdGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAgUj4+Pj4vVHlwZS9Y T2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3 OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCA0OTQ+PnN0cmVhbQp4AY1Uy24cIRC8 8xV19B6MaV4DV0uRpdwcj5RDlNMo6xxmI9k+5PdTwACbhyLPaHeaomiqm25e8IgXGL5RLJZs8foN n/EDwtfg9Rl3D2+C5zfYvMAmqwMucM4d9t7s7LQJam+kOsCO7zhXzwafHoobW9xwM72Eit9WyxnR iYiTqIXf7QKvDR+xatGZT0rcsmMY2D6xoJdskhc0I9JbX5m6r4FslN7AyWIYRluTJU7M2YM1vHdk 6trQsanrPchcpyRXqZkJGyutrWL8VGWb/Dy1D2TGowY2IvwPskF6HgZrx8yXDF0iRyb+wcMVNrI/ sH5qakTUEYy4t3mOA/ub1ZGZr40Fds/ytfj5rqrqkaElPCV1mdnsGE9h8KTn/Io3sGteK8lc/LEP SulCDoz+nqixNplmXZrxx9ZysvCES+uUnqoDryX4qGozGM9qNKFMO+GvmSwdikg5lOo4Jh3NtrJM clB9VqYq/ZV9Yc9lPM/us5qFye5rGx6TRdpY2XWqknR29YiiWmzvJvAIJSSjcypb8tglltIOyf8B qSeCzHDjiY7k2aiNeKaJueA9dJ630G/rK5UF0ahBVWq5w+qFdb9C2oCfkGLfItYt1gvu1pUx0vd6 xhfc2BN4E1ncmJNqxq2c8BXrR3xY8fgL6XoF0AplbmRzdHJlYW0KZW5kb2JqCjkxNiAwIG9iago8 PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+ L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3Vi dHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01h dHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDExMTc+PnN0cmVhbQp4AY1XPW8cOQzt9StY5gpPRI00 M2oDHAJcl/MCVxyuWpydYh0gdpG/n0dKpGY/vMkuYEtPFPVIPn3sd/pC3yniu3CitSZ6/Z/+oW/E +EZ6faaPn9+Ynt8ox0LzGqdCL5RT7e1Ta288xRLQESPt0Im+0pN6jvT3Z3GTxA0Wm9ai+IO2cpyn DUiOeWL8P8L9FPHhJaxTxWfJsmTHyDGsZliZ1ho3Xqk1FrCzmZv5cuRIqYFpWJ1ojlOKlZeBzUmn pu4U3g0ZvI6ODV5mdQ8Z8wLXRhUJ85kpKRkerFKnP7g7MuIJjnmEd5AjseXBrU408sXOi1FdfBLd sNtjnn23swoFj8gQ8riPo46OXVsZMvJ1hMA+Qb6JfvyWqiwy6gnP4WVk0zBUwe3Ycr6zc2xv1yUp /uaeKe4Y/D2CI9/iyOumyk+o1pny49oVVtmVH9euJ2CmfGAt5Tmb8rt8YdTCiFtoUQBxoUBXWlt1 dSF8YF2GPJwbMmi5gHnQMqt7yJhnhaxD+ExdJvlK+NVKBZtOfhePCf+WVd8KZ/O68HeYlVPy1YQv vLrwb9oNHidPvlNrakUdPSBDTPcV9K+x95GRrru6v6EpE0LXfeWhe3YMwbpd13iF9jx5ju3tmsbr 0D0ujY7Bn+jeLo9UIdWy6uUxJ2vLiYf2gpULJsAoeEcuD9k1794bqbbdUyqf7x65x5q8VzBrGd1h WMixtnuK1Q93V59oh4BdEWB2vXtWuLrcPX5J2O6Bz3aP+EYRV1fYbyG7eSnK4t3zUJnTSXnUDu0d +YsRr7Ba2cYI6Fmlkbs5oTc2w9mYWvaTvxB6nl3TfhhIdNXDK2LYj+zbdzV+UfmAF0PTLny2cxxq 22nXsV1ELG8Kjx29MRZ4k7F2kkPRG8ZEy/pQmha8XfwPnkdckWkuouCX3lkmLnlBZ5445iUkbAoM Mx5XvYmrt8Zpq0Xm9sGIps+UjvpUS3QgzFwyDgGfBn7mU5ti2RZUcx0U920mBp2nJPcpjCi0hSda I9hDwSkYOSPalJZpYzkNE5heQI80cw4FF5nGjw6VtUr80D2WlvipbFGGZ5SnNyFk7oH4YPSZOIGl oz7VEp1F499NA2I+W1MsbUEbFGo+U6h1n3K4KB0jLizqhnKUuk7zKtGWLZ9BeN0+UkYiZhw4Gm3r pFbtjK2j0c6oAoazvBdbEwc9iqnVbkhAH4M+UzrqUy3xgIZiUe3dNCDmszXFsi0YxFwHQW3MdJ5a 7U6nE/do5e0d8ZYf0YYBPeJlJcWfETP+tdIjKvxAkKO5/zyYYYOUiQ02sMoDwYlNkF8V+hPi04FQ UflKYbG1WCccXujj4QBO8HV4on/pQ/qD8KMg0Qe2xgOg/8LhL/rzsNt3qlhsvrJB3a1sECnK9j7P s3Kq6aAbNKR36G4QkCyxRNYl7rIOjf7DDNb0S9Y5pqkg/bdYI3saYBehlEVNB+tWiF+wzhGXbqrh Luue9Adk3Vh/+QnxDcvYCmVuZHN0cmVhbQplbmRvYmoKOTE3IDAgb2JqCjw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4OTAgMCBSPj4vRXh0R1N0YXRlPDwv R3MyIDg5MSAwIFIvR3MxIDg5MiAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9y bVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAgNzkyLjAwMF0vTWF0cml4WzEgMCAwIDEg MCAwXS9MZW5ndGggODE4Pj5zdHJlYW0KeAGFVj1v3DAM3fUrODZDVFOWLHsNUAToluaADkWnQ5MO lwJJhvz9PlImpXzfAXfUE0k/Uk+S7+mK7mnCd+FEdUv08Id+0j9ifCd6uKWvl49Mt480l0o5lVjo juZt3u1Ts+clTiVgIE46oBP9pRvNPNGPS0mTJA0eFmtR/FyteeG4Aslli4z/4x3lOOHDOaxqTAmP NIwcO3WsxLpNaynUjAUkLLK5I5cjR0oNTN0LzKeYpo2Xjs1Jc6Q9KbIb0nkdHeu8zOsjpMeFNKFV HpOS0sCzjE/KnS/sgf2LGasqqBdbjRiddiqc8SCMmFuD6fmcjryDGFnPg7MyhMD66PMyGmdG+wgZ XEBkiZ4+XfuAtbf1Ip6w6laTjIYqUMg496xCXmVubmsXMDrRNZ5vMs4MZZdJZQzJ7Ta0JDakOBUE qJMNRMZMT+FdBefUFMxrfqHgSjVu+KzCae9Kx7BfHGttz7yLrdJsgXtDBmSQgHnJ1muCGfxcVJ7c EafVhehUw2uv18gQx5tS3dA399sFk4OzwopIJ7a+pI4M9TjmC29IeIVAgF3klt1Fgj6w89oFn0QX ygL98r4aBv6tUdXd+vpYQR2xsoPvg0qGvfZ6A/lwZ7zQ1LAzKrV+q6a8KY4NhbE1ZdwrbzSAmxq2 Yd+QY2336CURF5zb/oOrYa44aLMe/bgTdFAjl7xgsESeYOSMPuM0kwO+mVBOneO6FZwvNonbJHvk HFpOrC88MZPjluE9hGHbWE41xdMfuE8KtRYZOk/k1FvJq9B6cD01glIKulDWKW6rEFxgLKLsgr0t UOjQNW46LHnVMwPbWwep1S93oNbPqBU581zgqSbkMrf6g0/OmPRIGWhO9cShhLWV+i1MEcuJSZjH 0B/YEGXTI51nq7/R2Yl7tbxyrMuGvWHVYoMphAZcA4R2rCsZXUloF2eIgqu8Ncgpub8zeHzGIaqu WJTmWoK6yhuHvl5cHORsly/+yrrYI4rGHe7o6+EAosh8uKFf9CWdEd4bkhihGed8Rr/p8J2+HQZ5 6sJCo85aSknvsA5KxVnziltYXDvrVuAnrBn0ERc+ZL3TP0chxvrqP3aH4zMKZW5kc3RyZWFtCmVu ZG9iago5MTggMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8 L1RUMS4wIDg5MCAwIFI+Pi9FeHRHU3RhdGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAgUj4+Pj4v VHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEy LjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAxNDQ1Pj5zdHJlYW0KeAGN WD2PHDcM7fUrVPqKG4+kkUZqDQQG0jm3QIog1SK2i9sAtov8/TxSJKXb3RusD/BJHFJ6pN7Tx/3w X/wPv+KnhOj3Fv3Pf/yf/l8f8LP6n9/8x8+/gv/2y6eSfMllyf7iU92l/drbZV/W7NAhJ+74V//d f+WRV//HZxom0jCYbNkz25+5lXJdKiylrUvA7/PFb8uKf2Fz+9LoX8KUavNmex22vOxtrVvxvVF2 nzSy6lhmOfvYjXF4Afm6xLWFMmwpcmiUQTG6Wgaus9kGLvU6sow4F1qHioJZZIwMZhuoosAf2M0y 8nFmswwPLGcftA7m9epHvYLhCqEX0d/xm21WffPTVXOWkVq85X0e62i2Wy+1jHqdQbBPoG/0/z3E Ks3MS8GTu4xqqg2rYH5Baz75mW32E0rSeEk4E8SG8V6A0UTUms8Yg0S0xSRtMJnaETlmokFrzjok ooAM39XPthbWT972K/0UYeDegEzqN2yYyGx94VJQ/TRRwV61GqqLvbrBt+F1ox9EGpttdLP04gDX 0IFhHXHqdccyxQlnKu0+qlhhW7rRTx0rLhytfspHbe5aP/fjrvVTB3tQr64fwiX6iaqVN346J2JF P2342QppRs4smjfw39oesKD2B/q5wyrRRRH97A0c1jq5rh/YTBfFi1bq5Ddss19faPYT/TjRD1Vq 1g/kE9fM8gnbLm0UmNqhdPmQj7ahHneonrA2Vk9M7a161k0YSbB6OVc9kAiVmmTREvTLh1AB8Xnj VOlA0mowpgU1EWn7wTO8kp44GBNtLQ5R3jp3m6wm3VcJI7yUN2Ma45usXRhsG/j0JDHeT1734kQJ k5euL64FqgQgCnc9BgLTACbWqlmlNRfRAFboRgOzzeLM68ZyrIE73OgawJJ2vtcwuB1EA7CN3Aff TSu4WGlms58us50h4VoDdB/jGxkIHkroIshJ2qgtt+OSMx0i7CQd1w+Rqwvd0TA7dlIdRds8iDs4 iUKIrKXQ8pWWshAX10sTU9ZbVARaWZksItq0YWpCpNW+lw+Wia9muxEU/KCDLk6Ma8rh+Lk3td3U xizoCYdof0NPmGj3s6xsxdYj26RZwLEb20MWu5+ZZhq2i1GF+X5ms83cEwURZtub1KYaAnK9a9oa WK56soAKZrvxGiOZz+HJcoclmpMoCCszqUVuZsQS9VMFTSeQqWqcQNh57BY2VOXN1k8Wfv4sBS8S +w+PnhCpMHygXKiD+ytuVxlvgIBbWljRiLSqKAxubtLEgsWw1JY3taCPpkVSh8YEJfqXbWkbvKcw lFfH5CZ52oTykaBZJEFjnFR0vLcsC27h4dUBSirYivGuQrYRd6VWqViA98YEjr0gqOJ1wJsA5U+d pPkjHco/VIFjzY6V8+8fHbDPkdThMdkTnVXz33rZyML505jcJM8+obOPhMYiDWfPP0QKFeCWbag4 3bHfjWwxmppefNo3X3Z6woJ4vVMpW+wWO9KmbMve6HPaozaxLewrw3b2Ea/o3SKpw2OyJzq5Z6th bLExMw1/dtOEbOloLNJw9mw7HAGeqSgVdCotYv+lzSJjjWYTCvCCtwa2w8SLR48Q6mC/pmw30Jez zYn5ssUVH4WxG854Xlv9GOoUyR1hLDzxBfwibk9hvCoY09FHynaeUD4SGo0cOHu2HY4A12wdgC81 8Can2Q7TC16HRPUNVCeZMPfDTn/koGeVnIhQcErdB6N3n+zYh45cPnQ/nXzoHfwi/ewccLr4j6cT VIWxTl/9X/5DfPL4w0b0H5I2ntOT+9uffve/na71ia0GZ0utSwE7jwASXdnnUYChJQ54COB2BDBD +kKisIDqBzjf8I1dH4Rbi05ReIpD1K7X9zk8+ffLaqiJDAn8uFddx0trqLG/d9eBujPlHRYo6pxX inOHqIUVz+CHov7yP+wZ49kKZW5kc3RyZWFtCmVuZG9iago5MTkgMCBvYmoKPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFI+Pi9FeHRHU3RhdGU8 PC9HczIgODkxIDAgUi9HczEgODkyIDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9G b3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAg MSAwIDBdL0xlbmd0aCA0ODI+PnN0cmVhbQp4AYVUu27cMBDs+RVT2oVp7oqUxNZAYMCdYwEpglRC zil0AWwX+X0PSXF1wCXICTgtR7OzDy75hme8IfAZRTFlxftPfMNvCJ+A91fcP34IXj+QM2IYfMIZ Eqfd3pot0YfktsqpNjb8wqnqBnx9LCJaRBjKT6nid9WSkP1MJA6TF77XM6hVftFNPvM3KiN2DIZt B5b8lMMsCc0YZwzdc25ayRmyQhsoB2vDELyGTAnjDbrLFZCd6Yqru1z9y16Lj+TmxGZwpVpDMGyP pXswZxl1BBdZGnbNukLcCunVmd+G3gUMYhmJ4G+MjnEzrZsdOzputdi+WK3rweqYu2ZdIysH5oHD qPjz3ylxnBKraW/ywCmxfhh2Ubvs3b7kdYzVmp7sW114Qx0fHoWObXhhjvXI+JFzbH88KKIcY2Vl yfGI1EXykuLIRfQSaEQd+ZnroZvcMBU/5xQ7wjVN8xTXNDkS7Yv6HMm+cNNDs5qFaQH3jyW15umO PKlZT6lVUevhcW0JllLYBQ5NkMhqIyc3z5njrFOD3AG9cOfKKpJQqqweMpXr5HRcJqybcpVD9cZJ lePKHVQvnIcF0hZ8laipOixn3C8Lc6HacsJ33OgteIkobmI37uQWP9zyhC8Lnj8Brkf3pAplbmRz dHJlYW0KZW5kb2JqCjkyMCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8 PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIg MCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAw LjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDExMDg+PnN0 cmVhbQp4AY1XPW8cNxDt+SumtAut+b27rYHAQDpHB6QIXB0ipzgFsF3k7+fNkDOkbnUnSYBEPg5n 5+M9cvcHfaUf5PFbQ6R1j/Tzb/qT/qWAX08/v9OnL78Cff9FwReKe1oKPVOIex9fZJx8XnxxmMCo TehC/9CTePb0xxd2E9kNHrasRfAHGYUQlw1IiusS8P/8THDGP8Wty46fdcUjFSPDLgMry7r7LVH7 XzdKunFTV4acKTYwDKsLgl6i3wPC0J0pdncJoY2nnt08uzU+856wi68NpcAsRnkCvOmjYnvW5iwg RWgK0rCj1QFxZwqanO27kBaBUrCIQqDXLBRDL62Yio16Wy7WFcv1PKwUc0erI3IGXT6DjJH+e5Mj DhyxnFqRhSNWD8Om3EOvNrhkdoohW/MXGsE2tkvCHkhBsQs9IkaVRNpWKusuksgR9OMxfMl495AE t56NdMKSCMjwphrSHkQNFaFBDZxpq1WoysFqapgxVQOw1jhItHdwV1JX18lRDRlMiwMzOUx2KUot VBRxhw460hVZ4euIvQMBa81KOSOa6f472xBgU04dzO2dhLpUS6acgWm/7yKmnGFlrEBNXyhH41JG KXtgp3Egfqu+Yl0HbNXOgjh6a3mrfmBlmDFAkeFJEdT+jn6uWMVnrDLBda0wq6yahk2ZqVZmO8OG nTOtmH5wEt7RT8xDPzLu+kmlXSmiH5mgpu/WTynby9sk1H6b7PtRP8AO+ilhdLA1et9G1QyZ+GbY QT/YaQxvtIB3RUZckw5awRCXWnX1v4qMfS76V5TDd7JcPmBeHl3GeIr+akW54MSq3yrQRoZ/5Q6C wywE1cOLNbEcGsjGddfZXwwhRD3xHjNj/NX4XSzvvR+3BLTUGI0+HFgObMoo5NkCs7HmwnQngNO8 j28DeYFaKt5p7A9em0JEzwPyaO9LPClLKBmy5hcdn6tLofJyiHy8yBCHECSw7SUrgvm8kyfiUywx icueS3bTNpzK6lOGbNkeKOayyNG0nVi0OLm4T25kISO8urUAeyo4CH3IyDbFsAQRDtxfQ4+U/eqq lzsQV5hfqXrYl4yu+yr5A5EAM0LqQ5DAp5a/LSbb6bCIifgUS9yrm+Q/tjECf+yzD9myP9AWVzft 5NC6Tz5eWjg98LL5Zd/QDrwdL1vlY6Js+QWEW0KyJeTWus3ZotFX2ZaMMvXI2nDKti1KgtNOvFE0 nz3bjBMG3Z6yBWI+ZTiydUUXORrbyROJU7rdCqWBW7alrFfZugE94h0tRZADzY+grbAhrPzhwC83 /bOB35pDswFzmk0RG8dfG/Jp8fmEDwaZ4B8zqsiG0zN9Op3AM/g6PdFf9CF+JHwsRPpQdPAQPtI3 d/qdfjtNuhPGQnxlQ77atoS23Y5zamdaxHSE6ySlG+FuVR+xyr67UbsW/gMS+UZvRs21vhU1qicJ dhLyWXcVdWvEG1GXGnmfuxt1L/pDGlF//R+cXtLsCmVuZHN0cmVhbQplbmRvYmoKOTIxIDAgb2Jq Cjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4OTAgMCBS Pj4vRXh0R1N0YXRlPDwvR3MyIDg5MSAwIFIvR3MxIDg5MiAwIFI+Pj4+L1R5cGUvWE9iamVjdC9T dWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAgNzkyLjAwMF0v TWF0cml4WzEgMCAwIDEgMCAwXS9MZW5ndGggODAzPj5zdHJlYW0KeAGNVk1PHDEMvedX+AgHhjgf M5MrUoXUG2WkHqqeVoUedisBh/79Ptv5GAqL2JV27RfbsZ3nzDzRHT2Rx3fmQEsJ9PyLvtMfYnw9 PT/S9e0L0+MLxcCUY54ynSjmpcpHk9M8+eygiJEqdKTf9KCRPX27lTBBwmCzacmKX6kUQ55WIHku E+P/cKI0eXw4umUq+GCzgVHHjt2O8rQUv2Jr/Z9nis1xbaE6cqBQwWGFxP0UfOGdZwzqGnrwBoys Dqi3GvWsPoMMP8dFM53Rru4ZguYycgqW/Dwy78ioxnWs1/cBciBuXehWRxrd4p4Ws7WQ3rHbY733 3a4fYyuoAdSrPowz7NhbqzeIO4BcN6BuoL+fYlQrjKzdyqjWJtex0QDi1vLTaHrH9nZ28DMYirqV to4bdqR75NgGqBRELTo/nJYqH0nl7DE/4IDYNBnj4xj1nZ0c9kUnh5f4enJ8qlOCcG1yfKq8BdYm B3Z2armPzlqHoqyVDEjLWgFkR7aO9dHZ2cU2NIgL2dqBfYX3Q9vJbiebVfA6EVSpg+A2oJlCGicC eeS0X3FvrAbdEyIbH6S2AI1ZfHeoapXQq8QyBqJfPZ+BeOSw187J4Kw7y9l3zrLnaPxE/3dcbBju 3G7HaW8Bbb+m3pWhmH2sCTf18p9m3Mf4cfIjVz6HTDwrJU9V4Ylxr0NJE3sRZtx8sAqxibhRAk9r yakiDjrE7imKxlRL8HydShLr7gakxTRRLG1DJ+a6iE2HZ89TLgQ8bVopJuGxYwnWUiKuMk4olOd5 KqsMQlgMQm4NuqeYMA9ZHmloqCmL1A+6JG/1Z0snxuKqCHLHxervi3hK5uYZRdGYagklWf07N1An O8TURewOy7GhLNZsmufI0+o315p4Xj2KzMll3A9Jq80rPAHRgO5xh0rtYhDgKf0hXuQ14GG8BMgp L2aDNMwmO7WRdwd9UbjZiE3Bn8RgddhOdL1t6DyibQ/0gy7CJeHRH+hibsJVuHQ/aftKX7b/zxB0 zCtuG8s66LGdz/NVgXLCoM+n0l3l9LUxuK3g92HWztK/4ktqWd/9AymL2J4KZW5kc3RyZWFtCmVu ZG9iago5MjIgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8 L1RUMS4wIDg5MCAwIFI+Pi9FeHRHU3RhdGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAgUj4+Pj4v VHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEy LjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAxMTE0Pj5zdHJlYW0KeAGV V02PEzkQvftX1BEONP5u9xUJIe2NnUh7WO0pYuCQIAEH/v6+sqvKPUkIYUaasZ+ryvX1bPc3+kjf yOO3hkjrFun7J/qHvlLAr6fvn+nthx+BPv+g4AvVUpdCZwotyfg0xnVdfHGYsFCf0Im+0HO37Onv D2wmshlstqyl42/6KCS/NCB180vA/+OZ8uL5p7h12fgnYUvFyLDTxMqybr7lSmNQGiXVbMNWdYYc KQ4wTKkTwYvot1AmlmJXDWIU1hWZfh0Nm36p1D1k6rmwDVeRMNOMsTuTp1dR3J++GzLjcYZZhHeQ I0onEZrUiWa+gvkVwq/laKdr2TdMq+YsIkXI4j7OOhp2LaXIzNcRDfYO7Rvp50NdpZGRJDy588ym YqiCyQXN+U7OsL2ctCTbS5KpIBjsPcFHJVFsaPSUO4lSDDLmymOcC0gEBQg5mzCJAiL8JX9i2wZ/ anvJnxCkAwtHOvK3w7CRYaNwXvlT0Xi9+CVJNqCniJv9ZhhsCX9AEtW0bjbrhozkwK/JA/N1skCl biA7PekZPn3MvnTbdEoassyCG7ILRzF3SZ/bepf04doJo5CuQZ9+KF7Q54Wc7gndkSck3zArkATk DNCoSdmDChl2LXWFIPN32HOjpyywwRR0xmSFM2yXAGEKXxeWTsP2clJmlhP2OGEPJ2rPnoBdUwud PbEix30MwvB4w3HNCl1IJ1/cb9gTttTZk0N5yR7fpCNbnrdPk5MfmLIHcqNuydijXIGUnCV6HwGZ 7SY3Urd1wR5g1stm3ZCRsG5LsemXItP7a+SaPQ3xqJye1cj1uBOrNmSblZQWbbt4rqX0Prqtd0kf 9mHma9CHMb19prWdnPlh9AnTj9H1qJDQJ+lN0/QWYf9NSvjTHkKMP+7W7XPdVRbZ4Aqqt+OFYjjD TE640vZyhu3lpB12/CHhT4M95k9/4i0Vry77g4ddwIumrvxwg+qY4AYpuWACMvi+vPFyyNnVtQ/x aMhxaVvJ0JXFiKFp8qTb7JKYlGXLkN6p8TXnYLMvwjxL2ob9DhzemKb5yUnHm9Ki4JHD43IYk1Bw 8noYwEXbypLLhhaKWLqAntDdECl9v7NMao/fJZ8l/tJtJs/PXYkq+SDx6yKubryLe+awqDZBMh9c LbgPOf6dGk45PDO7zT5kSdtQFtk101Q/+6H9LKrquEVb81W0Bj0RHreUfT8j0Xh+c9kn9hnk9ige VzvDC3gW/apDHFa+jGhtsWDRNHnCNvlRANXs/Yh2p+anzT5kSdtQFtk102TXup+j2sMdcdxqm0Ne Wn1R2wkhWhQ/LxuKH6uUPqwOnzZ8HciHDWqKBukyiLu3B57/XYa/h/rHz7sDPmn6BP+4o8BUGD2c 3dvDAZmHrcMz/Uuv4mvC50ykV6sO3oTX9B8d/qL3h4uO5a8qOFhR3985iAL+mYN4BD7sIHy+5yDn MyHF9zLI12aXeTSDGYcsKzyUwTQd/Pg/wOHqrgplbmRzdHJlYW0KZW5kb2JqCjkyMyAwIG9iago8 PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+ L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3Vi dHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01h dHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDQ5Nj4+c3RyZWFtCngBjVSxbt0wDNz1FTcmQxRRT5Kl NUARoFsaAx2KTkaTDu8VSDL093uUH6WHpghqAzZ5PlLkmdILHvCCwLtIxNIiXn/gK35BeAe8PuP2 /k3w/IYUG3KpPuOE1PLZPu720nzIjo6SuoMjfuKpZw74cq9poqbhYn7JHb/pVkrVVyIlRC98b0zv Ay+pbvGNVy665BnDwLiaYdkvLdTAtbuxCA4WWS3XQDbEHYyTdcQh+BiaLBM7xB4az0mZ3ZBZ1zaw WZexPkJmnJPWSy0UbETG2IuZRcW9+jJLH8hsxw1sNPgBskFMhsE6YsoloyyRsxD/4OECG+IPzH6Q s4YMwOh6m39xYO9Z7xC3cbzuOLwRv/9rpqwx7HL3mTKZ3MCmABCT/DRFH9glbx9InVH2rYMbnRh2 xCNr7FvMF079eHBjpZKQq24cHW91WvCSU6Zz8BJSIULps0uFQ9hNUK4SfG1Z6fpR/ctIOnvOzqTD UhLZFuYU6WHMuZvKtAXto5Y2IkedKjr3tHXhusXN3Qu0VnINvtVe4MKd3TjYuaa/oUeCVNh4B/Ji 8UESZZLF8RR6mmfQRXz1ncqB2KlZDyw7Z6jq3QrR4yzoK9eyL6GHC+PcesLtulI35l6f8A1X8Ro8 hyKuqhk3co3vWD/j04qHP/MEBtIKZW5kc3RyZWFtCmVuZG9iago5MjQgMCBvYmoKPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFI+Pi9FeHRHU3Rh dGU8PC9HczIgODkxIDAgUi9HczEgODkyIDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9y bS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAw IDAgMSAwIDBdL0xlbmd0aCA0OTQ+PnN0cmVhbQp4AY1UTW/dIBC88yvmmHcIYfkwcI1UReotjaUe qp6svuTwXqUkh/79DmDAaquotmTDeHaZHbO84hGvMLwXsYjZ4u0HvuInhLfB2zPuHt4Fz+/w1sFm pwOu8D7u40sdO+O1CYoTktoEF7zgXDMbfHkoaWxJw8V0DBW/rSNvvU5EnI1a+N6YXhteElXUmVeM Zckdw8C4WseCjtkkh/aOcD0u9UwD2WAbaCfrQs3amiyHSGdrqN1zsqwdmKK2gU1RnfURMuOU5Ko0 0a0RaW3VUozcRdmmPk3pA5nlqIGNAj9ANki3YbAumHbJ0CWyG/EPHg5Y935A/e+oUVBHMMre5j8c 2N+sjky7Nm6ue25di1//taN6YWh+x6iu08yO8ScMnnTLD7yBHXltO6aSz+1GyY4x3xM11gbTC/f8 eLCtvDdwwspaP5VJ0BL8orzLWoxfiCzls3epD2mXW3TKwXeE8xFZPnJSc1amcmJ19mQfwriNe846 LMyxYPtYpfXIoVMV09nRo4o6Yms3gXspIRmdUxHIvg4h04SQ/B+QeiJIhzvPkGdZrHjaxC7kGXSe J9AhPlA8qVyrUYOq1HJ+1cPqfoW0CV8hLX2JXOPWK+7WlfuZudczvuHGncBTyOLGnFQb3MoJ37F+ xqcVj78BmVEFewplbmRzdHJlYW0KZW5kb2JqCjkyNSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURl Y29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMiA4 OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBl IDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0v TGVuZ3RoIDQ3Nz4+c3RyZWFtCngBhVQ9T+UwEOz9K6aEAuNd27HdIiEkOo5IVyCqiMcVeScBBX+f sZM4Ael0L9LLjvdr1rubNzzgDY7PIIpUFO8v+I2/ED4O76+4vvsQvH5AxSPEbCPOiC6t8rzIQ7Eu mnkxagAz/uCELAghNSdJdGryjCYzmIu0qzabXH3Ixjj8uquptaYmQZtiY3nVJFVvM09CUSt8T2cE 6+qvIJPfAcymg2hTcTkGLMKgCCAF/kgAE3QHM7yz6ooM1HhdjEwPsJ0w2dTVBIfzg3gwUcd6N5VR bTninkzDzoLygdMPTefarGRlboh4n2tNXglEVvRN1UC/BqJ+SRun/drIeTro3T/liR2/4TwpPv/b MsOWbTzFsWW9IKK9BAnfVMfqpDaac9D6Z4hmPDJ5G2c7cFr6H4dYfUFIdUibE0F2VmIYqMlWHIWQ eVOROJlV5O37aHPhxHQlZ273JFhiNkuCZEug9e7GE+4FYzYlw1fLLWFTEldq3bPzrLfJXehVVMlw KZZgaymenCWw2lC8LUPhJShT/jh6ZEuqQaCBDqtakuGqn/ZF53qXsNhwGloIifVz0DZy+RjcjGB/ 6sNXzZqbw3g21+NILow2nvCEC38JrqoehCu5xDPGe9yOePgCdn7h5wplbmRzdHJlYW0KZW5kb2Jq CjkyNiAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQx LjAgODkwIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMiA4OTEgMCBSL0dzMSA4OTIgMCBSPj4+Pi9UeXBl L1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAw IDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDgyNz4+c3RyZWFtCngBjVY9b9ww DN39KzgmQxRRlmx5DVAE6JbGQIeik9Gkg69AkqF/v0+USDkfvfYOuCMpknokn2Q/0R09kcd34kDz Euj5B32lX8T4enp+pOvbF6bHF4pppDCzS3SiOM9N3qucg/NpgFKcRKGdftKDZPb05bakCSUNNnNz EvuVSDFml2EZfXKM/w3pnceH8zC7pXxy2bLZyGzYTW3JzYvPiakKM9OokVlzmWUDQjGG7rVjexf8 wnO3jagJn9CSIrtaOq7NbB2Xep2z9LgheLTKYkIQGKUdDU+IHS/kA/o3K1rVIF6sNULbSbuAjaAx t8per4lmHYSm/R0MlVoIqDdbL9px5ShvoMENSBbo9z9nP2D2hnTRCZ56/WY7VMQR7NDaCVpfG7gw J4ytWmg73QOLUpqZAT0JpUNITd5JZJ5AaWkWnEQBvwulGZX8lc08LcLmMC6v2eznxodOZj83IhVc tWfwqgMYxyZMjZC5dQYelcm5U0HpnoGw8QYEkv5lpZaeDSRuZGMDZGzsJvUxhGr4KIjrXEoZ5tYo g90qkdOAOdTD3IaFtqrFSH2wvfdSS8+0UaP5IU7HXxrFbUej/Id+Pd9uTTdoNhcryCxWtp4EDNRs 773eW86ejTdM6mcDhbV+c2c+d9uhAawNthOCa73ZwJV61pCP66V6OC3wU1s9M/KYcBNubvvBw4Ez Tk0oJ2U4NWV2nOIEJTr2EEIZW4KOJ0MVy9TY5SXhZtNFDCZYJOPCkdMnnliJbonwPoShmZpTxOJp G7bFAq1G4iJQnDg18lyyKqQePKAqQNn2VJjjOaLaMAJVXsBswBMT2KKme4oTaljKw688okQZa/1x giD1LwInTgGeDWucvNQ/NAt0LFpkUSQniCUrvtavYVj2ZcuaU8RtOGzYFgs0izSctf4a2oCnDLeM Bo8euOYF1Ejo5tGEBtzjDg/j5Ca0o4xH+oMHJl4YyqXYXhcwZfRHfFBs9UmD+JS3DHmluFmJq4I/ 9DiyBKwnul5XdB651gf6RhfjJeElIdDFpMJVuBy+0/qZPq0HJsoMQceUQW4tZJzP4TwUyE5c/xNu nnSLJHFnUQ8V/hVfkqK++wMbJOCVCmVuZHN0cmVhbQplbmRvYmoKOTI3IDAgb2JqCjw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4OTAgMCBSPj4vRXh0R1N0 YXRlPDwvR3MyIDg5MSAwIFIvR3MxIDg5MiAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zv cm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAgNzkyLjAwMF0vTWF0cml4WzEg MCAwIDEgMCAwXS9MZW5ndGggNjk3Pj5zdHJlYW0KeAGVVj1v2zAQ3fkrboyHMOKnpDVAEaBbGgEd ik5CkwxygSRD/34fKd6RsexajYH49HRHv3f3JPKNHumNOnyisdSPlt5/0Xf6TQafjt5f6O7hw9DL Bw2GfBh0oCM550q8rHEcdRfUknNyTAu90nO+djHX+ICaHC+oRex71CAvrctxqgEX1dG3h/TDNv0w 6Ok+ZI63ObLB6QGI7ztt8D0fyesOf4Z6PeIvGpAskBIIv1uygu7HbjCe1iA6clw3lBQBZrIFU4JB dadtN5pYC509XVwQYTATY5UVI5X6Fql1ZMaVKRrHecraTMZUVrZQFe4kSNVTMVEoWYzUnJkM90ay MDxulxFaxqyYOpPWQNJ6wXg6IocB1qxmmSBDO4AZTryHyy39uWolBSuxpNLoZCXphmBVueFWN2mM pSeiNMgUE6TV3Cm20BMImp0EuS1iK/F69dAeryvmJr5uvCHYLq8r9mJl0HhWiG6zNghmLJgMuXqd xBzyBIp/ZEqMYK0Ntgs54/VmlG7r9fqY1IkzCzypG68rnqHIYUA0/4fXVVO03+vptckOYF+rxsSM pVc0G/YfXm/TysDTahe8njcdHfFWl3/YamwcsTfkfQGl+WLQJviobETQ+YjbaavBzZ5DDDkGPYzB M4JrhGtluomLvGbOVD4EPXpkN2WhrpnDlCk/WG4malLJPGGxvGeJiqwHm9dKsEiBYzrjE5Eec4au hSxufYbUE4p43fSaaPS3dHbph8oL+lsV0rar+jGAs/pp1X9BLfbpU7UrhKcJatEOpwMWtrE0w/Tp +PFcDx84J6BlOQedyw0zYc1JZ5Z0QFH3E5n1Al+pxzikYNHpSHfThM5jtemZftCNOxAOEJZueg5u zYF+0vSVvkzZieqzHdEre50gJG0JqnyQyQTplCDcuJugPSgm+PgXlNXrsAplbmRzdHJlYW0KZW5k b2JqCjkyOCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMzI2Nj4+c3RyZWFt CngB5ZvLjtzGFYb3fAqmVxxA025euztZGHGkBA4Ew7Z6Z3kRjyXZ1sXRtGxLb59Dsv6viqxqDkeb QDAMWByyLuf6n0tVv82/yd/mu+G/2xd52+b7usrbXZWX+e2z/Hn/ptmFL7445bvtbmcjTjd52Qwz 7Z9h5iE7vc4/O53K7c7mn57nxVe/vnt2vspPv9g4G//olNv8ctzP/mnbervfH2rbdZ9P52bFz8M8 m7Lbdm3wP6Ozq7ZtV7ZVvt/VebXbNm1dGsn7kebSNt/l/bCaYU1eHjSszQbW4HpCUtcy5zAjKf8u L8qr/Hq3rfLi2p6+z0//zkaeDoMgDvnRhFM2Ru++bBPTa03Pr4wjW+ZXvbh5d5UNb7bui0ZUGrHT AzTwSWP5Ul9lI5l/dauxsc3pye5VEdBa9SI9VAeT4m7bjmKciMWP3dmAuZ5NMF+JOjj6Q29E3Zcz zv4zDsiK1xrxRlNM9yP979yc/+oFX25e8si0F3O2tfB86x+03DM9vNIDqz7TYr8zSMuJqp80ybGS F/oSj3QKidaCs1skxysG307Xywr/BeFBjP/Gk6bD3FlvNl/bvo429oWSMyv8KFY18YlYhXenhqxg LJ9uebXx9rfg113XmRkGnj26bOzZXbe3gYFvj7Z7h293+zJpxPjPdeAm5geRd3f7g20LYmUD2pkX 4GaSEpI0/x49fjvzApx4N0o48xjDJ60GfZ20If9m6FFfHjg8sbnlfrvPi5Pb+B8agcmjpt/0yevd lCqYAwO6vYGkwXi5rfelYa39MSBqGjG6rvGSysvM4oJJau6R0IA949XIUCKUOM6/yXJvsVN9m68P GrEazDo5BHarRc5Q9UGvNpDFljc8nTUhK24/bDTlWg+v/XIxAGnQxvNy42g1hHzNHuyPS/GJN2z9 ecLbLMxYfAqjaFfvQl+7FEW72vzPR1Eblj0fwt4QbCfKJ4p2deAmY1Jgym9kZ4qiFo6ypJ81lmdM c4o1XpYV2zu8LIjkuI40MPeyrFjystGrbe5KL8sKDC/ysklU7urjeh+rDAYTUVk+H8cGMYtJYpFn ZSK3fAO8NOsch4qXmKEGYb2YLIiDO7EF28f+6d1+zJBwZaKZdxl2gJrzeW4LT5w0Mp99oRLm40vi JqbUBDUq3wTlImgkKNiCHq3Hi/daxr3JCuQFEQzmzYOZgSM2UoXzT6KKbyvYFDFzi8kKEX4TSwKp QednjryH8vQnj6/yug/qts6oRsa+Z8HXmFW8Yp+xKHOdYI0PS6WFpYQTPJeakAMxBgtC5OKfpEhs X9akt77X7OBzRqexrEhhsdnPDIvbg6Uma9C4PVgRFOLxqqqmPfQ6iCG1kZ6GzCcbC4QUIrdHK6oS C1zKfLICn5j7IcDrMp8VmJwVqzKflZicFVgenrGMya0ZWzrzyXxVi0G2+2NCUidnjnMP6z2jJzyg CpsLocZVRohVBprGZAdMGoSBYvB42t2YHIQuuYnWvT8mjyCg+cLkoCJGJVAI+GmWU19W3EtQDAaB tB4l3xyT84/A5CC8hJjs1IciVrCpgHzJYvLiHpicFUlMHl0GiazB5Ky4G5Pbbt7Y6ZP/OSIHLYAl RHaik7ZSehytahUi52sRuZ70mC5Vom096TGtqkPbOmqZTbJjA9Ug5EVVaNtMkNhVVpeQ2KxEXnsX En8CNWhrlcHaCrSte9QOgp6T1N/pgkgweBhmyJCLb4J8TZbJWFBWG/gmD2AGAJh6RvNlOiDBOg9c 8NBOJEx47q3jIQgjDIIZ4h5U8KCVz2xutaeLIuIiFhMEvlAioXXYyrlrAItwrnU1h2jCRgQnDYVL hAVz8ZunviXFR8OgsWITGMGlRw+40q4iEGmxHBGamMTkoD9wUX2e0TNLCtSzggio/dENGDjf37yd WdiGiSgLACWVsliBP3GVvo1vmMQSksTN06vPZRai6suZcb5EBNCLZjVH61GsYC/6Eo90cQCaNML6 QcOnMB9g0FsZJlbHJ8icb4lJrAmHyt/y/uRi7F6jAfcQJFDoy1fZ2h26sGh9wUp+lujPD2YyxyBg U5MlJf3NYnCpEeCF94Tf4QlVsgFkWu7sgCKSKDzxJfCKeF+3SVb4fXE5ltK0DSYD85F0gzLEpt3h A7t0jSRpBMjqQRK+zpt1hV6z7+u3FS3uZt9XXNPGm53M3dHibvbpjlAj27y2p0AOUXLRHJoQCf5k Le5mKMPXJhjN3o43fZvSpRcn55qBo80y2G+ljH+6ofTmZdt4FOaPI8qPcUiqDO+Z+Mp5bGGO6D8c 0fZnKf0R7V90zJpuqjStPwadTHEHn4kY0jQd0nBTLILYPtdVW1Wj0YWnxN9lxWbrBDD/F48GSnF2 xCpZubFBuIzHzuESAWlj8pfxRVbMZ3wERbkCeIAcUL9xbngvpdQNfa6JUtwJe3BCz1k7XYnGdBAY qxmBkfXG7MtO6RNEJA/u/WKmfy1mlDjLX9B1vl7XKWnNdI1kc9/KQbJec7O0WrqOlO9njOVwStcu wrHLfSia6nqE1LscsD5ecECn64QD1ocO83A3McwBARvY1vlSvnS+5Bu//vgqefQ+wzbBE4ICykAw AOuVcJBPPimfLeuID2zDJ8wwxsJPvVm80R4g6ag5O6pjHp9A0BsoYj4IIc17Tp1tsB6TIcinVsB2 kAh5Vt4ok7q4G2v7o8GnVyIJw3V1U1b8IvZhjRxJk+Ae0tgjYN7xqEmeeaco5pAWSpe+9nX994zr EoGReH0H2UnKyPfBsTLZCUwB/beiUBT/zYWap1c+AZpeRcjCw9Ha7j8FWdqlw9G6MfibHI72OVrW w6+tNomtHI7W0/6NK7Uaaeq69QR+ccqiDK22C1DCXu/mq9o/0+brRzTiczXi/0+Ho3Wz/nC0rtOp sMrFvMDJeMCFMSh3BtwbZZYIk/OrbUTIuuovS0hPcT4UpGReiRv2f+/LeO+5+Jg/ZnIQmhV0SnBn 1pIn8IKGIG+YpFM6ec0cUfKCUh5XY2sAZHR9H0IYqki4fL2vOs4Owy41X6vj7DBsVfu1Olqhl4iU 3gPttClAodgDd5PDMFBolQ9ySDVc+5v74CfQgq37q4DpJuxiAlod+mOx0Yl0UfTZ9sXWsq/gougU kif3VSq7bRpA8kWjaLsEJA+F80VIrrpdwiAMiKe3Pl3uFRlENT3u+FN15Cu757W2YLZCMABFMwIn qftBsrAJVHHoFdzkAimDDMbpMgD0VN0zAHrqVLdqwtOEGNATBa4VPb5jF1GtFz77IwxBNSyC8wuc acFEsqkQAEJbDeAyOpJwTddYkjOI0JcUiltqMbvSUA39tMBhL+VQ1W52mXPVlYaq7IOEAqyPod5p DVu/X7jSUF3oeV9C8aCXuHW5pEQ2R/FP4EpD1d+aSTpu0vh3QdbNfT5/kPZQSPlYD4++Hg5aOp8E YLlUCBumRSbGC4n4seyVZXCSlxrz6P1NbLQMw7uoSDWvvwvt0EEmzgtfLOMomwcT9dt5ONR+iKlj W+3muV4Q1n1J0uLsb0Ies/2lMhfZkP/BCZ9Gifh8XzuRO74Hb+LJrMvoH6VHrQPFEr0+kHoy1+tC xe+auwjlMVUveS04qn1VChuiBD1BK9K5YHsOWxmGEcCL1l6j6KC1eZ9pQZdMjdYBD+9TxpSHSaNv 0jrur+4mKvSy850rD8tPKGOQBQ84JFWX2Pw4z8oKNCYYSpzSAUORvrd0pUcX8n+PyTv3rGN7gAMU jXnhC2IOjFGnRB82cgXQjNXGIcFlngVO8ctleLuUB8DcGkGNgtk6zJHAUomCjZwlCqVdoYnTBKuq pr/mKu1OedxqWc7rS7tMPas5rCXqUwSL9UuFnv2ka5ZhZDb9UoJwj5s2fYLg5E7uIO3P76Hnd95D H2Lsynvo+fI99IwGRtnUyfQg6fJ1nIv1klqTICx5pkA6aPvKNSKnxRGwW9B3CtJO7izAsACPfDdy qNIvg7QlhbjxKyURswQhX5Ug+ERJXOdLMHaZJDPDOLmPIQuvXpEgBJVVLDZpRL+WkB2DWWGCMA+M gCKjeaN10Kc2EgauSRBM9jY88PFUwCqPyX6Q1wNMiwReiMjA+uYsTq3PWRYLLFrfGH7uULVbEesT SZNp40qYaspoHWgPsrpXitCXb3RPXGF81/HWMeyOTrIEJz6ckQcshBgrTheyhMw3eTXaqxWlrcsS HGVax8mL3xzN/45dDl0bB6NC4Al7iMwfnS1kCY4yVhOJD4VIC5xGWYJPhNk6YS7aAu8ET2BFFchc MPO/gywh+OlBU7fbXf/7bvv5WRzCvxVn8AwfUB0dATlTCn5Gi0ZYZuFeVqSaHxTD6YD/y2WO0MAD k2PKncACkPXUeOz65n+3H0JRCmVuZHN0cmVhbQplbmRvYmoKOTI5IDAgb2JqCjw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlL0xlbmd0aCAzNTkzPj5zdHJlYW0KeAHtnN+TG8URx9/3r9jcS/aqfEIr7Uq6 JISCxKSciklhlIdUTKXgYhMwZ4MEBP5Z/pb0auf76dHM3Eo25iHBRRWWNT09/Xu6e1r+uv6w/rqe H/7bfVb3fb1eLup+vqjbevekfjp8083jL97b1vPZfG4Q25u67Q477Y/Dzk21va3f2m7b2dz2b5/W zQcvvnmyv6y3Xxicwd/f1sf7x5NbO6FvZ32/Wtn56xos1Yjl88+PUMxnq96I0P+M7tVi1q/aflGv 58t6MZ91/bI1FtYjD60RM68GsCVgXd1uBNaPYEjBSDSKhv/sj1XPnk1K2D/qpr+sr+azRd1cdZf1 x/X2z4HHzWH/pr42YbWdkbpue98+Sse2Ly+rcXt9aRwZmhfCd/NN+GYW/hTEQhBzfWjHD1XDkmDD St2sBPubgA3Qa63c83Pa9WxdNdvwxR8E8aU+fKIP3+rD/ok+PXcxRLybMubtbLluTROzvjqY1pGY HXZuAAVJiZp/66BwYtWI2UdaeT8lXBAQ+S+BmmGN8h+lXbn8d9pU4HEfpHjQ98HeBxMb7P1XB0M9 mHnlNgRzq80mYq6wKTI837RemcjkE2GT2Y6ddbXoF4vR7GK3s8ULmU3656eyuFybiFasfyrp3Alb NZHZHAwYGevgz4REX6Q7wilVc+cpNTo+TZGxfllNKqYo41VXVExlkevuoOUq6i0ApUbbfPLc7MwQ jBYSYtloIVE0LJlJF/tArvGIvxBopzUebLwk3yT8nCPfVH/Bh6pGCs5MIN1x+hT36tOwg8YjH0i9 qirHmdXiVVyxjV3RZU/ogfUbAvntLV8+lyuE+ONc3hJSnxGSgMaD5Je6GnDYJ3JqNhO+UDpLT0N4 hCyhDV9UDcTs2QQwiB87GJQSV0eUVbNjH0vE0xuQs3+C02Co4GMzBH0l6e6Q/Q3ge2fluYR152ng dtU9vpSUMMgfxOQXOhjW9tKQNsE9pHFGxHzijEKCmtmzF17p0lm+FVXZbmRhEFGmUoo/8zgazsfI ZSEGtjCQnU4RQb8NxvX40g/xVG34dEjElK/16yHSlTO2Os7Y+rXlh0nOVj09JFnzAfDIycnZ+rVl b2lcNkZ6aezKPg2yqMYgn2Vt/aYQ2A3BUgjEN3q1vK06XISzIAlBkHGleVs9mbcFmzg7b6vvzNsi v3ZDxSjMDGUUXGv9+noQepS5jZnye9tSctOvogSZDPfvl/V1O9tEmS2Hj5Kpmj0GjhSBIXzhQZJn FDIDEx5OcZTUPPcgvuFQIRRsWIjEpRVB/kjkAJ0HOnwTil8o4Gg/Lg+/6Ql7ghkCCDxVTQqLM954 FNhDhaD/I4vlzDoYKkeBCPawjn1qzQ+CdQdWXPTf30LxvcQDwI9k+CDJfJKK6nffuSjY72Hd9slq jyKAm3C/InX2+5oYDq3gRjfP/iKJYU3cHC6Xty8ooPIPF28FCfxe/HEwN7YiOGpxS9ImqRCLhaCg 5aqZtEjhedxwPHYr3IJ5EIxCf9d6frYLSrA/wENA71bBeV4oahd43HpNJkMJWjcSjkz1Sptkfvq7 AKFgl9uwWBEyWGITPiK0rEAkmh9BqgYTBhaQzAc5ERBX9juy/LtvzsOFyM1phd+d92ZFp6NfLJNb 05o6Jzod/SJrwRzdmdZMiJwuvzOXXeHK/WV0OqzvdHRfTnU6+na4XVXXe3B61w117AmNf68azCf1 /7ohhmOFwGC6QnvvlItjnXIDUIBduD6X1bICrDazIh/VwoXHArLzqAEDogttgKU9a78eAmxbZ3ci dAEpij3K4LkEJ79XWBvPrpofEIoQpbfbHkZFryBTvVnGIxBnSd944QjpEhx0TtUyM3fO47z7KHp0 myExPo4flk4PtfMhnSZ+dBureF86gnR2/3rLyk2bNuSVdSanYkh3vY59gwpkMu8evcUEcMi/JdA0 764auqIsCZYVCJ3Ku8c83/aOl9U2HPxK/dKhACFp6a6H+quUd5d6V91mGUeRyvqQFq7/qOwlM8vs mvb2mte7IR+qGqxQMrrwzDlPmvJbN/KkUV6F7TsQ0fXG3XbuIvInnPtmf5F6IdzSFoAAlsSJBFE1 eJaWMkHUBUGIHvybpE5oPMIJVisQI+fWAuySbGqri0R7XGys7VOBjLBRXN3dRkeEziBqExU6M2It gCp7+lL2lWN7ltIAFggeAuDg/6HuLvQgurV11I9fk8yqC8YTDLRqYAJhoHqx5Wq9JRUGere/eMep mgqe9kR1HDotpyqEzuUmDpxjKnAi9eo6e1fLuCYaXVnEisSWpV5dd13YPhk0/2+aFV23KobMUqui Wx41uF6mWZHb8ndYkMyMmImXy58EYelEaOykK9gsWH8EHV8BNOKrmkfyxvfTS4g7zu629XK2qv36 o2AVVVaNBKq+Fj4iI27uJYt7ExSKG/Pv0bAIE7g+sPgrZwDDUuDY3xZE6oPAJ9i0kG6NAjfI/L6B vDRkCb/QijHUH+QRXZDP7oSFL2ERJEINbHhzZzJNFRq2Y2eIAwVwtutNpwOcb786Ss9K4XlhhWih s5Lj3HmjLqPbXSctSiAbhInNWzcassVQMCTLr/EULQGru1MLk/4RvOEKM8nJwt7OsWIdKkFgTdDr WkK5SEC7yX8oIwCBTZ2gPY7XC4zhZSpwCAKkDEV8M0sS64/gOMigdAXzZCBCLhChk6Q1zvz+KxHG V3lmCGHaLp4RQqgcK/pIrAzZYVR/lAy8jd9gVcJUzcO/KTR+tFXmLwJgLRenQC5uAlAUOChwZZtH ZB6KmYfvHqK3tcSsn27lhoVxYcQaOFQrkkduZYJIbez1xR+1sw5CvmtEolTNLK/zd9kqnqsobjpU qXni9C4yCcaSzysgawlfsnE/wc53HlfSeOVB7hkmK0z+6JCb/KijqLeDDUl7wqK/59p0qnTrwjbc nReFdZborJrXkAiM5TidfeF2C5ZL1D4BQsBFmIm3RwUN6pGExEVq3X6iIIMsq4ZjtPfVJTjmPTTk 0CdPpURtlJOanpMXwnNM3nTYWq7Lma29oqS4/P39R9eAjkZ2EIlEZmG+xjoWE0XS8jDDckaZtOyS l92zCqVlV37Z9VLJqp6Pq7vn8ZalkZ2Jl92q4QaaJRchKcRcVwN9JJZkV2GleoWJvNf5srvsXuZl d2mVbB5c7SY69bJLrMILPOOTRLArLE02KIg3xVLtzQ2iHSIlAw1R4k2xZHO0iAmvnYhoP3extFyU HqFzwz/vkk5TDwwBhMld+aZUMgkomCCkO8ONJyieAr4plTTYXiiVljb/n18PViiFjOOnFUo0cKrm pxZKoYVNZ102oQuH6yrOtw71F8ED89Eea9QENvG6l4o91nI+TKBHhdLRpPA4mFaS+vATjNAqTmde j8fheFdaXM8LLZusSKqzoW585ThTtZyIFZg+KpKOn+LuLpKsZeMIMulL1uiHkKcV1+SYfgMJrrhI GqlClfCQxd+qQfF54uJx4owiqWqmu6UqkoKJOm5x5in6lzK4k0VSaejuWGIRg4hDJwoyl6Ug2BIk aPO+rmJtn5DgdJE0ahLlHJueP/kXyZsukhbr7JdKlvn7oBlGc06JFFWiyGPm3aWJEmnRdck7UvEJ ftG9/AP8orsuePpa9cmp5/dFvyK2WOsrPClPviONBmyM/68/vi96m5gqjLyW+k6LQ+2qKOyS2gYx 5LaZOzb+QYoSolvUIZTDPZIC3w8HMGtAoWkFZvbMEy4oYcG8d/4QIm8lsqYPIiPAOY0qWr5whp8T 44lhnCcCIA5xaAVhJnt8ypAFImP+RnDxgWT41yDDrbdxx5CDlO8jXsE+fHif/X8Uovt8IkHhV1aw I+EjlOfafgO1iIdUImyPxgzvxqOVTF4cOdQ5JyLjojyThgYRsZlOMCvqT7cmwNFZCAxRljM+uo6d 3bvHABbW7PYhuXPznLk1hwrx7yO0wQcJDUIlPf0ZWKkaTQK9FcxGfzI0Gn/ohy4cP4ja6e66ueLF BRWjHZ34Qoaxu6wNj/X8g/CiHyfy4iIqYGjKp/8pzJ4MuT5ttCIoVMflWuQbZa2Ns/Z2GoKiQSt7 aZbdTdyH7eE3HqWWYXU8lNauh19lvOwPeNuj31HqRadu/FY0DkSmTZNn0xXtxn4/7PfiL2word0M D2Ln3ozt6mgSJWQQJ1uGtQ+5Yplp5h3di7iKfEfunI9ragW/I7Senq+oz5uvqLKLl5mpMSvyy/+1 VQzcHYiLe4W4/K0cGxiWCBvyeYnpQYhyYNPCZ0LGVkD4xi8CyLsX8AnNiN+vbimQOExYBP3J+Qp/ vdQpORKdc2K+YkwE2I6dQQzZCTJ15er0AFwqEE7OV7R9NIPPfBKdCwg6r+BKpR+IjjwJtxDxeeZE duK3h4Dpgeii00J6J5Smj7LpiogsDJXDkTdLmJ0OlY650IBwHaFaNKrdrKDiXI86QXscrzdEJn/3 C0XIfZY4SDZdEb0BsNtS7dFSRci50xUhMIEodMmjh1AIE2rxjOmR7ErprNh0xYk8s7WaNiqbhn87 wSrw8mzFyCF6R2EZhcxW0DK0n4aL/JHIyBcZEJ6crQiC4lChk+CJV4hSENgReyXBLPZEA8jnPFco +Sol0/4PFhRahu3SJ8XPTKXbhVX/2UDqm5ahMuks/kYdtTRxqaOfw7+2BAC/8BgkC3zTMkxiqhyw 6LRR5l9ynXmpofbztAyj2qNb9rP58G8Z2e/Kcjd8lOViFGgei8W0rCK/N0OAioK/J3DaTXjLoi6D 9OHfQ6ibP4VLCRr4wOZH8h/wYsfAhCVrKntZ9uF/ASRGUfsKZW5kc3RyZWFtCmVuZG9iago5MzAg MCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwODg+PnN0cmVhbQp4AeWc25Lb xhGG7/EU8N4ErFoxBEHwkFyk5EhOKWXHJ6bKqSgXylqSZXlli7Rj6WX1LBkQ/X89xAxI7qZy5XKV F8L09Ll7umcGfFt+Wb4tZ4f/di/Lti1XzbxsZ/OyLnfPyxfdm8UsfvHxtpxNZ7MAsb0p68VhZvhz mLkutrfl77fbejoL87cvyupvP/78fD8pt98HuAD/eFsez+8p14HCYjNtmo78qgRJ0SN59erVEYrZ dNkGJvS/wPdyPm2XdTsvV7OmnM+mi7apgwirXoa6rItZ2YE1gC3Kei2wtgdDC4HFwFH3X/izbJmz HnL2z7JaTcoHs+m8rB40k/Jf5favJuP6MH9dboKy6kVgdVW3Pr3XTpjeTIp+ejkJEgU0Pwrfzc/2 Zmp/BTEXxEwPdf9QVAwJ1kbKainYPxg2QDcauXY69Wq6KqqtvfizIH7QwzM9/KKH/XM9vXE1RLIH Y8zqabOq6yBmWxxc60jNDjsLABlN/WNSburpOtKQES8qSfudeIC//8CWYAJ7vcJRtPRcToqDBd4z x0d623yruUB8AB2vDMi5+kqzPhnqExsEM62a6bKssBdWEVc7CLwVPpQfoqOXyYFuAYfDn02+vVSR mhPYl8IIDVRqQ0UFhak7zkGBT+zfYBNBsDLVQCJkOwjBXuSYR/iFVmYy8xcV+oCD1yOwZQU5YRGk ISkqkAhih+vgEKiJqIUHgN8o1DEAtN1uog7RaLoSTQiwgjzjiYoIWq7X2QhKce5un4kpCQffHjpD /cM2CBOf38O2BEJDnik0BOwLHKmPxEvi4wFukrKFq0IcmNQVxY0UQTLBWYOVLFmjJDSg2YxgZEAQ s6fgCcKtfwPMbSaA8TY4Qu9TNNdnqq+RGEF5YPZeoor5K7zBWdIYs979pNzAK5yeNzCm6SKFgFca kdEZ2YWRaCHNOfhqGdYQqgQW08/+Lta+3k7C6j9dlawNWB57oE6l2KubFOg0m4d09NnDQ/YOtMIS FYgu3bJ4A0QltfSRepkgbO7/If/8ybR0UPKhWgsF0qFa++hQZvVFWk7vy0WUWGqrzs5NakNtllnP H6KTbxVWw0SDS8hHpBuPE/x8p7xSVEM0IclZ6nyNgwrT3hEkY1owsRF4ZD1h0b+BBJdzJVjERrou CxuDQoTjeBbWfM9C9y8E+iQRUlSfZyGfhr2HBHmWB4RMoh3R0K4EkxQIiDo00kMWVapLQTAFMmc0 OCixSWAut9gja4P62PWKSpBZ9s6krcVRZduHT+gB9jCERm/Qzwe3gEgzBpOUFlNPnd4fHZ7iJmk5 C/kz2yaFpmX3sqBNWs5WAfCujdKyruOIR05vlRbOZmgCklZpGSjmUsZvo1kKfWyn9AvbpeVskUmu Twb1wK9KMD8q1xKZhHO0Hvb5wbOB59ujusTiKpkoRyVGCDSNKJQ9PVJD5LzbsqNm0SUFdz8swbxQ Rvu35CWiNJdY8yr+ljgSezarqEZFY4rwIqJeCJdBFhWUvWSFO0/zmEN4pKKyMhVF/Q1ckBI1i9L5 euAJ8GlTTsiIJSQKvMH3QD9FdbUNNVBo8r073N2CBy7hG4y8oWZ/f2XWvXOZ0m7C3pTtQ3VbP90+ 1EenK5t2HbanjreuQmJOo8g8Hm5PRNFQ8VKiBUXU8qKW4RRshZrSvsrLgZEgtdgZWCpqfIm8X5Qb Urow8F4OBj58wfdCzOBR6UrzoekDbUT+MoQgFu/nSGUFy2asovKQQgpRfRoN7vd4LgYf2MpLfaIb ffCwm4Tdza4XGdrXHLzq/xb2t+Tv04nYghHoayRRpBnPKxVButRYHLSpfMZbF3zFXXqEdum7pJm2 osi0FW27zATfI6XwT/Xw+Iu+v1JTFyVC1CJ1eHbHxMTqDZah3KPxBRHTpD6mux6j6UcrVFGx3rIE omFCCS5EYZ8O/aqQFAxojuvSkroUrGm4FL65DCXwEaHv1c1ej68cYwv/k8GU16gTOmiml8jdFE2R fWRLyY63DgcMZyQfxkLQxJ4pPV+EVUYAg1bBl8Z7QkFbOJ4kULKXVom0UOjy1umGol0sMrsgMA3q hDMpEFCTr6icMWk9LaVQBtYVLBSlQM+gwKIDBAWf0HiA2iz3ksz2sGZhERDDjiMUYwof/LLbdTrU krKasoyHFrACfanoTEZggREexraii/GtaLwZEcUBEpKK+hB0l3ODAnuxO3Qq6HcImIIYNzDlCsPG 8q+p54OwAm6K6iF8jgYzA/trn53Z9492CM5LBttBcWdiqplnYspzPrR2N0SPrCGxGQirkKVKtIX7 AzScHfN6kFuFVaZUfzruNGIGfbqdgmZ7s4o0fuXSJdMZwrdVnkR8EcriufTDmAQjguI3wTt6xhhS nIpTuNAL9ImcSuNR+SlgsQCbu1tz0ZNNRrZomXvHkKlzogNkzmXaWXI+nmky0nyLwhHR+C8qyZom K9wLjUl4KSPqF36Sm0IKDWkWLwChriY5wFbG+tgYg4kPpAJEI1RleuF5HFjxd35hKCpYRyeO8HqQ bACBEmLKSUUaVaMj5sA4Ds2QlsbQjghROl8jcI7SSSjCU4aDSks2iYqFBk69PAYPkwzIl5BkNnxK PFSDmEfLg7GF6EIY6fx0Ul5sog6B/UShQaqEL0EwcO+iWJLirCxkOIrcAkVmll4xJHQp62bpaLtI sEqF6JiSRVhTbP3cuKyDXWzmyhnrU5mDhzFZzJ3US19YoRcTICrXE3R0CZDG8XlDTIRNEfMwcSOF oCoNICu+mB4AnXB8aIuA8EIIvEbJkaUa8gTMLA/mXFIwKYfE4Qo0sT7PRNY610I4Zzt3YnYNJDRG ivxuGOoJ7A49SAxewL55iutOoBGho4Y7f4YypdYLRYUuiyWHIYt2Nn4U4jfGFm1Y5f3GWH+D6cyN sUW4FJfuKq60n/Gg7Rks+gPX5BhksfR9TLtPd7gxNhAd3wsG6qunIPihcJTy2QyeiTQb5gwJlpGl guriG2Pl6I2xqLdhvfGSOthdTkqttGg3R0cg/Q29j7e5Umyx6E6pUkWfvgRhnkqcmZgnC8FcVbdo wnENLcOFpeBiHm4iZli+2k6Kw/Y5RpVdKAs9IIn78ZaS2GK58jrJax/R8LAnFC2TRFttikVQwyqT hO8uCQJ0wi8koL/xmmJnvaFnCLn82N8r87GxrcysXx2dY15o2WazidzBw/Zr5JBgmA/bSPQItA9o tzk6JsWzpFEO3Oze49UQ+UHhLPI3rJ9gABhU4ojEayC+ISN0j5RaPtXDcLu29NM0BORGFTqAB5Yb MgZDcM6DVQdxoePO7E0SO/HmJuPBXuQvpzbrONVc6hKrOENELoFW0QeyIhl2lqJfyZCyjQZwDbAN IcghWFw1a+ovmgtowsiQ+2jXWyxhMb3I9B0JoeB8vddDkdywzxoV3xEqOKOB1Ij4SBnjzXhajDYU UtZEAV6xAnYRcSwI4xHDtrizI8MDhgCfkYrYosS+9xWvprv7cdfVrGmPLnxwH+9xiLyxgtAP3T25 +enm9aCCQVRUJn2jOhQPiCPGuIQV6TDtK9Cv7HX1cO9dwi0GEQeYM7U4twejfTrY03wkMAv7ouYl EskQKVNiYjfCZ8pH/NRtERbXEZphSvCUjyfun07kaNyzfDKwHDUADHPMjDFgS7QT1SA2/FrN41wh NtIKi7CCZGQg7MQIFBzQCyMqUkeWhiYs/F7SsUsBVVCJPHpE916coRslQ9wO1nbCI6bRsHYKNCDA 7xSNUBbEIy3an+rhxOqNn3q3igQIGRxD+jrRfDWz7q5T9MFO31d1C+vxBzvN4cpa1IBd9MlOU3cf m6Sdgbdg4bsYsZm7idaE+7w5o4Zvff7Xz3YK/9jjVBNmdE41Yf1qGUzZ33jeWgTe67OdrhelCWvq 7r5vfBNNbViuEWrCp1eRqrtrN6FdFTeEJ/FAsKVv8CJzaY9yOezp3G5Ky+V2S4nCQzSdSfGGkRAz Dj1XE1JI41FnkwEZlqGWPIvkwlGCAuRoaLz3QzRhkcz69wmTHK08vX9BeqgDP3vYgxGYYUEbnRWJ nVxV2u9fpCNivf8b3aFKOhbY1RQyKmaIlp1exCvSIDCnUpwE+ML3tNgg9Qu8JO6UgX1XH0TpJ3M3 Zr4J99eSi2moF7G9dPJjPkmOVahU8B7y9vVg2cZ5iNIBtlj3aOt3HZZw+Y9JEILjAZrufHBYIsKU FHyLF6Vnrk+5+WKVRrStrPnw986Le8wihnAYWMWYyUm0hweoRcs7lNxVWRETND6BvgUB4p2OWTlK jQp+4dEsTM10QTjLUS1pmo8ktlSlWQnehE9B0mqBHqMxB2l56DL0mQBYbTIBAEpfB5wRkyGT0X0d yVlb81JMeuNtQHBEU97UJThR6MwXR2VOv46qzPEL9/PFMt5lvqjImYcNbFIEZaeXOOEpUnGyyzxv ow+uad1+G1ft5234DPzCi/bzRf47Jks7pX+wYr5VVGm2YsnB//JbGlQulqbCxhZB6jlsv1f7dTDw 2N5mrlibN/nK+GprC8F4JsnLYNEQ7bUNZShHZBguPeFzGENGEvPV9APvYEPBiUpZdPqR+L4vyQlg 1DqYVVbffEP7bmou7q7mkS9ZPrctLirBoRJIcAlbKOCdkjObLDuAmU6mlZZY9/IOpXYT/YBSCEDN CCoUQ+Y7cYmg2blvnc478chu7PzQFJL7SF6fmw9ntNsXesggtlJZePMgx7Kpp6hO+OMZTQ8a5MCY jijjT7XqVZd1ogb5eOXw88k6/IDA0adaF51Q1quj/hYNrtXfPgjngdHX5snqUa/jT0J9b3usQQ5J UV4yHZScdMEzEecskiHZy0aKe/yuhbekwwb57qeU9brb+IxXEDXIufOkehUt1Kj6XMItqq+kj09M YzAudZATSIrEr7RtQRoWEk2iPvPScH/fQ9C69attF56KhB9FoWyxKWG74KMg67ydz6NU606lL4L4 QEIuRKNIuiPCqdMk9klYKwGH2dj0619o0KKIg+GM81R86+A8bFldWRGXXeNH0mPd+KeBOaNEP+PD r92w91MHGwwya/XsTfCv8FM+GSaCZ+vXfTJdbF3PQJbaui9PD0gvsrVVBzlbD9qX85pNvxYncmRa gksvRmydu19IFXUX77uaRN6fM1xGw5uRr27sbklmxtrDz7VOqkHo437WVP9GGYl8I/n8U/bXKBJo oqaH9m4MNUGWyaQrzM2Qtrmpf8QEWMgCvo3DGIijsxk6/kQu7zMZIn96dTqU1GNcafgSSfOFg6k+ +ihtSM034kQNVfmmULeb0BdBBAeF+vcyK6JxCCTVIj3rCTTOs4PwzGGj6IUKYorJW5GUMMzGhAEi 6mwzPr7KXW5DJrwjOUn5oy20TycxhULVT3flZ9b9wFgTfjYj2ZxLYwiDIlyg2BtBQhIaCIc6eeOn Q1KJDZ3aVMW4fzGZ4IEHbPpV0nihImCcG1fNl/8FakQNnAplbmRzdHJlYW0KZW5kb2JqCjkzMSAw IG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggNDI1OD4+c3RyZWFtCngB5Zxbk9zE Fcff9SnE5kVbZU+k0VzzkjK3ZFPgCmTyFPIACyYEFsIMGJwP68+Slvr8f6dH3XNZV0hVkqIKy+o+ 92uf1vj7+qP6+7od/9t/WS+X9bqf18t2Xnf1/ov6xfBm0aYv3t7V7axtw47dfd0tRsjwxwi5qXYP 9a93u27WBvjdi7p5/t0PXxxu693fw76w/71dfQwfKXeBwmIzW683faC/rsFSRSxfvTxC0c5Wy8CE /hf4Xs1ny1W3nNfrtq/n7Wyx7LsgwjrK0AVm2mrY1rNtUXcbbVvGbWghsBg4Gv4Lf6yWwGymjP2l bja39dN2Nq+bp/Pb+q/17g8m42aE39TboKxuEVhdd0sHj9oJ4P1tFcHr2yBRQPOd8N3/YG9m9qd2 BDoRpNVDFx+qhiXttZW6WWnvbwwbW7daeeJ0uvVsXTU7e/GOdnyjh0/18KMeDl/o6VtXQyJ7MEbb zfp1FywxW1ajax2p2fe2YUNBU+LmbyL0VXyomoOk/YeW4G/P05da81dsN5RVI0SGunbUMgbUkVcw GC4oYLBP1Zze8sJVPRr9Evaq0Y6fJAbkRJ8VWESKe17Vt9VI8B5w47aGAhoDnC0itTfJqobNuIb2 sHI44CQPaFziQOM7xQHEEnccWQYhOz6XLkTzYFK5IXMxH2uUqkF5GSjiwJs7V9HfLNbBiOdKH6yA USuJOoYsU8VM6mmK+FltNsX4kc/t0clD1Js7F9QxCwx6fJOX2ATCb2XEhNnRdvgmW/EJHGdizap5 LdFlXv0dNjODFLk0pUMa/xHeHB/ahyk8fi+om2fXerala+gebkKKrGKl8Co2PqWlbLVcBEOWi1md FrPVMpSotJzF9HqhnK2W26KfeEHrnc2QqrOCtlqtiggCWLGkVQ2uM5vkP4pRK1gKF0vSO8Xu8SWt PlnSkkyGZ7ozBcupsnuYDb3EUVGLTcTbu6oUlKE1oamh+D/DJfAzSRl9PUk+RBshmb/BbY+x1KES WRDsH4CCNoFBKPKGJPZKGD8XJmLvNYhArUDlBQjZOxs9YEzUwc23dfMMWkgBOFDTvHKHH8WydhBl T3LAgh8xEcorlG2qGnYjJ7iligcY/TrnFHhVXDYLnOLhvPIKop5tdrd113VJU/HGpryJHIS+CTIE JoLkFkt0r2AoN3CrRTs9BoRG9x5iWARjoRtMAx///EoOB1ii2tgyu/m80ZlFzxg5HQ8kwxlg96Jq 3hpPEqer59yb/AhSXwTpVgV5nyGLupKa9jJXrpziB+vPKEkogrDHScDCHlQUNVs1pgUI31m8sFF0 P3z2XJn3vehpdZMYPBTxqqGIY0lBwy2GfJntYUkB8VTQn4ky8Qh7iAhtARl0iSsUz4OAYIpYhqvP 5GYAodUD4gGfpeusaBRaUDVg4kbun6PXDpO68kPhPqN8g7LgDs6JFEggJprd3xzbeSgWVr/diNAQ Z6a3UcoL2aBdFCofTqzk500onPkZBZuIfKY67KgA0k4kZweBlCFBcAH/JKeAp4L+CRzAT+q/avB1 x2jpuG4Ay7TNilgOMsSCpxfZDlQGVxLqgO5tKfRlgL9me+ZouQI/lqO8b2nlHemL1ow2jqawFdCM 2h2z+N3k77ny0Qu8wS11EkmOo61y7Upl0gepBZMQzCgRgtI7rAA0RYul4RFXNJiq8QATM5AevPR8 YC23SUsZ52ShzIoN+BJmj6YHONIaVM01PHmhHPQqAkgjJPiHXpjSEtUHmwyTpbqRceBEE4W6QbMi JHSKbIex82tdOKE7vml2UzV2GWE8ywyZEtn6kiX6k8RHokO7xpFJcqPwA3rFKdj8W0WKNPC+RQi0 8Xp08jMchlmL9fx4MbumOpmG3j1YjBlXFjjY4iJAiEKOdN4rfym2WENgcEtgaIQXF4JhU+o5D68o 9ODGaQo2QFoKpzghmtG93DOLg3dltg/iQ9W898fR71feACIYsmfe81xofq+Hd6W5Ad18MxyapobM dSoBCGTjN4lKb5q12e3vRwStZf1Gggm1oZRcb3vqnfuE+UvVeNgqUrAbvi7FYwlxhgoJSayf64UT T+60CR4b5AZm3jxvpWnAItLPQpZwPW8fZu7qZ2ZDy8UqnQzFgc94zXE0GVou1ulc6KprjuWyKxxn fCq0cAZLU6Hl0g9Q4f6kCpdA4zVHeSYUzoWyZxB8nBXKnAx+WsURzQRL2ssKjce5a47YOgXYaNSd EX6ja45hDstMaBkuwdJrDk2Ehmsku03yvYthfpTMhExTdxM14J/48NfEhMTHY20lzE5JLIDxhigV ONlIL/DK0J2by8pKRJ27NRwKHHwUVC+63nwII7niCk6hTnFDFz55F+Lr8VXedUiGHFgZCR72nsCc pKmLTWhdiMmIriVkOLwVjZ9MLewCNCyEK9STU4tw25k405Vzi2UXBsCFUN+ZB2IYOJWYkuXAiqmr anDFaWm6m/g1oLiPnERl0o+EcJJb5WvxIt7YCwE1jtoJi+j9EdFSYAo0IpBzWfSdSWQB9Sa+k1yC gidzPTQiRr26E/GfKuDzeMrkdHCSOMRNiHORRXbI+CJDeT8AX7KzZMDesIdDIZSKgWBoEKbI4AQc PGAVOikd0U5fxS3bdRKW9klEckib8u5tNnr0K1M4QVDPpZhaAvnAXzJrBTm04IkcLN7SW6ykY2fB oQekQHuipa1EXGZFQLSVlm1Pf45z8UZukXg9iBACokLNC/aKT9jSVrhAWx4OOCd2EJQZLeFKjNbN 9+riEQIT+yY4FMYXNuZxNrTitef85UPsqaKgyW1SxjuxooGct6QQd0/5RlkisHP+YLbYDneTSZsz fBUUQgDvocPYk8qZDGOo3KhPyuWkaggTHuAfmmSebBYW+lGsqKT9CkvBBj4gc8iTiIVEwbHdfKyC y/1y1YAHCu6a4gKGER3OEf2TJqQPK0EHL+RIBnqJCGH3ED/HHELKMGSQAtUnt8KBQWEDDkFvhMNh kN2PkQuE8KGZnbDkNvJCdtmfN6FtLzRNqByych8Y+gX6xdkb9ouL9Rv0i4vhg4GC6HeTUCTMkJyc R0xapvOC53d4uA0PuCJpWf7kJjXny1xGO1nQC7c59cVsmFy3YExB0b3Dk1YgQBLPr8pZEpD4R1PT hcRXTULtOJO66ua1T3BEAgcl4SLcNJciGzsyJHpBIQAmk/FG/gG205Hh3XXCrmVCwKWBt1G52/KQ 3GbFvAuiDB4/RcnsnY7EnC/2InBg50IJXBx1gYzq0RRkg2IeM2dijjHOTcCCoKf17MXdoM75vGtX Vj9MPQZL8AUYwslags0VCOOM+NRoJKcHgaN2pNTKlKdpqCa5ZlprvOqH0IECIsw8wWliFFWPLIhA XfNLY2L7iiwoweuhOE86gKk8fosChdBJTrKElAOnGVpMRxo0PpNPokjbMiaqccHvEW/oBYx34yyx 4+Vo6csNo/GZoIKJjCuEPNzv4QWjSyd0LOgPnxJGVhRKWgCZmiHPEMC4MTP9sQc8sBy6HrOh83ms zeSObJgWD8GfDIzix2V8s1KVv9FZzNPp45UDo0UXuoZfqgGg2uNHqORAVEkluDPeOx3yYHaByHJA YJTp3Gk4nJgJsBNMAZV5nx/jcCPbUzo9A+5SJr5KrCOG4Uw+TJNAn/hH2FPCmqTVDfwnW0xGGNjT XqGjZLf54JShWl/KeXqVxjESFMTyeeGZ7QoRNDEHfAkjKwpUnTk8Lk+zQxAqmL08gjcEs+kLDwi0 zxf+flv+wvY/dvCSdnJ7ZivWDFVczeMxqbxjo8ELlCNDCasZPKkgXhJwhv1t+M3P8DHAzPV45sar H36Hc82dVz9+lvzYH/f06+FnKfmcwu+9ls5m6d6rX5e7PD58kXLQGgU3KOC//earXw/fql9799Wv +nQkZDdfeOnpNhiVkRLIBFY/qiZ8NqGwPOdO823qTPGmLr9A7fswtfXfiV31YX3fl754c0cKd5QD gzY2zj6r7xfhQ9XjX9FdukCN3eglN6obrknPXaBamtPMnK2nfif27/yovu83RScqfVLfz8s/P9hZ NJHv8RVrI5JvRonFPNtRoxS31GQy2OXBkmD9COVNIZ5Ll6DdcKVipgXlWURLWIkpxECTLplszUc5 wsL5F3qik7Crvgolshn+6c4KsomWxXbyrQjgYOYNraD4ITMQ/z+qGrOEnBnQNT/TKZ1/D1clkvk2 /PQ0TSWnvsWYb8cfjHgyueprjPk2lJWzdWntbBbrUjtkZhIK04f/k7oUfnR6fV2ab8OPlD31Wl16 rtMs0cZDliTk70RJ9MZwJUSTCbBuGvwgT4gS4OAhWKdJhx3yewh5N8sraO8tXKoGmsQhQrGbyJR4 7FWGClhiEdIOJCBAtfJk0u1AZWYLfCGoF1MIT0/cqv1KNpIWQrcWf4SrFyIPY9BFOm31uzWUw3fz QGlzIel5s5ur0kc0rAkTBQbtkgh5gLzNygrHGxSeyXVeb5W6pvLEYL4++q7LrvH43sr0XTcongTT Tm3zlAs+JJWpkU8vnphfSUnu1CR8Hp4SC/5hNTNF025yFscT0NhL+AET8BnTflQSb+BB8/iPzxj2 ckRBcbBULPmCnbn9Rweox8da0KIBFjzCUKB9REHg0Piw2zdxgWHGGB0k+THVxV9GzVcr8ml33ZdM 82Wpeb6z1BBV5KMGhMde0u40Z+g9RjdVJp2S9CZi+jupFyIoDdezYHbOfun7rEwe7Ie1c4+XRNQD t/Xrn/Gt04mJLH/zrmL6Az3kHzmjJc878BZe2Tkj90QYwbp+zywJWDIiVfNA+gR+DzksBxyWI0QV fsQjoe8pfu8KAwFRL5NgCS5DSN9iH5jw4kLaXZR+5eFseF+Ry+h6F12xiIxaSBkaZxFO4YyBbGBY Zd+hgw59Z07FCnxH5jyE3CDKg+JWK86kX7eAFw/z8XFiGUMpTDBRvKS3VoJN0Hgy6WUgMLMFfFEv IoQLKYvkSUbCuhVLlrAogqPLoRLulsqhEhu4XCNiRKxOU6hPmfUZSYhGBA/QFzw8jFiSptsaCxIq iJhOo2SExt3EIlsSk5mmJA0w7kRaAi+0s34i/GYO1P6JXgFn5vcl/UbNAw39V5IHlSMYeya5JTnI ZsCIQ2bLtiQ8TPQFcO6FAJETYTMSCKeMm5n7wZmxXLc9+l3DqbFctz36XcNVY7l5W5qr+VguPA2O emosN29L/S9NrnwHrwijiv+Zsdy8LZ+hS2O5bhxz5AG9s4yYu7JV6aQTw9d4IIwo6XJdFC4LnD6q PbA3j3ko/UxzZN6czKz8xC7qNiV9dGfcbcpXqVc1Vv5pLFmAVoPIY2mSIJJ/YSzLaqwVjpUoKEse /p0eNNOuxPJIdu7xEuFf25BJwIQ8h4dg+hhRH/5ZTeefglfFTzLc+lbZ4VcruJB5QUjhdKjOC4Rl YfAAL4RemLmxhH/XSYaHJPnqNvxbd8MFWOwJVEaTWzOYyWnDuisv8HW+0nar8gd8bi2EdU8//SlZ UmpglPA8ZyOPPs6sbuZMX/ibRy8WIFZTxs3hVGhp8DEOUDz4VMFfGUuJOTLWxIf3AhgKhrQHH0EM ZEZ7IoAW9QKYiK3y+3x3wpsj8+taaRE+p2mHfwuxL1W/j3UKg13kh2QWuCQUgEyAZLZyxv9RkTRD N4qlfmeBDg88APyxUgBMYF722FL4kthV89G/APWb6eYKZW5kc3RyZWFtCmVuZG9iago5MzIgMCBv YmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDM1MDE+PnN0cmVhbQp4AcWbW4/bxhXH 3/kpJnopF7BVSiIlbfMUN0nhoIkTW2gM1H1wN3aua8eS49Rftp+lh5r5/86IQ13WKBAEyMqcc7/P cPgmfBPehGb/3/b70HVhtZiHrpmHWdi+CC/7J22TP3iwCc20aQxicxNm7R7T/uwx19XmNvx5s5lN G8PfvAz1V6/fvthdhc1PBmfwn22C4c8iP/vTdTNjuApDtHdXlaEYdDNddtn/TMTlfNotZ908rJpF mDfTtlvMTNpVFHdmfJvQgy0Aa8NsLbCu2muFwgfSLDtw1kOR/hnq9VW430znob5/fRX+FTZfVFGd 9d4G63Btdpm1Ju9q1o2gL4QerkwjI/NaD27eXlX7J9O0Ioi5IBr9mOkHS4JlZXlVRTH/kqgBamLH lXvOZ7aarkK9SQ/+Kohf4o+qfq4nv+nH7oV+vYpm6P2U6W7OaGbTxWpmnph20S0PNpU73WGbHmDg ezO0SdO103WofxcnTBW1reobntze5vJE/d4mdXYyzg8iBOw2/arqZPTeoTF2+xjqY/ejfdwOQxbp l+t1Jr0hVZcgrZYZUsoSUxnvPbsyo1YDUQzAhLk/Wy7mZhaX1PGf4J7vpWr6UdXovJNdZBb9G4jt 7Y9CN+dGY0IwpCgFROgiNyF8ZN1QfycyA6yqFta3yVkAwBlcnE1A7CZCf61w3+rJDnAPDYlKIJTc sFeWHfusdHriQFIQYKIP6wia5c87lmCNfqLrUY0NXibr/CY1d6BDEGDEYUno4hDlrGrsgOsF4dpu pZSWJg+TMHrwu4SCH2GYCkgWAIa0j9zjCbVsp92wg1joQwrNfy6klqgIomC9OR+KgVB8+vSpq5bC PzGtarHAdALlAWHxDklxTZFF7muPUlHEir8qe7RCApwXq5C3MBoPYpRU9X9vEJw1NBA9iYK2+Acd PSehJ2yMdSs6KOuNZZAYbvvMvbGH3iJFGRPYCp4/Kl6xKz/Qd8A71FkEwex2Mo3F0GvxpV2js/mF nheRqrOtph1vlHT2fdfoJ5L98JVEOd81NimfMwOlqLdKEkeSZz4BEAmFiVRlcA8hkX5UPuzgFUID usTPvUGdwe6v5MBCBBwJbFG+kE7hrggsYpNgEATUvZp4jhPtHsnProTpQW1TXoxZFEcgLIDZnQ/6 DG0a6vdiMgKdDORtFjo0CTyB+4GRqGKQQLNZQiuCfI+JUO8GcqOix/hy++RGP9Mo5vnkZUNQP3lZ tBMUkNrdbBHn36qlrAIvZagPOEQrqKIHk6+3uE824IFqe+W9S3iPUhC8Q4qtRxLPcI3QnivwkawQ /vNEmSgEdBh5WTYCg5l4QjYyarmvMopps4Hu4E+jPHevkDMbkRkDLi2rjc0OlFWfix+mMiY7Yljk xVwEaWFZ+fcHOQE/eeIVJdCXxHsHq2TaqsbGUDw6o59L0mzUhCFUM3+lAo/++EtYc2mpB2XiaGWy uQoz2+f5FqPcQGTBhoVhjv7vJ/dS+Ir23YJNWMUm+5jwVT35ZOceuaV8ydkkBMJiKd98POs3oikD WBYFagakACmfEBLSRFTwO840iNP1sbu2GYMM8mQQyTIJxBQrIPuWyoOv7FEKIsARkubCEuZLOlc1 VpA8aFZkHsikjnCixFVdWlK6CBLZYCMI9EhBkoWql2dv5YCjQCEvIBqfAIU5xpcUo4F+mKWZzYTV ygd6AGuE4ge8v1OsCkk2wop6QKpmuEkm4e47YIp9oeEvdcBs9ya8R8c7YDZfFGZCP0yKfkb5TEKs bX4eSYjLW2Z2WscMitGQiBSx7cF+1rtz8+uWNtog6YXNr+vGD5XU/JBPLrgg5IKnacSqakJuWKrl /eOZ5s3QNmwpZkrz4VCCjjMdAkt9VkI9AfZuPS4Fs6sSx1HKFglA5aG0FeqiSQKp6g8xcKjL87PK Z1qYiP2uaJknUyTqJ+TjrpKBsTiW4ActjyRFOEKNVFDMTb7EUxJCs7kd53pLPanEuTxvx0+QJl+p WqLV1k8O0EuiKqbMj6dO2wSuKgIdmGAfG6Gj/Y+NI2Gkkd1AkBhMGZLVSXJG0mA/4tWnHLgfxGeU DBciPb6EkhwHiJhqgQkZauCSWb5v4hH0XK6iVfnSXRK9jY7/8FP+zo7cfWNhBfmSU/7O3ks5kg9g Dw9m3Grk/QaexveFg0kjn1FoSfKHu5w85Af4R7Ya2eEwsST/iv7kS5aIEgRlSa+1cO+WE4snBAhy QQh8bGBBFIOUJYDhKtE+VaoDK+HTAz8SkTsEgGVuR8qRC4M6koq0goCEQUvk/bCkLumIg2SnoCdQ q10CIc0uzbzBoGeZl1r2hZl3Zhhr8hHHk6OV4+4dZEnwA0g0muThM9x+4Xc8VlqPoJONHu15VrXn 1MljGY5EYIaDU0B6lPHWBJCixWbNSP5EZpot6JL5Acy9Nmot6hMG+iRTEaben6Zu88M3wsQVSJFF drSFGJJdf0FhjIMhOcR7LbxVZDRk3DnY4jBWTm0HyQLE5YA4I+KhO/bCur0eH7QheeP7nttbdKSX AVdYSH67pUIir8/OOijM9qn0C3IjlwDLYS8xFj+mcfAFgfQC9YHpZ4ITuimh/qCoHynXmO9XFS+M gRcIS3eVG1tqe8GmDDoBgvb9ld1j6W9SpEQ6sfHjSou1NLss0t+6WYW2v9YS5st0g6S4ztKtDcSu tIR5K5B0tWJ/laUyKodXWRqDX40OIX6NhUsHTb6Bror7LO1q/HC1OGwjZlKjYOziDStvrIxlvF6A ECzJ8qwsNcT9H2600E6q2nOH0LB4VgXgnke7mpkdx+60ZBeZHHrZsH333vYolVfyRToezba4kM1i yCjU7L0kJZPEFF0B86YeCEQBGe9RpUtg8jzFOY79NmlY9gsYSZaH3mvsfoUNKuQqEpx4mYtMUhGO GseeaIU8LUR4rOgDRDgpo7NOYt06tkS1bemBJAX5f6gaJPLZ+Z2XZ8LP29p2f/HJqkjWkfZXUNxk cQ7GZ8jAE4T5U29mO5uXZhJbapSd16uZYJERqvAhHre2j7h4Oie08NrAA95BJDeQ6Nr3KqXpQdXz LGz7C3zxbbhnIczhSdfzus8a1iAk6M2YxQcvt2qqa6DLloJgoDvqbUQorS5iCSSbwryHFfs6jzkI +rlGcmh2pOC2wNliiwvkHC0gslk0BsNkxEjYhODZ7XRU2lcSu/V3HepPZCnFFdA0bLGHLZQvmU2I g0IdYk16Ha0lVZGjUIWIy80vOOIJ2avEkgyUR7SV+lBL9LM6IxAM0wfvmaRZLP0NarW/A2kv1RH9 P8gBTQRCENQCjeFX6gArEUnCkYgZIGUKagUZ9EDRgwQ4RhBYC0VoPG/UGJAFMqgmuUWOCRMX+hsy LxC7ewdtL9QPB/+mtSLMkNFIHmtLkB3X3yBxYXoRRFCMpxXpVDhJYUoQ+GECxx9Q4wkGpnQmZ2Rv q3E/Bj5qgJ8K79B7JDgy6EEya/YCB/Ij5S3tkFnBltAdunHEUvs8S5fDR649t/PW8yzeNbY8I0rh hGHYpHH+QnQCjKX5gcm9nqfozkZfpHcgdJcFgcFBWrFQSwZjL41Ax7FY8ZfuySVVXdKB6TBE/XpR lmSS7OPUhXQx7k43u1v7oEC30i888W0b+77h8NsH8+nDQYozhROCOBK3FeZ3z3j+95feh+deBSKu YIUfuCBZN7uJIgvK3NQKZHZzC5Ys+UVSAfwhBTWRq+pTLYe4QE1JDG8/br6wREufgtLhwqldGaUP m1CAhkbva3ZyYrkEllijlfqbFiTsiXcv7jEqCByhi0FjhfNBHAP3Ben0CLFYj304Y6Np0lOywv0d xIulUrCocVXLAkAwF1JEiVqqoOizwmU/6qzokpSY5LzZsoZGKqOleCMMK/DmCTHhB0/IQ/4SXDxR NGR09hsRd+Onap5/14/Pvratrd2ltJl7GivV3rv5HWK/mdwfVsUTKx1b8SXWomsv+RJrYd+I3fVL rEV3PVJX+ZDpvp0R9TIf+xJrscxGWlrtyXOruHtJ9uB4g8OpRsYzzvEAiyW5gJU/9kusxXIxemo1 drC96PozrrKBbVIDI2kIPOXiY5nh8wTKN0AyByjEKjGqvEiJbO1fSIS8l65dOv07EaPjhwGLxfXd 79Qs5vnpabqIYy39Iytl824+j4Uw/9bRFtnLKnz0l65AbUh1L2slUv0obPCvdmKJ9g9Xko39vJX2 IQmGGOe5eOU4D2uqp9YwWjyqI46Z2QeXRN3YZafsS1O+GeWQZ9HYgfjwsLV+/srizD4eHRFk9BNU yM2vLQcgl3s8fJDHU8sbejzz4uUeL08byCE5mDTTgyMez46M6L2k9+US9R6v7pyK85Wl4ojH09e+ 42EyP/Iig9KD6jYgJ6uPfRVK/ZGWZ95oJVKCVrHCWLDFF5QvnJ6WfGYBSWR5gDf8bI41CPef4yS5 XqnyFnr5joEl6ql/4ZXwLxn9kaPUND8PSIL5AUR2fQppqUwygOwKbd/b+N1bShAj1OhZQPzARpST 9tnrUnicFwc3g2OzWhwONCf6EQgfs0kZsDGdCbVPl6OfP847q4bUHz+15jiXAGGTLEU/Tr2X3e6e CS/y2kU3bfqv5Bd2qFdsUss0wqc+YOsoVhzxIvphUZ74KZiskpayW42iV/r3b0knZOAHQf1YqQBL TAQMS1u3/zf/Axm5ejwKZW5kc3RyZWFtCmVuZG9iago5MzMgMCBvYmoKPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUvTGVuZ3RoIDQ1MjY+PnN0cmVhbQp4AeWc244bxxGG7+cpJns1C2gZDoenzY0RR3Kw gWzYFpNcZA3DXkuyvaYPpGxLL6u8SmrY/X/V7B5yyUXujAAxNV1dh78OXd3Ts7/Un9W/1OPd/zav 69msXnSTejae1G29eVm/6p9Mx+mDD1f1eDQeG8Xqrm6nu5n2n93MZbVa139erdrR2OavXtXNJz+9 ebm9rFffG53RP1vVNr8N8uw/s+lytFgsO5O6qPfnVs1v3+0m2pzxaD5L/s8UnU9Gs3k7m9SLcVdP xqPprGtN50VQujXp47on6yCb1u1SZLNqZxtm7+k0nzFnmelU/6duri/rq/FoUjdXk8v6i3r1jyoY tdwhsayvDZ12avou2tnA9E7T60uzyNj8pAd3by6r3ZNRHBGFyQkSx/rR6gdDomVkflmFSX+J3CDF gCcup12MFnWzig/+JvY/hB9V85We/Kof25f69WOAofdtYrs5Y9yOukVrnhjNgls+XFXueqcd9wT7 zu+BvnH1drC8if/+VkpZeAQTTYPw414wZLS1G6ARUa7f1RH2OzyxXqfGBdb5vKhF3UC6ib+qRrz1 pG5eRd2deCsiMUa6Bj6KemHma5mJE1yAJuH/GER9gIaMbKuQkX9SUu0FPd6YL5eJN/pE6tP4oUmL +WiW57658KNo9pkmxMiVTYD29mchEAMz8SsiCIaIcNUIYVxGNGtEkp6K/3P9ePbppVWV0bw2p4bs 3IB+LqluvtY0VJaE37ORyuMGNtIC9fRgQ2wgW3xfKs03ImY2fL+RbJGAlbgA1RpJTMKUdVIvdgkJ m1Ee3aOIVT7jAr8h5w59GePHu4ugcdXcNgC4kdKSKqv0HDejuSgsXWJobUWsIfRRpmpAhENcq112 5Wuap9J8mqRSXBEtK3AMCqryYyTqbO5vLzNDk5Q+MTtntliSnaem9HS4Kq+ia4fwCAvanVclgohQ EZwB3srdCgXoMBkwgKckfi3P5iFHeFFw4Qv827sNHGMKJ/kJvUICWlTViKwDnEhaNUinhKHYhl8U eH8EeWRZNbmBvhBjzxppUggIpamnAtmGGpoEP03SQMFN8YvdxdQLDwqvMeKXUVeeIUjCCdBeJGmx 376gxXcKCvDAdTzBahkJHtAGNX0dgQJdbO4DpWCSrqrjsBRbKUBGEUrejTD0X6itVQy5pkWpzAxR AIbsow/UA0LsK8Hl4XdCRNYe26xOP4uTZKiq+kq21hAKgqaHSoh1b6hwlqwTk9IlkGalvnLMcybA S3AMOEGW/CoTt0zDUaAWQ/T8it2m/dSpFXs8vNx8TIeLf9C0TKsNeIFgTp1AyBAmyyO3jjNjUJPW VnfjiswY1OJEbBMpaLbvwap5oQdQwFbctgzhN0AQTamURv51aTvVfqsEFwR4rADzbzGkq2ZzaVvd fl6I6L6bDAlMx8gkmSCK79W9RQpbS3ISTxjUwiasRNEE4NDRMgkSZksJScQFOduquc8f1U0iKVjL dERuClFUIaAhWg5idEi9sO4eL82za+uOBrafvq7GapuEPRqB2O2loAIGqkihHSZqJO7Rz64Ts6U1 aed2drP53loUekhbi1qlottyE6NURU824j498LpOlMo2L+uHcuBzRTibV7FVTlXNeo3zwRykfQ9R CC2c8JOslAy4aC5TWFRwtwuKY740eVdDRGM5a92t7xAxR2K1lGMeUp0iqxkIeAdtnF01aCE7xaXM QY3cXubVCW7wF7czmvw6bfLzao+aSKDc4wc8xBOCzJNUjM7PoVm61voujT7p7HSwco81hZvx2cEl IUmHiFbuFqVFfXpahEqPcJCU71FYDi5TPE62XIRYs+Gr2acBUA2viQCAC3IAWBqstQk58bvSGr0Z Qtu8ihFXMiOiUjUxu9PDWfgyJtEOh2LQz3Ys8wPyt82a6uYBBVOSHhbi7mu7yYnxIH1T2B9Y5KZZ b1jZqZ7V/Ad0D9ia7niirBGH934YJVtOKBrJTtmLbcEI/6cI7M6kyDerDBEtIB2xaQp23cR/F+yF b1IqM+SxCA96JcqDlXCOAeBrBqWOSCS4+CFJ92hJPBPzomEkj/TCoAK33jU5Xmil6VQNL0Abj88t G0kCFZ3xATwZKppESYvWOFxE4fk1vgs9XrV7N3Xifmpmr5WGGsPoz+SEyF8XrMvI9KOlQyZX3hUQ TnfFqwycK28TPQ+H6WP2RQMtROk86XJ8XxQDi9zUvqg+vC9SEGBblJ3UB7QhLAEYrMRGehL3Pyra RQE3D2hykKVkMO55b5cn/hY1JP4mq0ASnlgZscKUIg6gJVbERVL0729lI7aBlFcrjpIgQmt0MMZf VPYe6eBJ92w8vKWAA7jHH0lwoROpgwJuSHy/JwsdWUu9iJjG7nAbAHkKvvdFRcwTu3PsxRJG2EM9 Ewm1DwM3paMgwuaSsxiC2Ft2i2vmYyJUmkZRwCzZGdXxcopszX1PKSZTPRlExCwyqMACEs1xLlqY 0FtDyZnvHYOaLxMIDA0Ma5wFBH3XB3GfefbyMb0e2CL0Rzh2rcFy4sjthGl/T6G4n2DHv/n9hGl/ UyG9oRDemD9wQ2E6XyT7f9+78Ir/yq4bJJ1hcUdhutjrCzmXPnpLIXRPo6yW0SKOA8yVHSjEtGVI fmNkLpJjtxRCB21z94/581sKyaEc8et1zlK3B6K/rMELuumi7UEfuKeQXFFx6rldYfHrLbGD/qcs cFGyssgDJ8mrbuXXQKgxYsMDrBrqMkRtCRXj/2CuJW8gy1yjasUstM0s+WguVzAdi/nJvIh4i/e2 2r+RM50szo/3zq4jyAUEq0f71BW02w1ltHdDF3o6ASYIKTN4yQzf7S5EQUDHWO8Pz3axXjUMifa8 WEdOH+vVwRs5J8X63o2cabcf6eEG1PAdkOmkL0YAzQnhylLQ7vP49vaORYUgZd3xlZbVih/vdIz+ JAOWk3eVfKEIW5ZOJOKufA77IyaLgiBnBG4SmJEm3b4ovlTmkx8w0WTYew59mUcbk2Cj2azlWLi5 3wcsOZIGF2SKjZY93jncRNBFEAwaKkHuMBntHTB6ew3ZxGdJky4ZII4tXgz3bRo6Liy4SB0ggj/m Kzb1riW5xKbZmIBS9DI4Q7QIoB0D8bTOqz4eSKy2X3CSxIqLCGLR3gOGIiRNcArEwH5vvpYGRyp0 t7C2YbBGZ7cmu0Xf1597b7JbDr9R8To9MzV9Q1HU6W55vQ9TfwfNTqsOdSVVA0ijrKBQjvNKXR+s 1FVzUleyV6n/n3cnu6V1m4NdydDtyW6xF1ARqVWEgaglVmLUDlUO+gvygrgkHd4zxqNv8ormuzOF rFoRMoXbalciiZk8UGexgdl+fqDZDOnBbWNaxEbIj2fKcsFElRg/nM2Nrxo3Hjg1jQeUEoCSSoy8 imfCGrj4pFhJYMeWDBTybbI1aBd5BYUGl0pPyUQ7tNI5rigu2G3iaX5s0ss3u87o88yEpNpSr/jB eQpawJkfoK8TdDxlCqrGDVfZbt6lNTamREQyWeYwPZEVslpooc1mjUfQmfjCLhjiNSz11Y5SBcc4 LdkCj9zEY2V8cn2giFfp1feus42hX30/aWPZdVOHcKDRtgqZ+KAs4NOkT6d9/GM02p1tMtIt5bFG u5v0pT7pB2Ks3mSrWEzjJEIIWQ9RroWQKYQq1EpuJTtVhTkKfVH6q2VqiYYi1ySjNIJgMiJnSyVG cJzj1+zETFPhpQEKlL9t7D8ZCff1WZUASNNyiXVDlr7f8KoeyCK568X886suvLy9k1ayEo+gd0mL BpzBYQGVB28liERo4EzhijRJfEFDlwv8rN3Q2BFlZK0jyuQVKlRwKkxlukYMFC8vg11Pu3duRYnx TSchKIDjmjjQYDwQRzlqRMYHl1wAL6v0bFFP+ts5taV4+B6o+DhptjSSfkMwmYrk+IdJY6O3j5MG CgaHDLS5V3adxzEsz0ImB649/TF67Mluh5GW6WNfKE0WQ+dGfyWgnyr8n+uHPhvx03bSkFkXTCvi nwcK3ufqZWFDfPOC6Nlb3/LCADIKA+eD4v2pl0/lH7nu231qRdZs2l4fYe9K7RAraW71EbDOVUnM kW8gh1NjL56kLZURbBjCEoYCIlWj82lJoqr5N0nlZPhCzaokPmgs6DVAC89c94U2NOGcJcnyga/r JvP5QL1wL0StB5Y3aYKf0BV0DsRe/h6NIMAW8T7F0clacs602m/xaLeyO3M45wrAZOZtcH5roBre fEym9mGsjqhZl14QdGDBDxKSBk5mPi6zqgaPqQzpDCz54IAyRNhK6ig2n/qIy/8dNkfxo6yEF/GA BTia8CIXJIYao8MBDVwoFcpWKJBUzVPV2SOWDqzqYoxoS6kYqz+Io7Qg2E8BKgCTA3bhXcxwfzC2 BuBQd1D13cHYNnjeGxzduVlv0A5te7nV652BnYklNaPYvE0me++59s/efEFzEAWrAkUQPnz25txo YB5/9lY1j3ojuPeWZGJNWtoVHNu8TcbDvdgqP3sjBwSUACpjzE+YyKAc1Q/58kTsRHHgvztfH6p6 Q811ez38+ucmGpYnrC4Rpq8KZSJ5ha0/KtNYPGTHO1LWS6L4nLIcepWDkS3/McF/o86hEhCjkjR5 ku2/t7EUJVtdCjrsigonbmUdc7VkX6ldeYqKmqRekOBZVKJU8NcDv62HaHuRE8ESkTyNQPZ+GgEG GcuD0kZWByRiEdgx5B+GbK945XLw7Cx5pS3dvV2CeXT4Dq+kAg50Te1uX1au4wRWRCQ5RscWIbHV i7ejCTh006Cd2/uPcz/raGf9S51S5ZvstPnIFhk3YwvBHQ8YvE0kqI8kNvwULfJN9LIHrn9Eh0R+ cLZBvp523iBhfvuLlgvl5SvRcqCC6nZQZbfUZ4/5csu7C/B0O/OgtLuQUkJKoWWE2Nr9x34o1E7T terEPwXRdsfXgWiVe7FQHI/JNIBgxBNeWzYFC5VEbHngm7oneaH2tegeEVeOOhGAIsgn3qRrLKbJ mww/xMd7Imb2QDrQQZYXEpjGDzEsS7kXNN//iZq65NCcueBxyWr/TzuAkyRxcJtHZ93o+MEDwmuN Q1cwwk/FCN05ngemwgHohUNRPcSPa/VUHchz/Sj3SYo56oAp50vGYNc0yd7tx8YZ3dEH3aPl1jed sjQKHnm/5g+bgCCA+ZEOiGEJOUCoupugVjKiK7AKGR48yXKQgTLuURQ5/JB15excBV+DoNVkTxHA Lm+n7G1cY8MDJuIkK4lyVBcFLovA2iUEOlqwVi3TpPeenwQsxPwoTokYyfkVCDh/r4SypTBBJLV/ LQhN8dde9MoIXcwmz4jBNmY8fI3D27k7ksP/5EChLSFCI0BE0LAO/AWP5Jqa0BfrQ041FzIEsq4Z 3ScgeWtBNLBW3xH+IPag9zCV1KQhuR95mu3fg0VlwNw+cdpdOQ+GVw2kWCBoXrz4d5zz92zubfPC 40SLqn1qj4rkDjkHdtgjMbmQ/rZFWHl8P4Jud4h4zzNARYZYPw3F/NDp1/FQvR7qnZNXRW8VOiiC sd5c4GfGpJtufEBBr+eld7M55fic3EEGySBh3gsgzovg1tUltHCgOGyJJM8HjSEOByi4eDAKEXT2 tie+2zrrIy37awxDm54QZ0nAo5wcKXtICSjAjx+UGUAnDAlRhsRYgnIBvnyJ0mPAu6Q8g31l0yvW /gpwXL0kCmVoHnlCJvJEk9jZsSBB4upoK8sdUo7agC0BIGT00Eg4KCWJ3rooqcOTyK8q/4oEJA4F 5sHauyQU0wqGYoVMEoY58hEjXsODlbHs1Ccduhdsoyrem3rjRg5KS0yjeGiEEONosI/P4xVvPtyt worgQmcyvwRbKAkc0NrEoEo2UX6wo1nDsR1fu8tGnP61op4n6MMTTTp4zxy1sBd0sVfqySjCxqsp kGgVK3NIqiBIbGGnByyz9rdU0OZxy+zH0QHJZ3ZwXOe5fLxO6/WAfT8wGvd/Y7VrOZnyD47y6391 Q/H0WBAUMpi/2YZuYM8T7740m6EE/L6sJF/R0iiql0EHfjC51JzIhwaRG8+qz/4Hmvu4AQplbmRz dHJlYW0KZW5kb2JqCjkzNCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggNDU0 OD4+c3RyZWFtCngBnZzbcuPGEYbv8RSwbgxVrWiCJEjJuXAp8SallM+rXGVTqbW8u7bXWsfk+rB5 2DxLGkD/Xw8xAEmpXOWFMDN9/Lun5wD+Un5d/lLOu/+2r8umKTfLRdnMF2Vdbl+Wr9o3q3n64s+3 5Xw2n1uP27uyXnUj7Z9u5GVxe19+dHtbz+Y2/vZVWX3x87uXu/Py9kfrZ/2f3pY2vu752T/Naj1r mvXauG7K/bHFP8vqtx/Oy4v5bFFW9vCv8vbvLYH5bN0k/2ul3pSb+bJcrGfzemWN9aaXvTYh5uX2 ddFcWodVuVipQ9N3QO89odZz6305EKc0cerzopdmLrEuliGX0bjsrHFZXpmFOkk2dTNCxwa1dIqq PDdFTLufRe/unb+Z+b/qsVAPWNd6401BjZa1unzs1KBypZYnwafezDZlddu9KKq/qMdPenihh1/1 sHupp7dhhkR3A9G8ni03tblh1hQdnvYsHX3n1mHEUjchXmeo33uGRVgMYZDzOwkl290j+RsEVtsL uVQv7vAFlE253u1yDlS2F5DevhYlxt3TL6Mgbt+LNF23/lRU7rQO9l1MtXBuY+qDLp6GoYQt15eX iS1tUHHKoI0F4ogDENAVLZKYRKvX0kJqoc0f/1ETr7Ye00V1wD6YFa+K9A6K9Ll7KdPv1Iu8gYx3 MmxZMTDwy8B350UHNPRGbpGG/xakfCsloexvijZv9dhBEd4ITe9FGXqvBqh3JRLUo9YF5Hglukge giI7FtsisoblBDP37t7v1NuZmDN3TwZSwz9cxqs7uMDfDVRUWArD0HloGP1NyEksf1FU4XWzsmaQ 8Ry0Xq9GQwAVf8NBiJgxRlT64pdws88ikl4NEv4B2CsqDYJfJDCkFAOEA+445K1CKKbcHd2hjS6M y5JtL08CVTFHKzwOGnmALIxKj0dCDFD4VJCEM03Iu2/hMBaywFBS8uJA5irbzOU+RFD5Ae0y60cY 0Mcyl1cCsz54Hp7sm0UC2lOT/eqU2baoMDEGBe9olwFANseS2IoxMjZ20IvPlC2/9Fxye27FXFuW qMf9z7L8XmR3OTuQfy8hEHyb+YcUjVhILGboTySICgBSV1clirBdVB0w4AFOW43njXBXVLzSjNnh zqeTh+HOwYq9hbuyejJI2nSBwcDBh4KIMdKKmQPcYMnv5EfUxDr0gR59SFzI6W9CLFwuIfAVLfhV XeRW79F58chksUiLLF/t2BKBVKZJt6jC2KgxsGmZZ3FJxkRLoYpRIIIttrzChP/liXEUquIRccN4 JL1AIaw3pBimxzuinIfhsAVg9C4oKl7k8Y1Qp03EDnrkxgC72WOTbW1FMkvcU8vx+XhZceMzmyyy y3GKLQgNHKRRrlQy3wrLWEtd1QAfcKOWvmdR3QySAlxxPW8w6oftmDqQLFroEMX2UCA8NGxAUudb VLB7o76YBtnyRZ70gx7BpJZhGqTcQHz1FF+E/lWJjFwu1EfexhfIjwGRv61emtXsqqiuP9U0KGbP k3dBFf9B9fm5Rmj2SUxGd7IyYiGNhktbtFQdFrkCplEx8ipSngjGWm/W4/7BlU5zNah0bC1cHFsL N5enVDqlVTrDbIHjcdCkkYCV2zNddQgLGDJPaztY4RgeqJ2YB2RQeQjmuFctQ0xnoJ8kBS7U4zfe bL3ITpZptCEBwuYiePkiwq5oUuyAIchqJi1jbmCiyWrqdLoVE2wvZ6ghwIxv4SrAH5//IuchFunD yUVZiI2AFQ+IeUcnuRKpqJqkgnow2BoOVy7Neq9yKbo9Jatczp6JFuzxBeahKUqNVuk2b5XVte1e 9rsn5GLEgtTZJCbo4tzCaBJsGutDc9CTmQPf4NDQhSfiLrZF6O4kQypQznDJibtgqhbk8jFROx3T oKwghnV505NPigBRGwIxFlIknaHZS1t4eDLMF00xtzJMrLACUrnzLR2qD4U3dsBUGb3MZIglagyB CA8A1voeCYcmremikEedbUy4UcK0JaTo7p9HFP15RLNoZ6vJE4nSTiSaxbLtcuBMooiDEjuTaBab ZKkfkrLdP1fZcLEK6cZOJZqllaTUsUHJzyUCJITvsXOJooI54nDYIH/RcuhcwqGXZIn0XKJ80LlE V/zITeyPN8va7JieTPSHQeO7gs3CDq7ui/RQy5LlzaBCBthYDHB+mBXGfY6Myec+iiNGCf2yXU63 b4kEQkjl6SFwix/plBB204slXRBKLZEmCTjCRalIfYlEuko1hsCIqTDZS+6NRR4jbYmK+NxMeSSh 7grCRmNVLJdV5De1Jfbx2sUViYmALkmZhHIw40GU9wHgsmFr6aejO40Cafgbw/rYEGxok6g9EQ/3 iD7mkiOfDAybEFVoTUTO/hlqewplkaMaDKPhUVTPZLp/Hwh2MxYQkuCMgjIPNGEqnPGD5jq4A24R xlZ6MTXxJ1Wsugay7vAXFoYlYmkYm5x0UUsmDD1ooWJ545ySNeDQmUIZphKfCASEc7oBLw2OYumO ZTkE5W8RTvDrkEdw0VNX/Y3lEEU9UNXWCE5NgxAgwgynaziyIILXLkUFZKCTuw2kDK0KOU5VIGes k6hJLlJwJYJ5anW1Tg9ku1Pc379/+XbWHf+OnAiP3rAIcpcryNV91X9s9bza2CWP/Qsd2dz3yFOC 0UWvuxA3E2hymJwLIrC0WtTT6Du1CDy1MUgv4EOLyLkoRXXxyEgO9HmeSxbOKSi6AwxmOSwgCXPw aalF10juqJOPArIfeVYnRRAcPJCYoReBLvvAIaY+LZzVhQCa1uUu5+m2SVKqwb4zksjcDP7GmsjE G8+RRfVhOybbpCwj2kNDcoP4QbZXLNIgDaRiG5IEeRTxEYtWzhNYrMCvn3HpRsrp3wtZE3f/oTf7 yaeodpnBRUSaxP4CEo8bpsiPM9I7WdgXocSBONIL9i1iM4fcPXKFIYZ5zZX6xeM6Nzvg3jdJWRFX QHrSh8PpSlYm40zpmpxcZGPwyJa1MRaKsJXSeUkigvCOQcQmbXilt0LgVFRyVYCBRMgQ4xokShKy 8NNgmTC0JpZCawChUfftxuKRqFmNXcpjjoU4yFIBVMa5gdjJGAjZN4wspzDsvcYyJrMbLXcWY47T Q9coPgmV93cR7NJie6txZRcrkz2E/gZde+7U3mps9xBWdr/w0A5CctXSUs6qvhpJOyzL5+wfNCHX 2P7BapFVJlYXPH73oNTuQWFXLD3iH7d74IOfxNna43cPOtS0iCzsql2k7sXy5L2DVd3uNJDo+5t4 WQXVnj643OCHRDUVZkkZQSKMml1InUC57SWC6mxXLeaP2JYQvWhja1BNLnq+Ljt7hoAkaAKHmEVP OhPXjBqwsqkILbZxCMU7rHqmkoR5gD55rqJJ3GRDT5tJRaIeZEDG7u5i05BsJEJoyJoFc4giOJB8 asBeekH+J9+IDcKo64Mq2CK7GTIpkxjm80rPOS1JgM1jL7cur66SrcsTj+CXl+M7p2fX54UdXSTX iz5VJH6mh6dfdVeQ1rEpmrtb4Bs7fBoptuSQCEIAAO0kg3VVb8z4cbYKkCIORBqcOOVkQasu4DJK siC9o1AZ8a5PbCIkjAIQYpkHmohJlz3ZmsjCPCZOmrAT+sFi9/Ejz5WXmyZJ0j2ijp4rL9ft3n2S 2duL2ZbZvwA2Tx1KRfVvvfv8S1+yfKM3T2m7/uqrBHI33vHp/u5f0dVHIyv/ybvgyyadgTxcTM4P rDpZ2BlFX3ENNrdHcCkUyOf4Mc+K+Eh98ZVeHA6yfsOXQCCNKcjK5EKVKBIJwNYRlxSsQxXApPAr YshLhPhDMucilQbRF1HUZcxnhX0PM+2zpaU4sHVqimsPh0aOdHJAlqcAsqieCaz/EFhBLaBluUrT 0+vP88x+2mbTss7jsA2pD4w/UB2ewzwCqu35ZlduJblHXsT1enEYqv2GBEsZeTz5RCIyqigyS8IL zPqbZNUNqkhz8BA9umTAsxm8jyV1pfyhuvSYGINo+8nWNETnlv5AW5pWEl/tfQhmjiQxoAMPmBBb RKWJsJwij33KweJM+2KEt7SPnTgEiU3IvNT1DJd8waEEggdFGcsfNme7jBg/KVlcjWTpY5uzi01a CfkhbnU2tTk8zXzdF0fD0LrGTJgyswAOxDd9l6LCSBgHcszmmf2SY78+tORMqBE0EkU09Dc9EU09 wBjq3AGtcD9SiqCGX+iBKKUrc5W6aCzCYITAN/KdcmlGhKEDb7UwRWEhSm0Ghb6kk+gtQugp29OF QW/QgjZSC8bFtr0xYhvqgWWd5IIV68LM7OHF3Y7uoA2DI32+0ZYxsxddcpyOnqaftYbRg0GwvkAh Hlgqrz+8wM6cDC1aIqmBNfTUkiGZ54YyiDXWikvI8EJODD8b7LzfDP6mOGQoYABDRKPMIWmtvGPY 2MWIzOsc9ASwMA/OF5cjmxFueKS0nYM+EYWB9EamzO3e90iKRfRBHIwbq0N4igF9sLtYhocR6+C9 Dt9cklxAEzoijONo4QGTSjylh1H9j8TMarB48qsBuBauYzV/NkmcfU7/Nu7dh9iaRpyJmrnsAzXH bvJCL7kYxjC4hpl6ALHXM2zIZVCP3LkeRkV8wZqhBucCHzmXtAddgIXhxXqayoVSBqDeal8p9s5F 5oTqHE6YtZc3OVamhQfMLUYoQJc95DgkHv3dx6K7MabV/omH54s6XcbFJbu/ekpxByXZGcfgVR7e n9svJLQbVU8GuZYx2uMMm+8iIeKszHIY7A8AY1uK/boBxEw5Kdm5hg4Pziom/kTUPiZi44n5QWCF CoUlgY0KOF0oQANRQQHs6IawjTqkoU1k7BNDz5hwQJz7of1tn3eYcIhoiWGnPP034MZh/ziCrs4g jJXs6/pgUUMWyRszJ6pgrGwQKmm0eqC0GjDQw5F1JP3Px7cqEA0N0230HIPu3Ug7Q2vGlu0ZoIE2 YCFlfy9PwgqbbHdMHs/jpyfAJrQAHKiQeWVVlusIwsN2B1DiOx5zruMLf8SFFl4hMQiAqhh7l6Li K2mJNm22gwHqYmGEyLiIJd4ZJ3r0LQH7g7GHeUT3xpOh5iSQiuOG4ZpJgp1AiIgrC2Ke3MsUEvAj keEIR3Wn4uG4qK/SDbCYMIgL5xLWgj9awJYHqQNE8P+3Qhaj0RBjEBwiQ199p1zq9xqSqiSnwzCU GXomCQwhC8sDFzolgebpEZElqQ/qrEXWre2naLT/V1bb+1xSXIkFecOHs5gwJtvTC3B+sMDOxSTr NCzVA7thyf+hcZZs0ArR6St6tETs9JPy2aeCxWeatvIjsGdIcbDIOPvkvD+ysOXz2P2Gmf3qk52m r9vdr0UzW2w2y1X24012zUH9uk8qlurnPyg09RtOGjT+uzZ2z8AKKjvV8wsHdsPPnpIAzX7Kqbb+ sS0f4Tly7cEBDCZmg6KNuw1zmXjq2kNyIeLQRxMeA0lMgfju9NA36pM1KSFFxgosG1hkCK491Jv2 Q8r0o4lDP+dUN8lFk/5Xi2wD+NbNQFw7iiKhcY6gIpkTBuEW4BEQgF1zCdBmahrR0Y4LO7x3ik6d qCXf34QhVvFDZSeezdTLB++Vnwkyw39J2qQnPIlZZStS/mTf/JQf+4oxM4BeJCBLL62OYesREtl3 iJ4zppySXGkKp9ilHJZn6a9k+Z77wXvW7ZygwdpGf/HW8GUnIIkQOhM+fMv6KoB/+FiEW58HXO1h Pek+FbhF3HA80HfoOAJHniUc9WI44jigJBF3Lg/C4swTTWLlo79udrkZnjsdOyjZjGVtzzTJbZ4H bjtq18O+GXJDJit5gkahOD3B4wWy1U+agGnSHE1wiiwvSAKx5sebEH4e+0ZvNfGQRkUyVpM0efq0 RTMSMf6RmvYbDJRzsdCIA9OksjjEraeEYHEGEGsoYEvd9qPUj5lB5b7sgPZMJ/A4JE5fRLGUZAyl nnwZKidHlxrtgY8LTSjNyOMniOvIf1GZ5HsIdia0fyT8J5+Sn5/vcVDxs1o2s/myXpTLLEXafP6N gAoMcShG4xRKdgUwDHJzJqEYt70VN3TGLaKXO/dvriMy8MBg6gzoEkD08SbbAg7TfP1/vAxX4wpl bmRzdHJlYW0KZW5kb2JqCjkzNSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGgg NDI5Mj4+c3RyZWFtCngB1ZzbjhvHEYbv5yk6ezUMtDSHHJLLBEkgW3KgxDFshwgQZHPh0PIh8kY2 6ZNe1s+Snun6v2pODw8r5yYw4KWmq+vw16Gre5r8Nnwcvg2z/r/9F2G5DOvFPCxn89CE/cvwefek neUP3t2G2XQ2ixTbXWjafmb808+8q7YP4Z3ttpnO4vzt56H+8PV3Lw+TsP13pIv0z7chzm+SvPhn 2bbTxaITug7HU6t/hPqHrybhdjadhzr/8M+w/VPHaDZdLbP/ddqvp5HRIqxnizBfTufr9aINzbrq DWmiRrPQUd2Jqg3zhaiWyVyQOFJzNdOUwsKoZjOJ+k9X/Yek7u18EqRmZHTXg3QXNhG4po1ar5tl NLfKkYp8FrI2TKJd0erXerD7zp5M7a8oopxOYlXPRBqVSTrYUKhFy8hKJL8xbpBuJlWa/MTlNBHU UG/twXua+7U+fKoP3+vD4WX6VNX/cRgy22NszZrpYt1Eh0wN9yO4nXbWEZRIvTBtDrINJfTgGynD yD5h2CuVjDQ1Q73XrM80i3j7fBIDqAMgfuh94pNeCqxoZWIoL4md5uxx5IOGUCs9qGoURgAf9n+Q AM2GH5pnosyFp0SFzisDADD3Cw19mT5U9b/0xGUW6vzu91Ex4qSJfq1d+QdjngEPK4KIJyjwRrYq mkJNFnwl5JmGSVOPuLH6EFarVYyo+coScaQ4RJJ1R9KK5EJlCKt1Mxqk5Bt5fRsfnSsLq/XdKCcY CBPsBpJodx+eovg/LAyr9TJaf21pWK3akcLwlIrwTHH7gT48/6gP0linBRJhH2dVPXw3TCNBldQ8 0GwYw8aisKpfieb5TzvLpFDDgGAl2MkWzftIJaOqJd99zifS5+bJwP0HhL3JtLPKgFhJc6uxqQQL lUJUKaGFIjs+uUpijnxcs8dcq7dVzdoBNpRiLGFIiGj5kiRjW9U/UUzLyfAdKjESFrJTAqiFzHXD H3jW2ZlluTc7LGur5XzYKMXl372A1rKUB9IEP1EKQecXxF7y6pGjh41I6WipdDTtiviYppDtkeob oa5B61rGX/Xt4rBTdPDaGeBdO2V+N+guQ8T7rxZ0VU1C8MGdKRfIzPHMsgX1Cy1Monaf4rEys8oM MX9XVCoDqz7190YC4UU8HJIFlS/JRBO5oNl4V+2EBm4EA30BCInkmersGUvJS5W362qJRGAcpQRT Ekl1EiABd+O5OdofLDdxU3CuO1huHtMbLDcbj7yqj++0YUgNGAv7pQ3DarZyPqGpYp78og1D0Iah 6nYvSRl2AYKbkXMbBpv8xJaEOJdGsF9RH7Nh6FvTriBUMfs94eNu7tquYLlJvRibUEOK4PQQInRI el+XiuD+MYFU+UZ0kBC+ehQDLtKCsLfwMSVvud70fSFWdXUy+n/bl9CqpsUo9HaTvpWbWWrRy4ni ImY9AuVD5igoDIlscwpD1n6rK16+yoVT7FRoqDzsaPCPqeLcUPyBeoJoEPD1uDDlUxkp22CIFsyR njyAJE12rQ7ggFZ8YJJtQrMDDRgXa8cQAA8x2CFgYEnlRwfwhx1YybYD9pMK2SwLiGKWRKKM2MGN 5cWcku0ANRlaxQHbPtRFFdipWeeBryYAEpU534Mt+11eebRAfKOadCXLsBiPJxKPBdRwzXZE5sHx xjaATyB6149Qpgtm58Jk2AHe1wr16Vt2W8tltynT0VyTlrBLLdqyXWST7Cgw1qsXtksxPR0vQYyR +weWeNBWiAgAjFQ8eMofvEsDHHhr/j1bqwxki3bRMAloveMn/IgUiEyoG3iNEanVPu3WyneQRTKW KghSJMskg811ozi/0Rys1hxBD7P9A+gPN0l+XgMc4it2zN15fhzM4deEfpmjvoTdT55YlCkswGao Bmwwi4QGYHPyCFo5SBdKzeKoKaENdKWvWpyJN8Eo5FFfA5QfgN67V0TELLIRoynCQixLEOv3xKUc YXVFX5DaT+KBf3eY6i5KQU+koFSS7LBf1kQxWvrQ7HJmjy4UACqXVbUv954KZJIj2b8aGLHY7bGK A0hCVqLiuScRjB48YRpeFGfxOYWttxNuCvztQ9ZHnO1cBkFB2CE75uKFHGnGW1wCAtUU9UAACdKQ jx8Exojns+0/YIr8ERWigzOdeiCdw1lCkiEU4wM5hyOxa+hRwqzQF/6QGP9s9y/bxBUxGgBpuB1V j2SkZpf5LzYjUAc/aTHVq/p+Mn3b1mTWndM/sjVpN3k/463J08xZlpGYj4/48OZyWvcpke0X6Wdg QgATt68gKscUXYQkJIUr5IFiIIuX5EWY4UaiATWzSalY3xDOhOorTGA+rBl6x9ZlGPoxLY/2nGd6 +MBA9pSO4fiLNcfQiXV6h7pZ442aMB8eJhfwygGHEiskABp6yBckpJnqi5FXX39VoFmyGJGYrhFp xQAGRR7nS257N+jS7awEy996e22xLx1hWKIuQ9EaEk1OFGffEHj02Fnn2LsWPEKEIZMtgrQBTD14 u6Z8Bx9EiSGQoNbpkxdo1eGwVJT8jV0WXa+YTl2XEoL4cnSdtj+DmuAX/3t/eVxEPVpJCU0CEJIK 94okTcl6Ew0A84koClnXBhrfaIvMpF/S6vTIX8g7e188PM1DvqnmOyHAggRLCYEC/dxntqJdMQsJ nMMxyYZcLcGOpyDFifhuP5aaphbU2Amj06kJSdIia3DGlxVrUS8vK1V9Fkrjg/jSAfcTKm9cZcs7 SqFd9BcM/C1DunqUXVCKJN1NgOwOQrrDdOp2UmjbedYLeVvDEb6/aVgcteLF1aS2HW/EYSCvEw50 TlM23qlR4IXCTGfPqMOQuNlIVV/1riHxj3PPv2vITkyIUd8IRxcqUXnX0Lbd9ZCxtw3VyHvcNt5c U//pmH8oa8ml2AvFfe9S+16vzi8GiBFMXN7x4yYiTsuAmRRbHLKMTDJX9PY95k1DO1889uVqG6/7 lCA80wsTQEBJmlyjCfUHQqx8N5r7zcqFQkYrB8sXEoYUDOwN16r2OnD2rBBdMYO6SJXGabtXCJJu B92VerQnFpvNYz2xuBteouxeEqUYy87ehc4nQv19i0Je1S010o58GHiBPh/bxZ8HRK63zrHPtyaR QcgJYjESmKcdbUyylkBzTE72ugqBYo9rlVhpICseoqRnOOdyEUMTY2hwMFCogO2MeO+IUG0UsgUK GW9nblKrUFgPvK6IvUZGIEu8rk2r6aDwHRfCDHoKIcggO1NKdXz8FulivSSVvEz7K4L8ipQt70Xf IWFfqlssoBc2pxPCw99syHY19BxF9OcV0LSTqEIpop26pZgGtaOT+7SOPjlyRpZE1DoJIk73utWZ 3SZFBLa8FljAefLghP0x5kqmjGXfNhzwMEU9f3skYpRL7PIFQAJESpm52sW+oBcuDn61DVgKF2M8 m0DpNLL8e19PS43dJEmy5YrNyGK1GFm9iSMYRqnDbh2pUha89OBA7YJWZ9lV/bOXOCGPWLyF/GmK 0bFltIpfLjh5W2yx9O7kyttii4WvvF4ujitU3EliEh9ktsyxQMqqmUZE6Uxoos9goHVko1VZbAAe uIoQo/OeaeHVZOm051hBT/CCSP1Nh3c6UgodRIwKWES88gR9zfzsvBTh0ByXqeCHCydKRsZMFkm3 UhOSkw+iNWVjm60nP+BxxwwdUHcHJ8gNo8q/cABqTAM2SRspASrq3ysnvSbARyV3LGO6r+Oczpj5 mtXy2ozpv84yPM/o7mKnruDF0QKTlUS0xWqwKg4Msg4WamFEQMnRw1h5ppT5QOFfbjXgig4/ox+P DkPO1EVopZR0YT1BSyKpyP8sZi8nAMEjiR/ptcTT9xQZf36+jbvk7hsZQ8XpU1CrUDjx9QMfLAEO SdbUN2XFF4nZU/FNGg1o7mnuuV3WAnV2VWn3Lz7n/IeNeEn5YVdsLxh5ocGMNxTZAvN6v5QpS4Fv D1z+tldEvEfXA/iVkSEIGFGF0IBemp7GeKTMSDDqGniOldiPXqXxZvX4lCamYPq63N8oEGeEE+SY jwvRyzyfvUzk4vS7FGZZI52HJSHUeUlIhYuQAlhkksOoA82xpKqGC5NHCovUwl498BrBSTU0ez5J JiI0nQfomUizSqO5NAA3V27j7GsnV7SZ8423Yd5TleqzvUJt9iCYKssuamkNKy8HiSB8R3A4yDhL YlIqje2KIEXZw04HG1l7gljSZ1B7sncoEnpDYcDskdOlaFmK06GI7G4HUek+lRD14vELkPElqaH1 QG+EZCInu8M4HSzpL47+7RWCglOqyBdVFH/QIllla7h2ebWEFGeUggxu36X9bxrooVIR1vPLxHyd fRkgfdklns/dPJ1U6VaU/OKeOns2KXIMppwCikiuiiYRqxhnDZc8BGNkEhvlkyzKU5QezsQiGrpr b3Ep+RXrpoUpjyCS+p7K0lojiFdKx4GTS1PxlTo26RQN55/s07/H4pg3Fv2XIgCLSqQ9RdwbUIbB FmNLHb5WY4txqHeYWnWIZsYA24T6KdTuimEUo9pxC1FxeTdyuxDmq7FjaNTChXgO84qePztdglre NEW91GhA8RvLmgcT+2sgGDmKun7Rhwu64yxT1KsNiCo+PEJhcwx2962oFDDmVWdGBspaWKCJbtLG i4PlIF0l6yqZB+v9me0kjZWxztZF8h2Dd1IS1ijkASia+zo+s+zWM2yCpYAhxyDBoBc9dg4ZkUOK iD0+Y0TsRWFRm5VCuLngMysm1GLIdjGTdCGd4i9rsLlg1VCQx3rxyCBPgYVHwOCzIfgF5rLhikPO rOnVLGoXwGmEB/7mnjghXtEGhZlWgFwGV0I7+6YU9md+6Etzih5voGBOjCS1q/q3lqP3Exlye6tP EJ+88uxyTlUd8coqp22p0AkIVDmzs0ZwgloMgXJou4IqVU7Lxasq5+mg6lX2ZOTUAdWl1RVRFeJW alAhXGXvmiLHCynVdvv14c+vgDMVUaqhdIGclSG3j7jS3NEabH70zKV4/SgDYUQ78PY3ZeeL+I1R +2GeK4/05o33qsMp1fhrtvlsbN1XnA9jTYtgdnHH39q4V4lirZB4qViksovcAl9CSUcNsHwAsxqw UL9jbZNLKmKVWgZjSYJxkuTdCTziV5ueHG2Wgv/2C/G1Y3OEBPomOE0HbP5CqBDB0O69JhqkWamg 2goe5nuECn/nyCc08/2hGJE5mAGqCKU+JVg8l1wLZgM8fuMJ/LLGLpVWKQMpmseR85Wiid/2VubM ONnzUnN2g5bs8aUE+Wy2FTXSUMmifxNNmOthKhrQBySN0Jf4t6xIJ5o1EcvT2e0CohFiniALhuKT jQxKtYzFqNwN/drrF6DhYhKruowtaBSaUqEMun0WY8cxAbDsxIgj+GMjOCRJWQYx+9fFfozZmAuN FCYeYEOWqEx2S58fqPZoef/hUdzdN4wG6tJh/5tooVk1+W8alLcNm9U8v2vIL6FV/e+lHVX7VTy9 Wx39FoF9F50XjFwUvG1dr3e3VXHTsIm/1EZu0dgyXeDgBhqRqe9reyC4TDgTRCjDkLgxYvcMq1oX /yHldCjL3+NjAi5KESsWRtmFDndcDAAVGe4ZNuuI45U/gtbEH6wbu8Dy90mIv3Zwl/3W1umFBUW5 YeCBT1wKIyIN6DUyDLnudxpieMi18T7kdLZo5mExdtr7ibyDQAo8Gz+uXksiKcekMp+Gx8hZS4Ep 4kcNZq38o62iGMsHms1Sc9BDAPrt3d0f/xeVE4zkCmVuZHN0cmVhbQplbmRvYmoKOTM2IDAgb2Jq Cjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NzE1Pj5zdHJlYW0KeAHdnMlyHMcRhu/9 FG2cGhHEcHqmZ4F9cEAmZcOidoR0MHSQIFILBS0zWsCXpV/F1V35f1nTVTMYUAofFIoQG9VZWZl/ LpW19PxUf1j/VE+H/zZf1YtFvZrP6sV0Vrf15nn9om/ppmnDW1f1dDKdBoqrm7rthp7hn6Hnurq6 rR9fXbWTaeh/9aJu3vvh5+fb0/rq20AX6J9e1bv948htGKFbT1ar9TyMv6rhUkUu39ztsJhOlosg hP7Xy72qV9N5PVtOpm0X2ttVlL4NYkzrnmAdCLp61olgUQ3qoXkQK0jR/xf+WU4D9drFiMr8p27a 0/psOpnVzVwPZ4vT6rP66t+m2npgsa7PA0aDJKt2UeBD9/o0KBL4/RD5Vc3Nz9YysX9FMdOIUz0g DK9Ea2+qZinavxo3SM/15pGP064mq7q5soZ/iOK7+FA1n6vlFz1sn+vp+9NaMCS6BzeatpP5qg1m mCyiTd66qhxpp532BBgexN83ad5J5BwQ+0pSpSJE49CyQWLToW54eHUaXK3XV0BPTquBsf8dTWN/ D9oNvt07Ve/bfxmcMrp0QaPlej1ZEBDHdlotizC0p1XU7fpURr40ZOQwag+WGMEAHl8Ks62I1dn8 r2704ouMi95sAfUbCWV8vffX6g3f39QiNhrZSKsGKUXxmhaMxkAogDAbqGszJA0gcoM4MIKIFtk/ ilE1bxvO9N1IwFuattJm7KVq36+lKBBkcyv+J3d3d3r+RviZ5kk0op5oaTjDinTXcKL9RTak0xZa C7G64R1Cgpb4WKfKaTUSfWBHS4+kssZOAiYtLJddEkQ2q4REfMg3xjbA9b6Wrmh4g6NKj4lZe/zv iQiU8hKHvcUbpTOOoV76F4OAgbw1kdLiF9cWVzFBfMY1AyUywR9L5S3id938ysuNzF9pTkrMvx1D S2DSH1fB2j9bOAJ1xmWMtf6+PjX3SNJudW/aXcySDHps2u3C7EOudjdjuvS0+zG2vUVpAUnD9/I0 WmRDbJc1QIpVr5uPYtQntmDqVX+6bS7NdZ8oVfxdDy79lxIMLSQ7huONRhAFBjTHrBK3Ec1xDhEn VvgpBHIRSLWe3V+Ylq43T9Y/FFE0gSXBRIvUQ1/pgFw/CCxiUyTqCykDvhIJA0r0irn1lnd5cMr3 A5tFNzmvmwv199k1i6h8dPnCB6ehFp4sh773ZNpZWq54COSyIrRLtlVWrJuteZ2r++4FpWQGDrx4 KDCtYOoYPJFvo/uG0PJsBlcNvMWmakG/+x1jnLxdRaISF0aYnyQoNEjs2TRWnvCHVH4mYfFVvcgd cPObvBYR3Djig0NDkzG0oapmrzDO1h0a/cWPAW6CY8Qa9uGVdJsWxTGl3z8PTEPlUFhQsPRSUqya S0spQgevAW69QT3eSM9IUTUvcxLAFhcasB5O6OyiS/BCfU/grxa8BqidSUy0f1SNZ0MnLnHL4Dj1 hkoJebIJn15INhb5eJOkgNsaCXwFEQ2HAI9YGeAe2m8GuJVwIKaqqm6oizAk0OF3khsEoVXqpw/s aCkZYDLy8DjAjucfnh0W52lVlc0Ola+rQ4Y15aUFamVvUIs30k99U+saW4wpGhrG1q2asVv9jnBy jyAhIv5DrRtj+1ekoWqCNda8N5pKC0EQF0Sw86kR4UXzneYNiLdMiSCLoQBd3QW1UThcsGPEQ8tw sTsBHEpWtHps3kzDBrF+lPOBG3xs+Kqhm8ait3RAXWSnEA19PFJKG1mLdXkjS7xheacWM3piSPxB EooUwfLMQCIIRov+ldOIDQqL/xgkr7Ool9iYRAFx8zJG081u9mPTLVmeumuJCzKhfGYnTy22V/fg SmKxDEUuRcGRlcRikZYfnvuoarHK5wohXB2rgJog93mFoM9m06rxZJ6bKMPnZH9GSaDfGxl1Hhky Dho+l4ZSA2vhbS8zVcUFE8fOVXNCJwATLUxyBDcnY4/DSQnTy9GER7piRATnQVKRQzytADW28iWm kMgNlAXiLawZFD19NyHDwjj7dIYSIEofSSMcN68ghuarsRFFDDtx8cUY2gFFoOnjr9q7Ab7oyhU4 rDSKJqXg7j6TIgtii5wGjFEKHFEzGpMZLSL5L2PxSojIhH8zfxoWDbYwR44UkuEIQXsU8DW/DB7P CHTi4fEx05q7fkzyEhQ/wrN4kJruYWqxsE62l4gTkYg/quiFuwZOHZqsAvelISCJkfrjlnrhmsVp 5I8Naq85chjwIzSRkMCRSBtxJyMGUi8IkjNEtrAX83LpfONw4RTCguEUGj4hs3aCJnaqmjPEz/iJ L16ywS7bibmd/xs1DH9LMT9rHZ7igWt33s+lB49cu/PznuToQ9fFdJ5Mzz7TctLJ4v1sefjYddGW qzAYyMLm13+ug9fFdBVwPPbotTtfUhI55pejGdSLr40cDjcTmHIzggMfxd1e7qFNql9xESVMxi+I TpKTRXKyHCW7ihvxQyzoDZUG7EhBGReJAqmYcBK4IatY5Zxsm3juVDfxy5Fj2vKcGhiOKnzEAGcx drN53gM38j+WlBxKBmKz/xAUGO+MSdUcKnPsIsKDK/du3XE+c+ShTrcKd1R276OEk8P3B79OzilR QLruAB3nIlywBHS0xb45v25O3gVezIND8Soin0zFm/4oYfdKxrPhzkLYzf9ke2LZOTkau/dGQrec gqEHegQkOeU7DhCb6UuARMwOAKIhbcI6qrAFqLSuGcNThSsdbw5P51d+Wrt59JfDdzy6eSl1Sj2q PmTHxRRnWZaofb89zxL51r74kDc0QjYkR5nmg4V9EJDFA7z84J0G2ImSo9PRfqcwgZPUnQ45NnR/ d2cwtMRxsOjGalwgoRbRp96iwJv1IoEx6rilyILbDdnh9Y36nTAPwEFjUCSzEKc/6UFs1AfzMmik qJon2vB6poenHyRnfsNy5JAs7NVG9fwkx69G5OIhhU6Yd9J5dcTlqG7WkZuPTeft7ED2YuVfmvAy GLm5BOJM/kWVjrnv1U09ux6p0nztGccT8oV5cDj2xB8fjaqxy9HfeBmXh7xvmPjHByP4E/0EkTwP o4eIjcEXQ7dqOOFGOEBUZzFjGLil1YwJxcYiRPsZ30JzxxP5DBPuFQO/FcX2FbJLZrJGLtcNaJFj YKTuOwk9xhSFoOcodUNT5UW9EDsQxIai8HJu6zfygABNt4/NU67s35An+txZhRpi7FSoByh7E2Uu F/boI1ELx/KlrvmqNGv+KC/1bTffZNv6xhDCoexkFAyXVh4LKupd4MYkGDLT9LWNU5gnUVVW0kAA qAbY28he6YjiBhJMBhc05RVZTisANBI/n5aZqODn12EluDH2wxq9SOzLDBHLOlHkoEYRwj6EZGFg NaArYoubKNDU+oYcCNq8S1DQVtFISI80ZOAY6bF5C3wPLVc8yjBGFLni3nAQfbc62Y9d0TiWBnPj ICBoIUMY854QW/pyyWcWOJKGsdVL3jEIIUFKlJXolVcWtjlQ+3Ve2MTeVXPdOA55ki0qO5QxYRco Vn1cb5c8GDmXXSRKsLAP92TMaVBvMxI1ORDB95QWEgUB0wyfrOEYQ05HQ+4kyC6Rfd4+nOFFDwru /XoVADc3YxRF3vXpo1H69MpB3S93KKoGLUDziITqUiV7sa4jgqVGuMfJF+MFfhUW+FLM74PdetnA KEwe0tG1Vsx7VkRNeZE6aSysiQ30JlJWTR5e4gXzjRff6k0viLhZKhHExmdNSkBxQTrYmcuG7Ipj HxOJkx0/qJtPlfoC1uZfGpOh9iMuUsQzWRx3L2xkE98Hz3qXRjShhFVOojd+ld/dVO/iSFWDnBgZ 3USamMmSC/iKhDKHyRB2Xu6I+FvlKOKLjBtIPqv47qjw/ck8fLeVb385kAxrWgRn0LAZttDqjShB dPdF4u8wBQmYHZra5dZswWaTPuaAsYQ6sEavmtdexUtmlMjNJ5YihUIHg57LcAbR+oxOSmMkoi0O kOCl3h6ZOIowkVB+KOnlQH9AE5Ydu9/GzafLwwc18+kqPaaJH2qFj+Gq4eO5nSo+fBs3D59z5Z7F IU0npz0LTZ7Bq+zbuHlbWv7uO6Kp02/j4spKQLC3NdXQCMMr0fLGvo2rmj/g27ha38Ylm/xuwOAZ goFTwXn4LrB0QFM6QZz3x2KFvY8LYuuJ9H6mh3wXCN8LvSJ8J3QjJOV9NAg2GMOGtMGRztM73zSC AWHBjJvF6weau3x5RJx5fBEG2fUPnybSyw6W+xlWmrjW6JSDhUh9PRHROiiSmIMOpvH5xLJA4iJg Q4LIYZNF5KUayVCsmrt8oZfzBXNGEh8klp56kR+UuS18Fun1lHPv5Ak8fXbeFr3X7YDS0pUGyYKl qDNQ8Xd4X7TrjqlH60nXGO+TSDvdjvCQSaydBqwecmgzW4UzdIL/yI3F2bI/AM5z9MdcuCYseMBF 0hIj7h9jjzS+hgKn8vvMAsbtitXy+MLriBNWYeJjgLHOHv99YPs8aBAtgk5okPk/YT2eXU/kjXw2 CDeJ+ETZ9oCmROfDkpyGKAHFZkdUcgzM+G8dFYaLWl4YJBc5ZvP+1kVykSN+Gt+7mr6dn837q1zJ RQ4qhEiyE/mhQpjN4z3LavB034Bg8u2E3FmYoJP8kdUIs24xePKY01FVQoxmQWmlQNW8QZVQl6oE m2Ee+apodyOIC6IkD9zQ63lzquFAWkB47uz6u0PH1gmzeV+XjZF628TD0fdX0u5sUSdfib2iN5IL Vp/g0A59eQiHBtFZt5TtOUeosyD1WioGpQuGOMSZ5LpWTZYcbWeMg/BmRYU/Qe56fS9n9QWaPh7y 7QbTK7loK0EuzQAX74nPxfBxX/jtAZH4WKRjZjrS8YafLIjW8e7sx2BAz12WpjXSLcqgqK99eQef m8IhgQEGcQbqaPBkq4w+UZyqObzAHWYfLOxOEHorVHYyj8dNe86U6dknkwuH1ZtJOZSTtT/IMHGp L8wonPBnoFYUuL3pBYowpjtjjq9WJ5emZN+Twl4X/UV0WfDIKtxqTTzSwWapChsiF3PuOmSyAYrx hJKv+VE4QWdUfr2wpCG5xYQcknUtadZ/SDtoZhmITsdoli02LNZKLuGrHwkMZBgV5wBESjLQBBmx kd700Qu4mU5DXrwnNMJSPy8MvdA1KapGCRETuumQlGwlgXBnSDh3yUjU4DuvDLXxTCsq093l0gvM uVGFVYd75BNPEcWip13t/FxQXvK0q52fC7qn4GlXyVZGvDuU/lxQp8x/FuqWxD5ZudOud8r2/ipF 4PPmxU6tYqfy3y66d0ukWOxY0fnIQ/LNi51hRu5h6D8eIGm36/LPBZW2RNrV6H6vIXWB38k91kBP sBCViivRmv8llwPd53F1RsDxsnhlAHbrNRJ9YEcLZdn+3zapmt1EG7bESAmIpaEIxUQaMyK1BZ0Q R1CIy/5Ua9NTUvDk3DIuE5t5Cv9qN7scrvP+G6xkjRLjMV2jtPN+zZusUe75ha+2C/sShVRYWKN0 hy+bt+G3y0qc9oXtn+uyeTus0EprlNLnke3cL355ZfYxboY/MxfgZ1mYUfJ74ifG8X5ajE/dX2CK lQA0cOZhbxjQR64tZvobTQhs8aKBOPHotYGTcwCIstBEBEgysfMAl3gI4V+AwA+EJLEtPcJ3WViD mokWr2XVLYdANEllqPJCnchSlEoHjnGGH4CydUimvDjjSmRWlEdllWy+oKSX2EhAIZhrJ4rciIFH enkuWQkJkWRxqgECOysRqvLqpp2Nz737IuHKUuszXZP4RHJFxuHmHgEDENnyDm/DHn4HGH+Tz0OT vIklvHTZD5bg5YAP7+MBU+TrWwZE3klAzc5DizNIuGp5cPpYnz9g7jifH5o4FpQcYS6RUMGUebU3 LR3R7ps2hgOw3S0/WZiS7mFbWxZBOlqAy//jxyHPV0fva63DFmBhOS+Hx8dwR1IIcY7n58fv9PKg EKyZF/tEY+kv2f9GDNyWFCk+e/maDMkR/MPW3/lXNcd9vxDuU3nhcuTZwrJ8nPMvOT3qE7VSm6kY yLMvkXmDCYUd8GJTvRH7UDebQ5NBmBse+cbOsKkEExIJpJFdsr7fr1AuLS0uXIxYnIsBs8k/mR0Q pnAb/TjLdv2Xl/k6/6ORlZLDSEmMpJtLA+2JOo1RRNtgraimmNxvLSwg832quTI3I/YU7TugmBuH VzLkU1okHXKr4VXAubAs7+aLyXTezsKNh4DleGMdLEGMLINUXIeU5DZflVZNsPGLI5KPVziG+H0h n+da/j/NasjAA51zyc0ayWVnhtw4NB/+Dz0dOocKZW5kc3RyZWFtCmVuZG9iago5MzcgMCBvYmoK PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDI1MDU+PnN0cmVhbQp4Ad1a244cNRB991c4 eaFHYoe2+zYDD0hBAYQQUqIRPBAewpINhGxCZoNIfpZvoWxXHbvd7tme2ZFQokjp2W5fylWnqo7L fqMf6Te69v/2z3XX6aGxuqutNnr/TF+5N22dvniw0/W6rqnF7lKb1vekh++5Ubtr/dluZ9Y19d9d 6eqH12+f3az07gW1o/YPd5r6mzAfPbrO0ISDzru9WynqQq3rdd8l/zkRBz3Ujbb9ujYtfTRDENTQ jLV2DTbUoNW2lQad8ivBIkcS9DW13uQC/Kwrs9IX9drqqpcfF2alftG773gVG7/0jd6SOrwkg+kK 4zTSXa9oITTe6/BCVZdv+c2an9LCSpdafkAYfJK2/EVFMT/n0dB0K6N8Gucxw3rQ1Y5ffCUtXoYf qnoqb/6WHzfP5NerlRY1JGsnxNRm3QyGzLDugk0e7FS0dWxbuwaZyUnjIs3vMhFmDItV1WP58nUu uKgDXX6Tpn/ID9E29L+XToU13rAW/UI9oh2+HKLveTTnQMbi+s1m3cENlnYa+kQj3Ik0cm+lLmxn bdB36lj08b7AJn/+Kitma2qxpqqgWln6bFsd2yaw8QBmHatKJn4uE8qLvMfts6jqGInuMwKLhlEj /46G6dupjkfWTMIaAlTs3tnErhLenr4inFGkKghSjHdxuJZ8IIeJt7g+yeIqxKrc4okVl+tXVbn9 4ENiYLiZvMh7sMVVdRaJCOwceguKnndFS66IOBNdkVPLDExM6opsZzIMQg+WfvmavNM7xPU1Xr4S V0D8Eb1fI6T+CXWi9XMZSlpLsILDYgZ0RviCivmTqq44PKKTDIsXEOYG4+EbBn5CgYOXCEkn69qj Hz4hnl5icO6vKsQKEemYlf4l2t1D95eY/iYuBdLOzgbByHS8xCcrEQnh6r28eSETY2k3Irc04dUr ye+6why3iwMzo8+NXikPLrElLZkJybVMKSKgN3RBLSRFz8C8pmiI+BNhjmUBIHuZRWb9gsH1ZBUn cTSNxBWuFmhaN7g8f5CodYNxTSJV87xBzVK1bugSl45igx9Fskb0x6lAhfAwIWvdhuI5gkMcaY6u aUfXgkXWrABRCIjWcrrmWCXD7n+ha92wpdUvJWxdXyLIO1ZDEX0E3Q+CrnVdDy+IGcKl9Nm00rUt cJNStZC4ww7hzlTNJW4GiMAMUQnxHj4KE+RpmAPCB0bVOtqCyvagZJSDRK2zNSzKbl2dTNO6Om5p p7Y+lpazQQ/Yb7mtPxaS1m77sq05cBf2j+0mOmAM3EWC5jOmqs5B0HgosZBkRbgeci9SOHgUDI5P V5xK0EmGxQv4dmQ1+IaBHUFjucAxwMJkyKMImiaClsWdY1aaEjQW7AwEjUc6D0FzBRheIcwB5c3y RZgZfYiguXpOJNvnJWjtYPMwRruQc9KzttkcJmdts51QM1fzInpGBG/EK6mK1rYNHDl6ZYGYEcOK 3FRNiFnb0c55XEWkhR+kZaGutmafEtyfSMsYbGegZUndJW4b4MSEOVEDqgJtOxRJWVIxjW0bosIF iNxGy5KtbFZFizUYCIlgAthLNMBuBMEoXSM72MlVtNY2CTs3alHprTVuMyHYmUnX6izUjEEiULsD NdNcRUt2xrK/yMncklkkKC1pe58ReExNpdnSxgGoO5qcNZshMRGFCeVKqifTs2a0HWSY3KGK5s2q qWbF+EUSRvg/3uLRq+BDYmC4mby4zeJJXf4kicYWX+ZVTT9yxWVV8KYjVwRMYjqYJ2n6EEmLOryl isYGFCtJsIKyUOyBLRC+SiQtJBaYSYblF4k1FpE0XVHMDxVDxFXx16NJ2uxKGboQerrSCUmj2gaa j6poPNYsK8LYsQA6T9JUtbyKhlOychWN5RJ7TMwMuZikaVREJyRNVZPe0AWNLyl6xHaQg5vGlVEk 49TBoe5G0whyXEVToYrW1K7kdbCK1tSuZp1X0fzxJFO15BiOqFpjygdwBbLWjlQwIWsNnSOW/HwR XQveJUZkuqaq46po7AcFusYgSWLq4UNP0DVdpVTGT6Cc6woWovmNO1IqVdFKhK2hU+vddc4/HiIm 0HlCHh2AxCxe4FgnqTb/I72/jJICSwFVAVC2J1o/OT0n7MrpuR3qg2BKFkdgskO+G1fkAQUodVEu 8qYJlOyGSF7G+9Uy3l8Ekp4ASVXYEgjopmIWgMRWyYCkcF6dn54fApLPARMg2WEzglG4sFCOObYv H1CVgZRngzkgJQF3DkiT+r5tXAl9CqXkIoZtHHnII9N8fd82GT90R+5lOFGl3+lxrr5v2/S4NzKQ g5Hpo6nv29ZthUqRKckEiGO2KW25y4BiZ+DIpKo7ACqmOqonKLrXY6gWeBBOZjtMwJSmuSwy1bS9 yCJKEpkGCZh0rwexvRiZ/P2gPHAfBFKISELrJdp8gCnO1mUYJZoGjMw27BRyTS0Bkp4F0ikpznSO l+VQohQXk5zp/eFkdvI4DyYzuj4SqR4yyGYpnIw/8wQwQRpPBxRSnYp5946pLkRCAu7pnAmpzoXo CJLeXcooRaYipCgqQFOhWkDZ4G6AQqpT1VyqG0Umd+PQ2FtuHBp7zI1DY0sHqoASLuzdduPQNMnu I+zMST1zQPq4bhwaOiQswcgxnrpxJ9Z0PXV6j8vY8t7nJ1froZuo/taGe9Jpv/+baJ9/ki/4p8OM ++5qCu4p/Wgb6f8m+u2enuNJZc1Xue7NX4ON3lGXryzhQLqUvrdlQgg4+S352I+5IKLiHRW3Ux63 +X5FV3PXva5+lPyFXI+dCjYoN6+kZvaJOxYxTn8hCUrnWLmRL5coy0gb+YKzb4wvLTBzbDpmJLpy FZ10JaqKK5GCNG4bviRr+Ws2mAn7MVQ94lRZ3SHu2GL9AxUH1A7lAo8MA+qE0pN8eY/KDKTJKcS3 BXlZqljDIcj6NYnSsCQMix8wKY6z8AZFFFpA0KesBL1j1QpTyFrk+hKWBH3s403i/QX0D8NC7Zj/ ksaSLVN5T7Qpc32EdwAN9b8o+URJkARrwnqlLYumKlh72hadoNDpm3UwlN/HSKxYcsl4SO8u5UX4 ufuv5bgHnlCMEvn2MXMtnbiW6EYOlWBZNnxywAGtRSTE6ABNCpIiDoBRvMJI6AXrSXeRa2qGfxGz ppaRXkAtJnhfQpUPIqqKqMpdcNoJI88ImvBeiIflQgF55xiIMD5WKWuSPvAKNJUv0rIwTSCG+ACJ oinzQeRvWEZGryVlvEOqQu1P2iTFrGRr1tLZZ90YS5XMSA9BpB9PYiSCEGSY3GpE2GFl+4pflhr2 E0XBMkCXCI4DOLpDGnT2DUdlyIAf6DyVHDNyG1Vhyn3ctT76D/I/+hwKZW5kc3RyZWFtCmVuZG9i ago5MzggMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDIzMDQ+PnN0cmVhbQp4 AeVaTY/cRBC9969ocvJI7OD2t+GAEpQgOERK8I1wgGU3JLAbMhO+/j3V7qrXbXfb41kioWwUKTsa 90d11atXr8vzVj/Tb3U+/ju81HWt27LQdV5oow9X+tp+U+XhF48Gne/znEYMl9pU40z6M87s1HCj PxsGs89p/nCts6dv3l0dd3p4TeNo/ONB03zj9qM/ddXt27YraddWT+eq7O9X40Sak++bOvjPGtrq Ni910exzU9FD0zpzDe2bazugowGVLioZUKvxPDjqxI4mp9HdzAL9vc7MTl/k+0JnvXy4KHbqBz18 y2fpRgd0uienjJa0pk6sU8p0vaOD0Hpv3Bcqu3zH3+z5r4woZEouH2AMHslYfqKyRsZ+zqthKA7w qd/HtPtWZwN/8ZXM/c19UNmP8s0f8uF4JZ9ud1rcEJydcJObfdkaCsO+djF5NKgAMYi9n5XbodPo 6+zV7burl1eHCXYsDmgtAYPDQdM0NH0VCU3T2iEeC6NhahELTWtii9JooMBaNyiH7AgNTdslV1rC g7Z4oCMSQt4DHjThQTn8/i94aNqaTn8+Ipqm+g94KPMTaChNhAWbxYQHQtScF5oywiYhAWmF5Lyg HJSEIMTHSKiIMafsSOus4sAxxZ7xILkeb32SFywORh5T2XvAgRZeUNlGXmjKPokCOiBXEuVrAnih KWzWzny2yAu0FvOCcrxQ9yVNX+WFuq/skBkvjIzOWAjsohpR9+lsRkgQiSkadIyGnDJjXi234sHh YoYHlQGKsAJ2yVg8WasTzBib6wTwoGM8qCxVJ5q8WOCFQBsAB3VPWuJGhbqCPCVV6xcpSKhMctjn 8uTJtMCpTEZgys8ylCSH40upylyndXaQSSHm2VVHzqox/0c7rQ6x+ucTkTATWvFHa3sA3KhtUxqv lHgX8gbtc1HUReEoyLnKrUcPH0gpmf/9SU7LFT+IJNzqjq2yLWMDyIwlDP6VjV+6DRWK23zGll0k EDxWZSvWP2BSPisotc/MVBxBWkmwViUi6kQwyahbwhdJ4IQRSVXs4UGVSviPLFGEqIVYO7idE+tA 3c1irc+MtZMryByJdRT8LbHmhLqTRdNYb8wmEyTgxpzN2wRxg2xw7EtQx80NvryVjGPG8Vx0A7H9 K1yJ0Zw3Gswl9ARHXYnQw2QQFtIDj66ZEGGWpBR/EWDjiEkYjIVfiBDQluUdb4JJhTcOmIdHYNBL LI75KydlbGA9TIZBv4sVB/j+EsOP/ii34qzF3bC2D92LnXgJJPWPHPK1bIyjHSVCMgmnh2nYIzg8 n1EmySIIM+YcZYjE0h/5RqyKZsMXNMJr1RSNVX2gvFBIcChg9SB7iDlfMLRe7PwWUGajRmN5VjWk wteu71VTrEqzwGySZlXTJLISAgjCh67v4dEjYVa1lr/nYmOTTP/gZVnVUsVKXN8DT6M0VbWTwnNP dZIJAggkC6A7hwznzCgVHYn4TEWCIkeAYSSU7IQNkN6yE+ZgOXxz+NLjYYrTsYvU6oquB5NrhOsj WWEgjaaqsNfctWtE4EGL1aKn8THKEmjl9sJSs6kqbe8jXukjwWtpb3hJxK5qtKoo5lyx4VrJeCi7 bsZb6pqw4NFQdv0ZWCj7QC+CaIEEfDh1oaxykpK+vcBS8e440HKdVL4HCmMk48Cqa9dJFgaf+jbG etsxuIT4aop8JR6Qfhu4qOzbNAoSTYWys7kaeyrcwJGQ129gGgzCN+IJLtBK+ro6+0uI8BTBlLVt Ns5LIUEhgFRt78vbCaasHS1wL34NVhTTQAlE5bBsbIrBXVjpIwFWYzvTSYJJQavydwkqpJyC3wE0 Uo0EM0A3ZKs8gbziqudvCd+wvHr4VOD1cEdvUWwbXyZ7wY1qh8pIAs7d1g4sXXUm+hGyFGpa7E2I T3eV82bhBF6F/olNkSzwhJgaPGHhK9bAA3ASbjFiliwSnVdl2BqC9YAFZTrG4OCQGEd/U3XewmQM geWxFXIEnFYMDASOv5XIfDELzsae8kRG0nLsrGR8nQr18cWCkT32FQNeZSW1T0nvsubENK11pglp 6cQrtrKY1CjbIKOOBaoKOIVqHeyivllMSoVvgfGLRloH08VRHNj79YqtLKokIQWNal8XjS0bIG+K nPP4wCQSQ8O5TmXPhV2e8FC8GxTnAk3IBCSUABb+B6Mgmf1rxDu3Tkv71hAyzlbLDf3Wogsb+Dxp bKmpqH0Kd53fPlUZXCv+wjUIPIYEx1hPOy6J2ce+W4qE33NY5jNO7+I5+/RY6hyzOkh0Lh8PKt3T LtpQfKQCsyrOi4buW4grp/fdW6jUFA+WCyMeN8y3RJypdyWK2yOusnn8kEMSYKSZfDGfwVFcbYJv t8hG3FFvMuLTl6PgmaIKX+D7iCvqec9/8eEnFWEqehoH9eDoJMTZ6yuNVK9/TjRSeSnxiZAVkhDb IhagLwSdHymIJ0ySZfEFstz3NPAMC9tGKtu1RWGAcsGnUSNVZeAKMemck4Z6jg3zkmXSSOXb3eJu 8CI1Unml5UaqzrY3UoOrFvaA8xbNQZgxhxqpTuSJbvMSlhupOlt2HTk3uD4lLgWFITac0xlVHChT AGRzK5XMnf4CxnTj9XCtmWq68WX47E338i9gTJd4954Wa3yDXPoFjBnfscciZEmu3a9fwJjeXu5T N8iUYDNdSiAP90Gumcb/ONBXCPtWdLFCmLqBeI0Ld1CmfPE4X6ppkmqzkrBFGM3LMHP6BybVTOV/ Z5UKyqpQM2XcRb3zm25T5CDJONaOY0dJsinWHFDUa3As6F+K4ulY3xeRZoLft05izcSdqF29zz/v 9qQ+YxVg9Rn7HqUYYkVcfkKf8VJutFopvajgkFGINx5JTYdZYgQ0GKBxSp+xXXi3FJ1L2jw6w6Nl faZFn/n72LLIwHFw0lCfsWGkz9j1d9ZnvJLVZ04SITvQLdyuz4KfOMN+gOI8feZuw9fSukTD7n3o s64C73iM31GcBT/7rMp6n5em0MEvePz6cQ4hoDgcyUEXBIEsfAbswp34Jm5zojABlLJeHNyvWWjA BnzA5OcCMmyJBMIYPDp4cfzsX0uVXOoKZW5kc3RyZWFtCmVuZG9iago5MzkgMCBvYmoKPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDI2OTM+PnN0cmVhbQp4AeVaTZMbtxG941fAPA2rtMx8 D5kcUnYsJ07lw7aYXLI5OOuVLNu7jkhZkf6sfksaA7zX4AAzS26Sg6NylZeaARrdjdfdDz14Zb+0 r2w5/nd4YbvODk1tu7K2lT3c2ufuSVvGDz7Z23JTljJif2Ordpwpf8aZW7O/s7/Y76tNKfP3z23x px9f3x7Xdv+djJPxT/dW5ld+PfnTtf2m6/peVh3s6VzzN1u8fbm2V+WmtoX8+Lvd/94JKDd9F/3P aT3YoWxs3W/KqpWX1eB1r0SJ0h5emG4rA1pbtxjQ+QG0+0SpvpTR24k6VtSp18Zr00CtK/kFvUTG dvTG1u7EQ6MmQ9Vl5ITpprBrMUSs+xHybl6HJ5vwFyNqjCjxo8KP8Eql8U2PIb8M0ihlhzdPdJ1q 2Ay22I8PTPEbjPgBP77Gj5/w43iLX/fqhsh2AVFZbZqhkm3YdGbE04mndWwpAzKeeiqCvctv6KNv sAtc/RsMgre+xQNO+hee/Fo1dUAyiiYPpL4XRM5DyQqU+n5wQyZgMrNg6ocqaxx3Q+HUeu2Mj5ME Tv2wzUqiADiAdgugxESB2OWAsoRnBKgQABcDyiaAMsWlgOqHTqyPIeWj+JO90YxCSPV9ezagAsYC oExxIaBGhI5pYMx9Lu243PfR2kjem8tYfVM+ALOmikHmw2ceZE0ufggxAZaPo6tqbZYyVt9KYj9N 4pL55gBmiv8gYyUAM8XjM9Z/BWDN7nx41S4JpJ7KZywCLMTPhQDDhmmyGnOXz1jdrhFNZoufy1jd rnVDJhlrLFauPkpNjiJIyl+3y+cZwqmL4LRYAPtSYnbKChYAZR8ElClmS2ACKLsIqLAXMyUwBZRd yFimyJXAvqxnMlbEgZixup3kjTsT8yfxlC/ItmBNY9lDsv8Km/FZKOahdisj4BTijsTqdZjDinGA 2LjMB1cdQ97P5TrH8ab0Tk0bdoyVyiA9Lk/plRGGjCre+Ehsrbu69qDzrvLy5OUKRW769x/wUEpm 6FZvtinOGRtBZiyu9C8WfuEXNCy70xnnrIKNCGNNsaD9KtCaSQFa9nCnkak1S6dENJ+EXXe0bbij nuxLQb8XfAkMMkpk2b8Kk1KHVCqaGKmeM3vtS+slex3xjMle2wv32hMpRg72Otn8c/Y6BNSjNDrd 6zOjqYoCkPxE9zpDoLpyyCRuJhuarcz87o4P7xFxIeNoLroj7fueruToEDeayJGe6KhbsH9OZsJi ePDV85DcqBZCKjyIsHHkJA6m4GtN/NSUmRR548B5fMUMekPhnL9gacAG5XEyFfonvHtg2r7h8KOa cg9nza5G2bp112t4iUnqHYz8DgvTtCN2CJNoPVXjGpHxwUZMghBuM+ccMQR7qSbfQatkNn0hI8Cd 8gfPdheROBYSGkWsHrAG1PlVgNb1WpfI0rO2Fxo/15lw5Kzt60VqFlEFoWZt32eiMkPM5FFkenKU bAeXv6dkY47n/3/RsnaQihV1JnCMdCydna205LWdsOKp84vP71/fvrg9nPS4ToHgGLa0qFrh3yc8 3Z/oXOUdSbiDQu1OuEs8fQKGeifj023MwEF2dhEOjWt7pJI+EEA07giVhcQyIuo6wcPLc/HQbLeT xGCeCxYUDc12dwEWml1EyJjJiASerKUBsIyEUriaNgACF3s8DizOa6ZgH4laIZvyDdVc6jB5IiZz 45blZec1i/Oaa7WRhza74REoaLYuaiexU5yPg861B09LxBQJnTtHnp8Xms5Hc+jFL6FBtmIpLzS9 iwzigZI+EDz0ri2dzQsZwty0yrGlwITI2QeisEBt3pOvkMKSRfkIMe4DiG/gkRAp4dQ+/OENRU0k 2MITKKMfG0gnQa1I6kB2+EDXQsT+BGqpi2+CpRjyWfg3iSAXjI4MgcpGh1taSvJF3qgkF2uwr89Z aHjT3xgKo/iCU+hS9d4BJDryF9WARBoGB+JFslTYFT0FHUnhuWF6SHh/Q9MhibqGNcd+kwfE9LjJ oZgLrf74F2Do2R6504bPA6T6VAez8Ff3OZIbpY5cQDS5EySm03tYgX09POCI4Hl1H2Qc6ChuzvGO DohOQqmoqdtSSUkEPfsdHPjnAO3gUVP8AW8+xQ8YMe9Z6snTGc9rVFcDL9GGY2g6lsQk6c5zO7kY gQcfbrQCZHlrc/ppNWWtzUWfVpv40yrrCRnBAP89xFOa00+rHxZPqU4/rfIAkwvC6afV4KmPmfUI WYL46Rdjfui1D0P4cNbqU1QARg4QxQcAJAVTDDH7vR9jiqdvb5iZKYDDGCIENGR/oQ0Bv36UsbXO /ABYrZ5MqtSRi72bamcKLovVxOpQh2lT6qxEJfeFP3Q8cipBONenkxHJVj9JsvDSN8wMtISvsCNg 01gpeNEUb5kO0smUS5/zCeRQY1RdvEiznhqurSZn53IJqbeZM7dr/3IfqDds5QPowp16iU2gfwL6 7CPQ5w8h2a0OCFGLiT6odDLNS2I6z0zDh43RV5nu+ux3l3qQgwCPqLkmfyZj1L1rVJDz+26x+PwZ ocew4A9ChK0zmPo/iC+ijnHyNXYWq25ClM/9XWEgZRETYoHfEdpERCX456ZNGeAKaPwWmlEaViaC ic80kzA6keRMAcFcOoMXLEHjIkcFcIL4zTkIz1caoVl2UDfuiBSdXlN+UDfjAXfh6/NpV6tuMudp wV+GIzxweq1bd26enMxF0uNPrz+nr89147qD555e69pdeZs2hPdCBOT6VkH0apFmwBBlemwJCS86 1b1byx0/d8HsyaT+fj75N090BHg4hUbCkjikLpyEMEEoRGkI0F8xVx1oAgUxszFTXDP0Ip4Sqvp0 tWjE9NjOZALNEL+muLuj+tQDo1INsSa35qDZgl/JMIir4gHlzS8Z5pgilz38xcVnELfkQZjAi3uJ MsmDdzSF1l2vT5ETfalnmwLaYEU9HuINN4ZypSnh0z2VkNkPkJKqz5THlZyQAxxegSRSMy7HjdWj GRHGraBOKY2CIfhLwWyuxHaMtxMixTArXTIqYKddValOErhyFPjr0fvFdUyzpaDayoespS9d1VYu 6Z6UAelzzt5oq7Z6ASRcJ84XAcnmbr/mLk1Wu9xFwMUS4AGxmWQm1p8S28u2NV8BeXzTAxOg4Bz6 0B3ctKEdfa4msLQtI8gCbNnQruRKUa4ARNe9dOzgPyadXOB2tI8Q4w9YGaLUFHpOeZMmFtUV85Dy rKQ8Cg2RoQwHo1X4dEd08lHzOzM3w/HqzfEK/TyrZ7qwYHStS8oWXJgg3MgnvKodv88tYtzdaJ+g XK7Rz6O8c1ejU7JNmGwBtocaIlUnNxIzkhaR7tP41K9h8Z8T2ak6d2jJYT0il4r18fZShuyMCZNF glhmBUyfeJQqajmZwAaO3x9IOPBIQyMaPTkPRpnZp/OPj0dWCm0aM+0jxwdVo3YIAc/0fwVFUrsg hvbwjIU3mIt/c2Rki8eXBiciVlu51Js+dvUKrEnDliarFeEu/yTxt3J8KBvpkEWXyrR+fAXRXINU gz2a5LJHlFKCYlSCYqZcwyhnTugqy3q4WGOL34ZaQyv5g6wp1Zyu4wKqjWayL/8NhML+UQplbmRz dHJlYW0KZW5kb2JqCjk0MCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMzY0 Mj4+c3RyZWFtCngBxZzZjtzGFYbv+RTU3IQDaFpNdrOX5CJQAiuQkdix04ARZHLhjCUv8khyt+Tl Zf0sOWTV/50ii72MHCAIkGl1VZ3lP2sdsv1D+Vn5Qznv/7f/umzbcr1oynbelHW5f1G+7L5ZztMv /rQr57P53Hbs7sp62Z+0P/3JTbG7L5/sdvVsbud3L8vqkzfvXhyuy913ts/2f7Qr7Xwd+Nmfdrmc LRYd03U5PFr8q6x+/va6vJnPmrJKP/y73H3cEZrPVm3yf53063I9X5TNajavl7ZYr3sditqEmZfd ho1tWJbNUhvaoCT6D4RbzW33JpWrMJVMroXEmuvDTX1dSi6jselR2ZRbQ6qXZF23KR2DptMPOuW1 KWJqvhG9u3fxm1n8qx2NdsC6vi4CRixpr8kUVlb68PtIja1brTzuV4rKztbr2bqsdnHrn7Xje334 Uh/e68PhhT69BoYi0d2caV7PFuvazDCLkA+Q9r3zbkPuCZLmGzGCo5T9XCvPxoJrxwsB9ZW24lVC G/z3OjSh4yGgWPT27p2986/O2R/1jj72cZRbbTaJcn6osOg4fmi9yg+Z7xivm6ZtmuB2irnooFdy m/Hf/0j13JpAG1Qvqkv2BrcpO7fpHRiziPHXgWFR6YvxiUu4iHrcW1QnpL+KHvggw6yWs5bU5Ybp 0lYwTJLxyF1u17ZJTGSZr7NC9eVr8zMjMCHIZCp0css0BmrLXiHrTFs8Ll5i8ZgniN+RxcsHWLxP FMPMLANnLnDO4kX12yQaWjzAdTYUm+lQdIt7jXLD1BaKuEmscBaKpB5UvyOR3N/z5WvFXsw/juE9 ALwiJbE7RpDHmJIV5iOxcZj0RaCw9HIcqQquKGdijQOH0AHCt240JCWvKoPsOccS+fQO4pw/oWl0 XehxGIHeCt092N+x/eCqvFYVOMoN2m6622uhRLr6RUp+J8aodpCFdAjtEQ0eifJRRx0SEczMmYO2 yJau8r2kyk6Dhe1IOpUpN59bNvQaTP5BLbx1Ly4S6A/RuW6vncmwTStCm9auuxw3btSsjHqj1q7r bsuJVq1w4a1Va9dtKnYoyWmTRbd1rllrN5bPJ+IcAlIXc55r14oqaddiU0YPJmoXtWvRSZKc+uHt WlGZ98kXyHLtems4XtqwtauuQS7Uf8Rq9Dz6gVR7hZsD2U8KG+0JZzwp4mXRp62ijo9AldCQQ968 VZizdPeKENhf28Wja3ITGPtiRnQTy4GgS5WHMlQPiPO7Tv26rCSNVPy0h6Wo/r6L+AinsGC3JWn4 9K/X5aJr/PLO6mdgMK8rerHJ8jEplZWnLnYjnaSRdDHBJIlfK9oJhuOFq789vba7WwflP/uLw6oT OAgFlgAkcp6qWRrcIMKlJfBy5BFCWU/kjmvIkfvIMukcYe1QgZDUhLK+gOAbuRdnTBqF0vTVpm1X nlTJTof3ogQqfCBWyLOHWXSc8d+rPwbPefilxG7giDXofIujV5LWJgTDK1p3KX4eRRNWMo+VjeAQ e9DzSKSUuRV0DvDZEyttURGdlCQdOtVxYCpi+Ethz9JY+Fti+EQZjnoVFZJCDxOOCevfkMUfgyqF zwIgloc5rsISqHnzo4Ak4+Y8HTYBKWvq3wrQohoJ6lkOstj58Dj6hKiQE4L6RWUyWSa2NDeLO8cn LuiuRAv+mYRYASizLQk4417zPDh3sIaT42W6J4nBchuzs/wm2TZ2NRxN0N69Kd+++fb1u/Lbd+Wb 9+9m1lt1AwPdIYftVT/kWpfLzep0c7XcrNPWquhHfUenYMut3UGHYqWNFeMla6xCAgqpI5uCLbeD aVpsFo61VUV1rq0qH9BWFRVinpuC9UX3dFuVFEtPRjiVuZlMTlu13E43VUkT63s3i8lWdheDBHeD Ywiwwq+iJ6Zgsf8kCxKuyknRiYuKy9WEjnEKFhSdmHEcrR7Lrq+nux6UnONTsGXbNaXywXjIfPCR ZfB8CvaAmUgEI6bNogLaLGXlKZa946QVzeJDL+6ax9IcifEoF2+Ezu8tq6vogZOGKaYblOVynWM8 GKSczF3Lhd2/sKvm/x88BVs2FgOQSy0+Nfc8b/GY1Y/i6532eXyL7OJADMnARKa+GPtI5JJ0pJRu /OohPngVU++kxYcPXTzP1N0VexRVXUwx9/QbNocW2zQUz0zBIuonpmCO+5kpWCQlTJSsAAvEsQXp C6PHpaLSHYJDIssXWMNHR6xBuJuCRbks54d7C3lVJL1/YIl8mk3BiopcofMP0ZSG0EZCUTBvBAdT sCjtUW6gaJ15pHR8ClZWF/RpUfuks4UH4B0VBzNzxprtcK+QLbMp2ERrigkNXJXo6Wy42Fg2JP+4 m3PlwEG4nclgx6ZgJq6eWIYp2KLt6vzJKdiib4/HU7DiaKu2aNPBtotNk0UXdGMDqA6CeM/LmrXF 6sw8TerS8zKPUM7TDkZdcwUJsy6WtJeVldzu/9KuLVbdM52pKdhUw7Zopxpk9WC47B7nCdXAazoZ CgdV1AuX/IJMrNOvwYh4GlPRv7GZyBNfYUfBvRcuMsOT2ITqb0YS2lEpuxfLIRAwU1NBrJ0Q2ZMS nsR4H4lqwy7Qk0x7kbtr5XE4Wvzg94E+DzykbC4W27Ro9k/7Hp1+9Ltoxu83dCOTfwCDHhj1I9lR HQm+4nVSujlEMqJMERGauKt7LQJWbIJz+qAG+Ui2utd6bhVzahoeMxbcxYsFBfIulqjhwezhA1U0 jlvcV0FEVGjlOKyVA1KyZLU4yvXrHcldMoMSPJCQqQ9LwUIe3clwYXjfyFEUP5w8iufE9siGBNgS XZCJzSnEoW7e+mUHyZFUOIEgAMAsbEluwimL8DrAMW16Zz5Tf+up6ussEAPBTvrv7fXjmD6kGaoC NVhJbG3F48D3ZSTGEbyfXDQmwlZ2xA9JQ/RhfgdlQyd6sCT3njrXYRyekIl+VVScEbkHYCb1j+ci +I0BSd+DYpPoEaT4LGEgKQlttsABZ1HjneRIYua28iyHxUX8cxWUZ7EO8oJUK/DHpab00ZO30Cjm Li0WSh+I3903zkSLvfame5w3fcLsG0mGNq6gmLoYpyNrnLqzGS+KYZfMjSYV7J9kTaflmDR/vZOw mBFXlapouP8RQbD+4Um0GR7CHpp484KQHkE/SOv1V6zIG/CcRDUCdhrVqKFTmgVJB73JJY1Gk4xq L5ytNevtxD3Hnudt69kmiUVSnKzgLSmm1rMeDASKbNFpdHUbYKh4PAlOrtwZ+hzXihjo33kGcl/X XojkSwdUkL5ei9HhZzyKr7yL0rmye96ePtzsHmlH90B1SXRZmX8cHTqcSmoxnLLgG8GSPFbXiohh RDIjTgwmfIDPbCBSWX0xbtvBesgvESQ3grbmmeyX+OSzj0+7LG/L6ump88NIsxk3BjO1TyfZZjXV xMtQSesOTNAGQWf3g3yBuAJvc53oFpgRkvIPuh3gZC+miEumJF8hCMd4yAJ7bArFBOOQHD+acngZ SSK6rj9CG0R+kooJ7dA0fhEdiPyKqGMGLBinCJh4aytEYKwdunIlUalRX9L5cExm9pYdnXK8QFn5 EDEQWQJKHP2bnXDWDnQ8hT2c73ErPEWEGD2nLM64vr3en/cXKIMx+cZtL66gpHqaGf7T3vDmrcde zwFxtOQbwSdu4d/J8xwkm95Z+mUoRaVvSqRLMpuFL+B6uuc8UsLbKUlOCBFrv/KJNYkMZaqFvfAT AvLEPW1YI5I0C6OYHbyuPY8h+PQTJamnsokEP+CoGBaP+17RSNrRqQvGxMKo1CS88F9/gDZI0Bdc cDUhgH7MjwtitGIL71RNW/FM3Cyn+nIoHfQmTJJxBJUkAl4tZAAlP48xgII/IP7ewkwy+vy5/xSG 0M18e2QE3b+ruSkbewg0HkD3v2/pf1IzmJ7ba5iN/RYozxQLecRaDnXuJcymmRqpxjG2eyroUMZm o/6D29hcrBkxxyWnxgpTck09oTL6xUzfdqTvChQVF0KiFHsTIX5TsCCUeXjE1tSbweg5vJ4xQNr3 ztPfh/jdTyEsryHGQUwrpAFW5HragdhshZr7GbGJtuPdJ65QNDwaFfeYPGQoW2/Tt5bjryYGT68n nmXW3Zu+E+76lMT1lRw3S8Z8AWzoCwJ4QEAyKSBAChlYAimn2QMHUhk15uZG1oI7FPkAIVk4fpGM oGABGcQQAx1GcS3EHHyq6mZF/3kMV/39XFEawyh/1i72ear2zCiJUMKWRh0iimZqXIEXplDPEukl ryCCjsQSa86eatdUvl3yyVY5XlpEmsvA2IuSMgJ7BMT4aM6ew5VIAxi/k/glr6ycc7HtvNLYdJ6q uzf+J+YMuVQSRYDmdg47Cl45/WgXneiZSzFZ6+r+ner8gav9xkG/D60X3Vswl9e7epm+QzHn1xI8 cPWKZzUkwSh74FovB49uc0oCBoe9uOYVFZWNQiZqrFxU80J3YWfTmld+WM3rnjxTx+pl97h56oGr fdm3G/bHdy8GXUb82aNyiFQjjkFMK4QAK/I2RSShxVaoufufr3neW4gB7oznf3jNaxoi6sJhX20o 5u2Z6l2SP5BOcvMFkIEMSYNcIxSPZqrSHy4AJ6dhFTkkc8DfXO9iFbhMieFTLM4EL+rfXg7jPGwK EkLt0nqXtI2PRw2sSMEEwAbpt7+qUp/yJaw1UsNeFsw92+tdxItwwEgSSyGFVMfrnQeDi/eh9S7K lYuOgGMvKv3V9azeJcO7/1G922b/LQR74J+LJPSEZm5kOdvz6BZpsavtF/Xdq/MTZaV7HXO+qJty Mb5Hdf/lAbosrMYAG/fgkYhkJJg5RJPAN/mYjCVMJXrMLPgt5V+ijsjABw7nkhNz7KHX2zs0n/0X xcfaTQplbmRzdHJlYW0KZW5kb2JqCjYzMSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9H UkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNjMyIDAgb2JqCjw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0V4dEdTdGF0ZSA5IDAgUgovRm9udCAxMCAwIFIvWE9iamVjdDw8L0dSRm9ybTAgODk5 IDAgUj4+Pj4KZW5kb2JqCjYzOSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0w IERvClEKCmVuZHN0cmVhbQplbmRvYmoKNjQwIDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAyNCAwIFIKL0ZvbnQgMjUgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkwMCAwIFI+ Pj4+CmVuZG9iago2NDcgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpR CgplbmRzdHJlYW0KZW5kb2JqCjY0OCAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgMjkgMCBSCi9Gb250IDMwIDAgUi9YT2JqZWN0PDwvR1JGb3JtMCA5MDEgMCBSPj4+Pgpl bmRvYmoKNjUyIDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5k c3RyZWFtCmVuZG9iago2NTMgMCBvYmoKPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDM0IDAgUgovRm9udCAzNSAwIFIvWE9iamVjdDw8L0dSRm9ybTAgOTAyIDAgUj4+Pj4KZW5kb2Jq CjY2MSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVh bQplbmRvYmoKNjYyIDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzOSAw IFIKL0ZvbnQgNDAgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkwMyAwIFI+Pj4+CmVuZG9iago2NzMg MCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5k b2JqCjY3NCAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDQgMCBSCi9G b250IDQ1IDAgUi9YT2JqZWN0PDwvR1JGb3JtMCA5MDQgMCBSPj4+PgplbmRvYmoKNjgxIDAgb2Jq Cjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3RyZWFtCmVuZG9iago2 ODIgMCBvYmoKPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ5IDAgUgovRm9udCA1 MCAwIFIvWE9iamVjdDw8L0dSRm9ybTAgOTA1IDAgUj4+Pj4KZW5kb2JqCjY4OCAwIG9iago8PC9M ZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNjg5IDAg b2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1NCAwIFIKL0ZvbnQgNTUgMCBS L1hPYmplY3Q8PC9HUkZvcm0wIDkwNiAwIFI+Pj4+CmVuZG9iago2OTIgMCBvYmoKPDwvTGVuZ3Ro IDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjY5MyAwIG9iago8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNTkgMCBSCi9Gb250IDYwIDAgUi9YT2Jq ZWN0PDwvR1JGb3JtMCA5MDcgMCBSPj4+PgplbmRvYmoKNzAwIDAgb2JqCjw8L0xlbmd0aCAxNj4+ c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3RyZWFtCmVuZG9iago3MDEgMCBvYmoKPDwvUHJv Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDY5IDAgUgovRm9udCA3MCAwIFIvWE9iamVjdDw8 L0dSRm9ybTAgOTA4IDAgUj4+Pj4KZW5kb2JqCjcwNiAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVh bQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNzA3IDAgb2JqCjw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA3NCAwIFIKL0ZvbnQgNzUgMCBSL1hPYmplY3Q8PC9HUkZv cm0wIDkwOSAwIFI+Pj4+CmVuZG9iago3MDkgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQov R1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjcxMCAwIG9iago8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgNzkgMCBSCi9Gb250IDgwIDAgUi9YT2JqZWN0PDwvR1JGb3JtMCA5 MTAgMCBSPj4+PgplbmRvYmoKNzE3IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9y bTAgRG8KUQoKZW5kc3RyZWFtCmVuZG9iago3MTggMCBvYmoKPDwvUHJvY1NldFsvUERGIC9UZXh0 XQovRXh0R1N0YXRlIDg0IDAgUgovRm9udCA4NSAwIFIvWE9iamVjdDw8L0dSRm9ybTAgOTExIDAg Uj4+Pj4KZW5kb2JqCjcyMCAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERv ClEKCmVuZHN0cmVhbQplbmRvYmoKNzIxIDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4 dEdTdGF0ZSA4OSAwIFIKL0ZvbnQgOTAgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkxMiAwIFI+Pj4+ CmVuZG9iago3MjMgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgpl bmRzdHJlYW0KZW5kb2JqCjcyNCAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgOTQgMCBSCi9Gb250IDk1IDAgUi9YT2JqZWN0PDwvR1JGb3JtMCA5MTMgMCBSPj4+PgplbmRv YmoKNzI4IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3Ry ZWFtCmVuZG9iago3MjkgMCBvYmoKPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk5 IDAgUgovRm9udCAxMDAgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkxNCAwIFI+Pj4+CmVuZG9iago3 MzEgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0K ZW5kb2JqCjczMiAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTA0IDAg UgovRm9udCAxMDUgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkxNSAwIFI+Pj4+CmVuZG9iago3MzYg MCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5k b2JqCjczNyAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTA5IDAgUgov Rm9udCAxMTAgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkxNiAwIFI+Pj4+CmVuZG9iago3NDAgMCBv YmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2Jq Cjc0MSAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE0IDAgUgovRm9u dCAxMTUgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkxNyAwIFI+Pj4+CmVuZG9iago3NDYgMCBvYmoK PDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc0 NyAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE5IDAgUgovRm9udCAx MjAgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkxOCAwIFI+Pj4+CmVuZG9iago3NDkgMCBvYmoKPDwv TGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc1MCAw IG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTI0IDAgUgovRm9udCAxMjUg MCBSL1hPYmplY3Q8PC9HUkZvcm0wIDkxOSAwIFI+Pj4+CmVuZG9iago3NTQgMCBvYmoKPDwvTGVu Z3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc1NSAwIG9i ago8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTI5IDAgUgovRm9udCAxMzAgMCBS L1hPYmplY3Q8PC9HUkZvcm0wIDkyMCAwIFI+Pj4+CmVuZG9iago3NTggMCBvYmoKPDwvTGVuZ3Ro IDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc1OSAwIG9iago8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTM0IDAgUgovRm9udCAxMzUgMCBSL1hP YmplY3Q8PC9HUkZvcm0wIDkyMSAwIFI+Pj4+CmVuZG9iago3NjMgMCBvYmoKPDwvTGVuZ3RoIDE2 Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc2NCAwIG9iago8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTM5IDAgUgovRm9udCAxNDAgMCBSL1hPYmpl Y3Q8PC9HUkZvcm0wIDkyMiAwIFI+Pj4+CmVuZG9iago3NjYgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5z dHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc2NyAwIG9iago8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQ0IDAgUgovRm9udCAxNDUgMCBSL1hPYmplY3Q8 PC9HUkZvcm0wIDkyMyAwIFI+Pj4+CmVuZG9iago3NjkgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJl YW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc3MCAwIG9iago8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTU0IDAgUgovRm9udCAxNTUgMCBSL1hPYmplY3Q8PC9H UkZvcm0wIDkyNCAwIFI+Pj4+CmVuZG9iago3NzIgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0K cQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc3MyAwIG9iago8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTY5IDAgUgovRm9udCAxNzAgMCBSL1hPYmplY3Q8PC9HUkZv cm0wIDkyNSAwIFI+Pj4+CmVuZG9iago3NzYgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQov R1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc3NyAwIG9iago8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgMTg0IDAgUgovRm9udCAxODUgMCBSL1hPYmplY3Q8PC9HUkZvcm0w IDkyNiAwIFI+Pj4+CmVuZG9iago3ODAgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JG b3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjc4MSAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTg5IDAgUgovRm9udCAxOTAgMCBSL1hPYmplY3Q8PC9HUkZvcm0wIDky NyAwIFI+Pj4+CmVuZG9iago3ODIgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzIDAgUi9NZWRp YUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzc4MyAwIFIgNzg0IDAgUiA3ODUgMCBSIDc4NiAwIFIg Nzg3IDAgUiA3ODggMCBSIDc4OSAwIFIgNzkwIDAgUiA3OTEgMCBSIDc5MiAwIFIgNzkzIDAgUl0v UmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFIvVFQxLjEgODkzIDAgUj4+Pj4vQ29udGVu dHMgOTI4IDAgUj4+CmVuZG9iago3OTQgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzIDAgUi9N ZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzc5NSAwIFIgNzk2IDAgUiA3OTcgMCBSIDc5OCAw IFIgNzk5IDAgUiA4MDAgMCBSIDgwMSAwIFIgODAyIDAgUl0vUmVzb3VyY2VzPDwvRm9udDw8L1RU MS4wIDg5MCAwIFIvVFQxLjEgODkzIDAgUj4+Pj4vQ29udGVudHMgOTI5IDAgUj4+CmVuZG9iago4 MDMgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzIDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0v QW5ub3RzWzgwNCAwIFIgODA1IDAgUiA4MDYgMCBSIDgwNyAwIFIgODA4IDAgUiA4MDkgMCBSXS9S ZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUi9UVDEuMSA4OTMgMCBSPj4+Pi9Db250ZW50 cyA5MzAgMCBSPj4KZW5kb2JqCjgxMCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDMgMCBSL01l ZGlhQm94WzAgMCA2MTIgNzkyXS9Bbm5vdHNbODExIDAgUiA4MTIgMCBSIDgxMyAwIFIgODE0IDAg UiA4MTUgMCBSIDgxNiAwIFIgODE3IDAgUl0vUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDg5MCAw IFIvVFQxLjEgODkzIDAgUj4+Pj4vQ29udGVudHMgOTMxIDAgUj4+CmVuZG9iago4MTggMCBvYmoK PDwvVHlwZS9QYWdlL1BhcmVudCAzIDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzgx OSAwIFIgODIwIDAgUiA4MjEgMCBSXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUi9U VDEuMSA4OTMgMCBSPj4+Pi9Db250ZW50cyA5MzIgMCBSPj4KZW5kb2JqCjgyMiAwIG9iago8PC9U eXBlL1BhZ2UvUGFyZW50IDMgMCBSL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Bbm5vdHNbODIzIDAg UiA4MjQgMCBSIDgyNSAwIFIgODI2IDAgUiA4MjcgMCBSIDgyOCAwIFIgODI5IDAgUl0vUmVzb3Vy Y2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFIvVFQxLjEgODkzIDAgUj4+Pj4vQ29udGVudHMgOTMz IDAgUj4+CmVuZG9iago4MzAgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzIDAgUi9NZWRpYUJv eFswIDAgNjEyIDc5Ml0vQW5ub3RzWzgzMSAwIFIgODMyIDAgUiA4MzMgMCBSIDgzNCAwIFJdL1Jl c291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4OTAgMCBSL1RUMS4xIDg5MyAwIFI+Pj4+L0NvbnRlbnRz IDkzNCAwIFI+PgplbmRvYmoKODM1IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMyAwIFIvTWVk aWFCb3hbMCAwIDYxMiA3OTJdL0Fubm90c1s4MzYgMCBSIDgzNyAwIFIgODM4IDAgUiA4MzkgMCBS IDg0MCAwIFJdL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4OTAgMCBSL1RUMS4xIDg5MyAwIFI+ Pj4+L0NvbnRlbnRzIDkzNSAwIFI+PgplbmRvYmoKODQxIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJl bnQgMyAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Fubm90c1s4NDIgMCBSIDg0MyAwIFIgODQ0 IDAgUiA4NDUgMCBSIDg0NiAwIFIgODQ3IDAgUiA4NDggMCBSXS9SZXNvdXJjZXM8PC9Gb250PDwv VFQxLjAgODkwIDAgUi9UVDEuMSA4OTMgMCBSPj4+Pi9Db250ZW50cyA5MzYgMCBSPj4KZW5kb2Jq Cjg0OSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDMgMCBSL01lZGlhQm94WzAgMCA2MTIgNzky XS9Bbm5vdHNbODUwIDAgUiA4NTEgMCBSIDg1MiAwIFIgODUzIDAgUiA4NTQgMCBSIDg1NSAwIFIg ODU2IDAgUiA4NTcgMCBSIDg1OCAwIFJdL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4OTAgMCBS L1RUMS4xIDg5MyAwIFI+Pj4+L0NvbnRlbnRzIDkzNyAwIFI+PgplbmRvYmoKODU5IDAgb2JqCjw8 L1R5cGUvUGFnZS9QYXJlbnQgMyAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Fubm90c1s4NjAg MCBSIDg2MSAwIFIgODYyIDAgUiA4NjMgMCBSIDg2NCAwIFIgODY1IDAgUiA4NjYgMCBSIDg2NyAw IFIgODY4IDAgUiA4NjkgMCBSXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgODkwIDAgUi9UVDEu MSA4OTMgMCBSPj4+Pi9Db250ZW50cyA5MzggMCBSPj4KZW5kb2JqCjg3MCAwIG9iago8PC9UeXBl L1BhZ2UvUGFyZW50IDMgMCBSL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Bbm5vdHNbODcxIDAgUiA4 NzIgMCBSIDg3MyAwIFIgODc0IDAgUiA4NzUgMCBSIDg3NiAwIFIgODc3IDAgUiA4NzggMCBSIDg3 OSAwIFIgODgwIDAgUiA4ODEgMCBSIDg4MiAwIFJdL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA4 OTAgMCBSL1RUMS4xIDg5MyAwIFI+Pj4+L0NvbnRlbnRzIDkzOSAwIFI+PgplbmRvYmoKODgzIDAg b2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMyAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Fubm90 c1s4ODQgMCBSIDg4NSAwIFIgODg2IDAgUiA4ODcgMCBSIDg4OCAwIFIgODg5IDAgUl0vUmVzb3Vy Y2VzPDwvRm9udDw8L1RUMS4wIDg5MCAwIFIvVFQxLjEgODkzIDAgUj4+Pj4vQ29udGVudHMgOTQw IDAgUj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcy9LaWRzWwo0IDAgUgoxMSAwIFIK MTYgMCBSCjIxIDAgUgoyNiAwIFIKMzEgMCBSCjM2IDAgUgo0MSAwIFIKNDYgMCBSCjUxIDAgUgo1 NiAwIFIKNjEgMCBSCjY2IDAgUgo3MSAwIFIKNzYgMCBSCjgxIDAgUgo4NiAwIFIKOTEgMCBSCjk2 IDAgUgoxMDEgMCBSCjEwNiAwIFIKMTExIDAgUgoxMTYgMCBSCjEyMSAwIFIKMTI2IDAgUgoxMzEg MCBSCjEzNiAwIFIKMTQxIDAgUgoxNDYgMCBSCjE1MSAwIFIKMTU2IDAgUgoxNjEgMCBSCjE2NiAw IFIKMTcxIDAgUgoxNzYgMCBSCjE4MSAwIFIKMTg2IDAgUgoxOTEgMCBSCjE5NiAwIFIKMjAxIDAg UgoyMDYgMCBSCjIxMSAwIFIKMjE2IDAgUgoyMjEgMCBSCjIyNiAwIFIKMjMxIDAgUiA3ODIgMCBS IDc5NCAwIFIgODAzIDAgUiA4MTAgMCBSIDgxOCAwIFIgODIyIDAgUiA4MzAgMCBSIDgzNSAwIFIg ODQxIDAgUiA4NDkgMCBSIDg1OSAwIFIgODcwIDAgUiA4ODMgMCBSXS9Db3VudCA1OSA+PgplbmRv YmoKeHJlZgowIDEKMDAwMDAwMDAwMCA2NTUzNSBmIAoyIDMKMDAwMDE4OTgxMCAwMDAwMCBuIAow MDAwMzM5MzkyIDAwMDAwIG4gCjAwMDAxOTAyMjggMDAwMDAgbiAKMjEgMQowMDAwMTkwNDEzIDAw MDAwIG4gCjI2IDEKMDAwMDE5MDYzMiAwMDAwMCBuIAozMSAxCjAwMDAxOTA4NTEgMDAwMDAgbiAK MzYgMQowMDAwMTkxMDQ2IDAwMDAwIG4gCjQxIDEKMDAwMDE5MTI3MyAwMDAwMCBuIAo0NiAxCjAw MDAxOTE1MjQgMDAwMDAgbiAKNTEgMQowMDAwMTkxNzQzIDAwMDAwIG4gCjU2IDEKMDAwMDE5MTk1 NCAwMDAwMCBuIAo2NiAxCjAwMDAxOTIxNDEgMDAwMDAgbiAKNzEgMQowMDAwMTkyMzYwIDAwMDAw IG4gCjc2IDEKMDAwMDE5MjU2MyAwMDAwMCBuIAo4MSAxCjAwMDAxOTI3NDIgMDAwMDAgbiAKODYg MQowMDAwMTkyOTYxIDAwMDAwIG4gCjkxIDEKMDAwMDE5MzE0MCAwMDAwMCBuIAo5NiAxCjAwMDAx OTMzMTkgMDAwMDAgbiAKMTAxIDEKMDAwMDE5MzUxNCAwMDAwMCBuIAoxMDYgMQowMDAwMTkzNjk1 IDAwMDAwIG4gCjExMSAxCjAwMDAxOTM4OTIgMDAwMDAgbiAKMTE2IDEKMDAwMDE5NDA4MSAwMDAw MCBuIAoxMjEgMQowMDAwMTk0Mjg2IDAwMDAwIG4gCjEyNiAxCjAwMDAxOTQ0NjcgMDAwMDAgbiAK MTMxIDEKMDAwMDE5NDY2NCAwMDAwMCBuIAoxMzYgMQowMDAwMTk0ODUzIDAwMDAwIG4gCjE0MSAx CjAwMDAxOTUwNTAgMDAwMDAgbiAKMTUxIDEKMDAwMDE5NTIzMSAwMDAwMCBuIAoxNjYgMQowMDAw MTk1NDEyIDAwMDAwIG4gCjE4MSAxCjAwMDAxOTU1OTMgMDAwMDAgbiAKMTg2IDEKMDAwMDE5NTc4 MiAwMDAwMCBuIAoyMzggMQowMDAwMTg5OTg3IDAwMDAwIG4gCjI0MCAxCjAwMDAxOTAzNzggMDAw MDAgbiAKMjUxIDEKMDAwMDE5MDU2NSAwMDAwMCBuIAoyNzYgMQowMDAwMTkwNzg0IDAwMDAwIG4g CjMwMCAxCjAwMDAxOTEwMDMgMDAwMDAgbiAKMzE3IDEKMDAwMDE5MTE5OCAwMDAwMCBuIAozNDkg MQowMDAwMTkxNDI1IDAwMDAwIG4gCjM5MSAxCjAwMDAxOTE2NzYgMDAwMDAgbiAKNDE2IDEKMDAw MDE5MTg5NSAwMDAwMCBuIAo0MzQgMQowMDAwMTkyMTA2IDAwMDAwIG4gCjQ0MiAxCjAwMDAxOTIy OTMgMDAwMDAgbiAKNDYyIDEKMDAwMDE5MjUxMiAwMDAwMCBuIAo0ODAgMQowMDAwMTkyNzE1IDAw MDAwIG4gCjQ4NCAxCjAwMDAxOTI4OTQgMDAwMDAgbiAKNTA4IDEKMDAwMDE5MzExMyAwMDAwMCBu IAo1MTAgMQowMDAwMTkzMjkyIDAwMDAwIG4gCjUxNSAxCjAwMDAxOTM0NzEgMDAwMDAgbiAKNTI2 IDEKMDAwMDE5MzY2OCAwMDAwMCBuIAo1MzAgMQowMDAwMTkzODQ5IDAwMDAwIG4gCjUzOCAxCjAw MDAxOTQwNDYgMDAwMDAgbiAKNTQ3IDEKMDAwMDE5NDIzNSAwMDAwMCBuIAo1NjMgMQowMDAwMTk0 NDQwIDAwMDAwIG4gCjU2OCAxCjAwMDAxOTQ2MjEgMDAwMDAgbiAKNTgwIDEKMDAwMDE5NDgxOCAw MDAwMCBuIAo1ODkgMQowMDAwMTk1MDA3IDAwMDAwIG4gCjYwMSAxCjAwMDAxOTUyMDQgMDAwMDAg biAKNjA2IDEKMDAwMDE5NTM4NSAwMDAwMCBuIAo2MTAgMQowMDAwMTk1NTY2IDAwMDAwIG4gCjYx NSAxCjAwMDAxOTU3NDcgMDAwMDAgbiAKNjIyIDEKMDAwMDE5NTkzNiAwMDAwMCBuIAo2MjcgMzE0 CjAwMDAxOTAxMjggMDAwMDAgbiAKMDAwMDE5MDE3OCAwMDAwMCBuIAowMDAwMTk2MTAwIDAwMDAw IG4gCjAwMDAxOTYzNjAgMDAwMDAgbiAKMDAwMDMzMTkzMyAwMDAwMCBuIAowMDAwMzMxOTk4IDAw MDAwIG4gCjAwMDAxOTY2MjEgMDAwMDAgbiAKMDAwMDE5Njg4NCAwMDAwMCBuIAowMDAwMTk3MTUw IDAwMDAwIG4gCjAwMDAxOTc0MTQgMDAwMDAgbiAKMDAwMDE5NzY3NyAwMDAwMCBuIAowMDAwMTk3 OTQzIDAwMDAwIG4gCjAwMDAzMzIwOTggMDAwMDAgbiAKMDAwMDMzMjE2MyAwMDAwMCBuIAowMDAw MTk4MjA5IDAwMDAwIG4gCjAwMDAxOTg0NzUgMDAwMDAgbiAKMDAwMDE5ODc0MSAwMDAwMCBuIAow MDAwMTk5MDA1IDAwMDAwIG4gCjAwMDAxOTkyNjYgMDAwMDAgbiAKMDAwMDE5OTUyOSAwMDAwMCBu IAowMDAwMzMyMjY0IDAwMDAwIG4gCjAwMDAzMzIzMjkgMDAwMDAgbiAKMDAwMDE5OTc5MyAwMDAw MCBuIAowMDAwMjAwMDU0IDAwMDAwIG4gCjAwMDAyMDAzMTcgMDAwMDAgbiAKMDAwMDMzMjQzMCAw MDAwMCBuIAowMDAwMzMyNDk1IDAwMDAwIG4gCjAwMDAyMDA1ODMgMDAwMDAgbiAKMDAwMDIwMDg0 OSAwMDAwMCBuIAowMDAwMjAxMTE1IDAwMDAwIG4gCjAwMDAyMDEzNzkgMDAwMDAgbiAKMDAwMDIw MTY0MCAwMDAwMCBuIAowMDAwMjAxOTAxIDAwMDAwIG4gCjAwMDAyMDIxNjQgMDAwMDAgbiAKMDAw MDMzMjU5NiAwMDAwMCBuIAowMDAwMzMyNjYxIDAwMDAwIG4gCjAwMDAyMDI0MzAgMDAwMDAgbiAK MDAwMDIwMjY5NCAwMDAwMCBuIAowMDAwMjAyOTU3IDAwMDAwIG4gCjAwMDAyMDMyMjEgMDAwMDAg biAKMDAwMDIwMzQ4MiAwMDAwMCBuIAowMDAwMjAzNzQzIDAwMDAwIG4gCjAwMDAyMDQwMDQgMDAw MDAgbiAKMDAwMDIwNDI2NyAwMDAwMCBuIAowMDAwMjA0NTMxIDAwMDAwIG4gCjAwMDAyMDQ3OTIg MDAwMDAgbiAKMDAwMDMzMjc2MiAwMDAwMCBuIAowMDAwMzMyODI3IDAwMDAwIG4gCjAwMDAyMDUw NTUgMDAwMDAgbiAKMDAwMDIwNTMxOSAwMDAwMCBuIAowMDAwMjA1NTgyIDAwMDAwIG4gCjAwMDAy MDU4NDggMDAwMDAgbiAKMDAwMDIwNjExNCAwMDAwMCBuIAowMDAwMjA2Mzc4IDAwMDAwIG4gCjAw MDAzMzI5MjggMDAwMDAgbiAKMDAwMDMzMjk5MyAwMDAwMCBuIAowMDAwMjA2NjM5IDAwMDAwIG4g CjAwMDAyMDY5MDIgMDAwMDAgbiAKMDAwMDIwNzE2OCAwMDAwMCBuIAowMDAwMjA3NDMyIDAwMDAw IG4gCjAwMDAyMDc2OTMgMDAwMDAgbiAKMDAwMDMzMzA5NCAwMDAwMCBuIAowMDAwMzMzMTU5IDAw MDAwIG4gCjAwMDAyMDc5NTQgMDAwMDAgbiAKMDAwMDIwODIxNyAwMDAwMCBuIAowMDAwMzMzMjYw IDAwMDAwIG4gCjAwMDAzMzMzMjUgMDAwMDAgbiAKMDAwMDIwODQ4MSAwMDAwMCBuIAowMDAwMjA4 NzQ0IDAwMDAwIG4gCjAwMDAyMDkwMDggMDAwMDAgbiAKMDAwMDIwOTI3MSAwMDAwMCBuIAowMDAw MjA5NTM1IDAwMDAwIG4gCjAwMDAyMDk3OTYgMDAwMDAgbiAKMDAwMDMzMzQyNiAwMDAwMCBuIAow MDAwMzMzNDkxIDAwMDAwIG4gCjAwMDAyMTAwNTcgMDAwMDAgbiAKMDAwMDIxMDMxOCAwMDAwMCBu IAowMDAwMjEwNTc5IDAwMDAwIG4gCjAwMDAyMTA4NDIgMDAwMDAgbiAKMDAwMDMzMzU5MiAwMDAw MCBuIAowMDAwMzMzNjU3IDAwMDAwIG4gCjAwMDAyMTExMDUgMDAwMDAgbiAKMDAwMDMzMzc1OCAw MDAwMCBuIAowMDAwMzMzODIzIDAwMDAwIG4gCjAwMDAyMTEzNjggMDAwMDAgbiAKMDAwMDIxMTYz MiAwMDAwMCBuIAowMDAwMjExODkzIDAwMDAwIG4gCjAwMDAyMTIxNTQgMDAwMDAgbiAKMDAwMDIx MjQxNSAwMDAwMCBuIAowMDAwMjEyNjc2IDAwMDAwIG4gCjAwMDAzMzM5MjQgMDAwMDAgbiAKMDAw MDMzMzk4OSAwMDAwMCBuIAowMDAwMjEyOTM3IDAwMDAwIG4gCjAwMDAzMzQwOTAgMDAwMDAgbiAK MDAwMDMzNDE1NSAwMDAwMCBuIAowMDAwMjEzMTk4IDAwMDAwIG4gCjAwMDAzMzQyNTYgMDAwMDAg biAKMDAwMDMzNDMyMSAwMDAwMCBuIAowMDAwMjEzNDU5IDAwMDAwIG4gCjAwMDAyMTM3MjIgMDAw MDAgbiAKMDAwMDIxMzk4OCAwMDAwMCBuIAowMDAwMzM0NDIyIDAwMDAwIG4gCjAwMDAzMzQ0ODcg MDAwMDAgbiAKMDAwMDIxNDI1NSAwMDAwMCBuIAowMDAwMzM0NTg5IDAwMDAwIG4gCjAwMDAzMzQ2 NTQgMDAwMDAgbiAKMDAwMDIxNDUyMiAwMDAwMCBuIAowMDAwMjE0Nzg3IDAwMDAwIG4gCjAwMDAy MTUwNTEgMDAwMDAgbiAKMDAwMDMzNDc1NyAwMDAwMCBuIAowMDAwMzM0ODIyIDAwMDAwIG4gCjAw MDAyMTUzMTggMDAwMDAgbiAKMDAwMDIxNTU4NSAwMDAwMCBuIAowMDAwMzM0OTI1IDAwMDAwIG4g CjAwMDAzMzQ5OTAgMDAwMDAgbiAKMDAwMDIxNTg1MiAwMDAwMCBuIAowMDAwMjE2MTE5IDAwMDAw IG4gCjAwMDAyMTYzODQgMDAwMDAgbiAKMDAwMDIxNjY0NiAwMDAwMCBuIAowMDAwMzM1MDkzIDAw MDAwIG4gCjAwMDAzMzUxNTggMDAwMDAgbiAKMDAwMDIxNjkwOCAwMDAwMCBuIAowMDAwMzM1MjYx IDAwMDAwIG4gCjAwMDAzMzUzMjYgMDAwMDAgbiAKMDAwMDIxNzE3MCAwMDAwMCBuIAowMDAwMjE3 NDM0IDAwMDAwIG4gCjAwMDAyMTc3MDEgMDAwMDAgbiAKMDAwMDMzNTQyOSAwMDAwMCBuIAowMDAw MzM1NDk0IDAwMDAwIG4gCjAwMDAyMTc5NjggMDAwMDAgbiAKMDAwMDIxODIzMyAwMDAwMCBuIAow MDAwMzM1NTk3IDAwMDAwIG4gCjAwMDAzMzU2NjIgMDAwMDAgbiAKMDAwMDIxODQ5NSAwMDAwMCBu IAowMDAwMjE4NzU3IDAwMDAwIG4gCjAwMDAyMTkwMTkgMDAwMDAgbiAKMDAwMDMzNTc2NSAwMDAw MCBuIAowMDAwMzM1ODMwIDAwMDAwIG4gCjAwMDAyMTkyODMgMDAwMDAgbiAKMDAwMDMzNTkzMyAw MDAwMCBuIAowMDAwMzM1OTk4IDAwMDAwIG4gCjAwMDAyMTk1NTAgMDAwMDAgbiAKMDAwMDMzNjEw MSAwMDAwMCBuIAowMDAwMzM2MTY2IDAwMDAwIG4gCjAwMDAyMTk4MTUgMDAwMDAgbiAKMDAwMDMz NjI2OSAwMDAwMCBuIAowMDAwMzM2MzM0IDAwMDAwIG4gCjAwMDAyMjAwNzkgMDAwMDAgbiAKMDAw MDIyMDM0NCAwMDAwMCBuIAowMDAwMzM2NDM3IDAwMDAwIG4gCjAwMDAzMzY1MDIgMDAwMDAgbiAK MDAwMDIyMDYwNiAwMDAwMCBuIAowMDAwMjIwODY4IDAwMDAwIG4gCjAwMDAzMzY2MDUgMDAwMDAg biAKMDAwMDMzNjY3MCAwMDAwMCBuIAowMDAwMzM2NzczIDAwMDAwIG4gCjAwMDAxOTU5NzEgMDAw MDAgbiAKMDAwMDE5NjIzMSAwMDAwMCBuIAowMDAwMTk2NDkxIDAwMDAwIG4gCjAwMDAxOTY3NTIg MDAwMDAgbiAKMDAwMDE5NzAxOCAwMDAwMCBuIAowMDAwMTk3Mjg0IDAwMDAwIG4gCjAwMDAxOTc1 NDUgMDAwMDAgbiAKMDAwMDE5NzgxMSAwMDAwMCBuIAowMDAwMTk4MDc3IDAwMDAwIG4gCjAwMDAx OTgzNDMgMDAwMDAgbiAKMDAwMDE5ODYwOSAwMDAwMCBuIAowMDAwMzM3MDA0IDAwMDAwIG4gCjAw MDAxOTg4NzUgMDAwMDAgbiAKMDAwMDE5OTEzNiAwMDAwMCBuIAowMDAwMTk5Mzk3IDAwMDAwIG4g CjAwMDAxOTk2NjMgMDAwMDAgbiAKMDAwMDE5OTkyNCAwMDAwMCBuIAowMDAwMjAwMTg1IDAwMDAw IG4gCjAwMDAyMDA0NTEgMDAwMDAgbiAKMDAwMDIwMDcxNyAwMDAwMCBuIAowMDAwMzM3MjExIDAw MDAwIG4gCjAwMDAyMDA5ODMgMDAwMDAgbiAKMDAwMDIwMTI0OSAwMDAwMCBuIAowMDAwMjAxNTEw IDAwMDAwIG4gCjAwMDAyMDE3NzEgMDAwMDAgbiAKMDAwMDIwMjAzMiAwMDAwMCBuIAowMDAwMjAy Mjk4IDAwMDAwIG4gCjAwMDAzMzc0MDIgMDAwMDAgbiAKMDAwMDIwMjU2NCAwMDAwMCBuIAowMDAw MjAyODI1IDAwMDAwIG4gCjAwMDAyMDMwOTEgMDAwMDAgbiAKMDAwMDIwMzM1MiAwMDAwMCBuIAow MDAwMjAzNjEzIDAwMDAwIG4gCjAwMDAyMDM4NzQgMDAwMDAgbiAKMDAwMDIwNDEzNSAwMDAwMCBu IAowMDAwMzM3NjAxIDAwMDAwIG4gCjAwMDAyMDQ0MDEgMDAwMDAgbiAKMDAwMDIwNDY2MiAwMDAw MCBuIAowMDAwMjA0OTIzIDAwMDAwIG4gCjAwMDAzMzc3NjggMDAwMDAgbiAKMDAwMDIwNTE4OSAw MDAwMCBuIAowMDAwMjA1NDUwIDAwMDAwIG4gCjAwMDAyMDU3MTYgMDAwMDAgbiAKMDAwMDIwNTk4 MiAwMDAwMCBuIAowMDAwMjA2MjQ4IDAwMDAwIG4gCjAwMDAyMDY1MDkgMDAwMDAgbiAKMDAwMDIw Njc3MCAwMDAwMCBuIAowMDAwMzM3OTY3IDAwMDAwIG4gCjAwMDAyMDcwMzYgMDAwMDAgbiAKMDAw MDIwNzMwMiAwMDAwMCBuIAowMDAwMjA3NTYzIDAwMDAwIG4gCjAwMDAyMDc4MjQgMDAwMDAgbiAK MDAwMDMzODE0MiAwMDAwMCBuIAowMDAwMjA4MDg1IDAwMDAwIG4gCjAwMDAyMDgzNTEgMDAwMDAg biAKMDAwMDIwODYxMiAwMDAwMCBuIAowMDAwMjA4ODc4IDAwMDAwIG4gCjAwMDAyMDkxMzkgMDAw MDAgbiAKMDAwMDMzODMyNSAwMDAwMCBuIAowMDAwMjA5NDA1IDAwMDAwIG4gCjAwMDAyMDk2NjYg MDAwMDAgbiAKMDAwMDIwOTkyNyAwMDAwMCBuIAowMDAwMjEwMTg4IDAwMDAwIG4gCjAwMDAyMTA0 NDkgMDAwMDAgbiAKMDAwMDIxMDcxMCAwMDAwMCBuIAowMDAwMjEwOTc2IDAwMDAwIG4gCjAwMDAz Mzg1MjQgMDAwMDAgbiAKMDAwMDIxMTIzNiAwMDAwMCBuIAowMDAwMjExNTAyIDAwMDAwIG4gCjAw MDAyMTE3NjMgMDAwMDAgbiAKMDAwMDIxMjAyNCAwMDAwMCBuIAowMDAwMjEyMjg1IDAwMDAwIG4g CjAwMDAyMTI1NDYgMDAwMDAgbiAKMDAwMDIxMjgwNyAwMDAwMCBuIAowMDAwMjEzMDY4IDAwMDAw IG4gCjAwMDAyMTMzMjkgMDAwMDAgbiAKMDAwMDMzODczOSAwMDAwMCBuIAowMDAwMjEzNTkwIDAw MDAwIG4gCjAwMDAyMTM4NTYgMDAwMDAgbiAKMDAwMDIxNDEyMiAwMDAwMCBuIAowMDAwMjE0Mzg5 IDAwMDAwIG4gCjAwMDAyMTQ2NTYgMDAwMDAgbiAKMDAwMDIxNDkxOCAwMDAwMCBuIAowMDAwMjE1 MTg1IDAwMDAwIG4gCjAwMDAyMTU0NTIgMDAwMDAgbiAKMDAwMDIxNTcxOSAwMDAwMCBuIAowMDAw MjE1OTg2IDAwMDAwIG4gCjAwMDAzMzg5NjIgMDAwMDAgbiAKMDAwMDIxNjI1MyAwMDAwMCBuIAow MDAwMjE2NTE1IDAwMDAwIG4gCjAwMDAyMTY3NzcgMDAwMDAgbiAKMDAwMDIxNzAzOSAwMDAwMCBu IAowMDAwMjE3MzAxIDAwMDAwIG4gCjAwMDAyMTc1NjggMDAwMDAgbiAKMDAwMDIxNzgzNSAwMDAw MCBuIAowMDAwMjE4MTAyIDAwMDAwIG4gCjAwMDAyMTgzNjQgMDAwMDAgbiAKMDAwMDIxODYyNiAw MDAwMCBuIAowMDAwMjE4ODg4IDAwMDAwIG4gCjAwMDAyMTkxNTAgMDAwMDAgbiAKMDAwMDMzOTIw MSAwMDAwMCBuIAowMDAwMjE5NDE3IDAwMDAwIG4gCjAwMDAyMTk2ODQgMDAwMDAgbiAKMDAwMDIx OTk0NiAwMDAwMCBuIAowMDAwMjIwMjEzIDAwMDAwIG4gCjAwMDAyMjA0NzUgMDAwMDAgbiAKMDAw MDIyMDczNyAwMDAwMCBuIAowMDAwMjIwOTk5IDAwMDAwIG4gCjAwMDAyMjE3MTcgMDAwMDAgbiAK MDAwMDIyMTc2OSAwMDAwMCBuIAowMDAwMjIxODIzIDAwMDAwIG4gCjAwMDAyMjE5OTEgMDAwMDAg biAKMDAwMDIyMjIzMyAwMDAwMCBuIAowMDAwMjM4MzE2IDAwMDAwIG4gCjAwMDAyMzg1NTcgMDAw MDAgbiAKMDAwMDIzODg1MCAwMDAwMCBuIAowMDAwMjQxNjY5IDAwMDAwIG4gCjAwMDAyNDI3MzQg MDAwMDAgbiAKMDAwMDI0NDk5NyAwMDAwMCBuIAowMDAwMjQ3MTQxIDAwMDAwIG4gCjAwMDAyNDg1 MDMgMDAwMDAgbiAKMDAwMDI1MTAzOSAwMDAwMCBuIAowMDAwMjU0NjA4IDAwMDAwIG4gCjAwMDAy NTY5MzYgMDAwMDAgbiAKMDAwMDI1ODk0MSAwMDAwMCBuIAowMDAwMjU5OTk2IDAwMDAwIG4gCjAw MDAyNjIyMTkgMDAwMDAgbiAKMDAwMDI2NDEzOSAwMDAwMCBuIAowMDAwMjY0ODY4IDAwMDAwIG4g CjAwMDAyNjcwMjYgMDAwMDAgbiAKMDAwMDI2NzY0OCAwMDAwMCBuIAowMDAwMjY4MjgwIDAwMDAw IG4gCjAwMDAyNjk2MDkgMDAwMDAgbiAKMDAwMDI3MDM0MCAwMDAwMCBuIAowMDAwMjcxNjk1IDAw MDAwIG4gCjAwMDAyNzI3NTAgMDAwMDAgbiAKMDAwMDI3NDQzMyAwMDAwMCBuIAowMDAwMjc1MTUy IDAwMDAwIG4gCjAwMDAyNzY0OTggMDAwMDAgbiAKMDAwMDI3NzUzOCAwMDAwMCBuIAowMDAwMjc4 ODkwIDAwMDAwIG4gCjAwMDAyNzk2MjMgMDAwMDAgbiAKMDAwMDI4MDM1NCAwMDAwMCBuIAowMDAw MjgxMDY4IDAwMDAwIG4gCjAwMDAyODIxMzIgMDAwMDAgbiAKMDAwMDI4MzA2NiAwMDAwMCBuIAow MDAwMjg2NDA0IDAwMDAwIG4gCjAwMDAyOTAwNjkgMDAwMDAgbiAKMDAwMDI5NDIyOSAwMDAwMCBu IAowMDAwMjk4NTU5IDAwMDAwIG4gCjAwMDAzMDIxMzIgMDAwMDAgbiAKMDAwMDMwNjczMCAwMDAw MCBuIAowMDAwMzExMzUwIDAwMDAwIG4gCjAwMDAzMTU3MTQgMDAwMDAgbiAKMDAwMDMyMDUwMSAw MDAwMCBuIAowMDAwMzIzMDc4IDAwMDAwIG4gCjAwMDAzMjU0NTQgMDAwMDAgbiAKMDAwMDMyODIx OSAwMDAwMCBuIAp0cmFpbGVyCjw8L1NpemUgOTQxL1ByZXYgMTgxMTkyL1Jvb3QgMSAwIFIvSW5m byAyIDAgUi9JRFs8MUIwRjc2MDIyNzg0M0IyMjEzRjE3OUVGODE1MEVFRUE+PDZFM0E3RDg2ODM2 NzA3QzgzNTg3RDg2QTE1QUNEODM1Pl0+PgpzdGFydHhyZWYKMzM5ODk0CiUlRU9GCg== --Apple-Mail-9B2CF6D8-3635-4138-900A-793DD316BB11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sent from my iPad --Apple-Mail-9B2CF6D8-3635-4138-900A-793DD316BB11-- From sratliff@cisco.com Wed Oct 3 08:24:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E479821F859A for ; Wed, 3 Oct 2012 08:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCa+2vE7qSKX for ; Wed, 3 Oct 2012 08:24:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6F15121F8673 for ; Wed, 3 Oct 2012 08:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2439; q=dns/txt; s=iport; t=1349277869; x=1350487469; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hdSXKUJcZn+GqqqkhGKAYbcVeRNvcEMuiaDwuR9Blbg=; b=ebItj+HKx6c9J54K6KFjglzla6jVqvJNEnwrowR0xK8c5TztjwkVPzeu U8Hqvuyhbr4esrpLcSiLgPP0JxVCFP8imJ1RsF6N3TjI9aoMZ30kmwEyK s9uXCFG5M+CaL5mhMi2wN9/fDaNMoJxGgbd8tZ9rCPwjgfjI6dp/Mtqi4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHxXbFCtJXG//2dsb2JhbABFvnOBCIIgAQEBAwEBAQEPASc0CwULAgEIDgoKFBAnCyUCBAoEBQgah10GC5dhn38EiyOFWmADpCuBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="127947705" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 03 Oct 2012 15:24:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q93FOSZs024191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 15:24:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.244]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 10:24:28 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAAevgA== Date: Wed, 3 Oct 2012 15:24:28 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--42.251400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <89BAD8CBA820A641BDABAEFB4C619CD6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:24:33 -0000 On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: > On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson w= rote: >> I agree with the need for a defined protocol (UDP vs. TCP) as well as = a need to define a separate FSM for both the Router and the Modem. That wil= l ease integration issues for everyone. >=20 > Yes, specific FSMs for both the discovery process, the normal message > transfer and the ACK mechanisms are necessary if we want to have a > chance to get interoperable implementations. I disagree. I've not seen another IETF spec that contains "specific FSMs". = That, IMO, crosses the line between documenting a protocol, and specifying = an implementation.=20 >=20 >> Regarding the Ethernet MAC address comment, there are many L2 devices = on the market that do not utilize the IEEE waveforms or phy, and cannot pro= vide IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP = over the wireless interface due to bandwidth limitations. Pushing additiona= l protocols over bandwidth constrained waveforms can cripple user data thro= ughput or significantly reduce the user's perceived performance of their de= vices. DLEP was designed to allow for optimized performance of wireless de= vices "in general," not just IEEE wireless devices. Thus, we requested addi= tional features to eliminate the redundant and chatty overhead of the proto= cols you mentioned. Furthermore, one should also acknowledge that a modem = device may not be connected to the router via an Ethernet interface, but co= uld be a PCI card, USB connection, etc, and therefore not contain an Ethern= et MAC address. >=20 > Thats why I suggested increasing the size of the "Radio/Modem ID" to > six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide > an unique idea, but it doesn't make it mandatory to use a MAC. The Modem ID/Router ID is intended as an internal (implementation specific)= tag to allow implementations to correlate the traffic to a specific neighb= or.=20 Regards, Stan >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From thomas@thomasclausen.org Wed Oct 3 09:01:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0636521F85C3 for ; Wed, 3 Oct 2012 09:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVU-kTiHV8Hm for ; Wed, 3 Oct 2012 09:01:38 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9021F85EF for ; Wed, 3 Oct 2012 09:01:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 348C6A37A8 for ; Wed, 3 Oct 2012 09:01:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5EBB81C0797; Wed, 3 Oct 2012 09:01:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D3E0E1C0020; Wed, 3 Oct 2012 09:01:32 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Wed, 3 Oct 2012 18:01:29 +0200 To: "Stan Ratliff (sratliff)" Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:01:39 -0000 On 3 oct. 2012, at 17:24, "Stan Ratliff (sratliff)" wro= te: >=20 > On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >=20 >> On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson w= rote: >>> I agree with the need for a defined protocol (UDP vs. TCP) as well as a= need to define a separate FSM for both the Router and the Modem. That will e= ase integration issues for everyone. >>=20 >> Yes, specific FSMs for both the discovery process, the normal message >> transfer and the ACK mechanisms are necessary if we want to have a >> chance to get interoperable implementations. >=20 > I disagree. I've not seen another IETF spec that contains "specific FSMs".= That, IMO, crosses the line between documenting a protocol, and specifying a= n implementation.=20 Well, off the top of my head RFC2328 (OSPF) specifies a number of state mach= ines for various parts of the protocol behavior (interface, neighbor, ..) as= does many other protocols. As a state machine (to me) simply describes what messages a device is allowe= d to process in a given "state", what messages it is allowed to send in a gi= ven "state" and the minimum required actions that must be taken on protocol i= nformation bases upon having received a message, for protocol operation to b= e considered correct - a far cry from specifying an implementation. For the record, my personal point of view is also that a protocol specificat= ion should be sufficiently detailed that any college-graduate programmer-wit= h-no-experience can implement it _correctly_ (but, of course, not efficientl= y) just from the specification alone. (In the Paris 2005 IETF, I called that= "the graduate student criteria for clarity", I think). Cheer, Thomas >=20 >>=20 >>> Regarding the Ethernet MAC address comment, there are many L2 devices o= n the market that do not utilize the IEEE waveforms or phy, and cannot provi= de IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP ove= r the wireless interface due to bandwidth limitations. Pushing additional pr= otocols over bandwidth constrained waveforms can cripple user data throughpu= t or significantly reduce the user's perceived performance of their devices.= DLEP was designed to allow for optimized performance of wireless devices "= in general," not just IEEE wireless devices. Thus, we requested additional f= eatures to eliminate the redundant and chatty overhead of the protocols you m= entioned. Furthermore, one should also acknowledge that a modem device may n= ot be connected to the router via an Ethernet interface, but could be a PCI c= ard, USB connection, etc, and therefore not contain an Ethernet MAC address.= >>=20 >> Thats why I suggested increasing the size of the "Radio/Modem ID" to >> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide >> an unique idea, but it doesn't make it mandatory to use a MAC. >=20 > The Modem ID/Router ID is intended as an internal (implementation specific= ) tag to allow implementations to correlate the traffic to a specific neighb= or.=20 >=20 > Regards, > Stan >=20 >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Wed Oct 3 12:18:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC0711E808A for ; Wed, 3 Oct 2012 12:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJqMCRPznTyK for ; Wed, 3 Oct 2012 12:18:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C636E21F8458 for ; Wed, 3 Oct 2012 12:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3467; q=dns/txt; s=iport; t=1349291894; x=1350501494; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wd+4UDstFpdPeFIudEuLqN3fQYfFU31z2rZpV3UwnZ4=; b=GlY7Z6oPK1xMYC+u28o2XLw3OjdBo8WomHBigqjifH13j8cGDuo6hTCB XpUXSBcYnr68tX9IT97GmY0zsdaFaePqfCXTwTfHWoMMb0CBlmXCtaeqV BJ62VCcJ8HP6kXjySWEuYEg23agtX8JPwH+UFXz/6b0F+djuFAbcQKI6u w=; X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="127783150" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 03 Oct 2012 19:18:14 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-126.cisco.com [10.81.230.126]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q93JID4S007997; Wed, 3 Oct 2012 19:18:14 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> Date: Wed, 3 Oct 2012 15:18:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26D850DA-B53E-4F96-A370-34979DEE5585@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1085) Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:18:15 -0000 Thanks for the comments on the draft. My thoughts on the state machine = suggestion below. -Bo On Oct 3, 2012, at 11:24 AM, Stan Ratliff (sratliff) wrote: >=20 > On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >=20 >> On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson = wrote: >>> I agree with the need for a defined protocol (UDP vs. TCP) as well = as a need to define a separate FSM for both the Router and the Modem. = That will ease integration issues for everyone. >>=20 >> Yes, specific FSMs for both the discovery process, the normal message >> transfer and the ACK mechanisms are necessary if we want to have a >> chance to get interoperable implementations. >=20 > I disagree. I've not seen another IETF spec that contains "specific = FSMs". That, IMO, crosses the line between documenting a protocol, and = specifying an implementation.=20 The draft uses message flow ladder diagrams instead of state diagrams, = state tables, etc. Easier to present in text and are very useful for = implementations (including college students) >>> Regarding the Ethernet MAC address comment, there are many L2 = devices on the market that do not utilize the IEEE waveforms or phy, and = cannot provide IEEE MAC addresses, nor do the developers wish to push = ARP/ND or SNMP over the wireless interface due to bandwidth limitations. = Pushing additional protocols over bandwidth constrained waveforms can = cripple user data throughput or significantly reduce the user's = perceived performance of their devices. DLEP was designed to allow for = optimized performance of wireless devices "in general," not just IEEE = wireless devices. Thus, we requested additional features to eliminate = the redundant and chatty overhead of the protocols you mentioned. = Furthermore, one should also acknowledge that a modem device may not be = connected to the router via an Ethernet interface, but could be a PCI = card, USB connection, etc, and therefore not contain an Ethernet MAC = address. >>=20 >> Thats why I suggested increasing the size of the "Radio/Modem ID" to >> six bytes. This ALLOWS the Radio/Modem to use a MAC address to = provide >> an unique idea, but it doesn't make it mandatory to use a MAC. >=20 > The Modem ID/Router ID is intended as an internal (implementation = specific) tag to allow implementations to correlate the traffic to a = specific neighbor.=20 >=20 > Regards, > Stan >=20 >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From ietf@thomasclausen.org Wed Oct 3 12:53:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA92A11E80A2 for ; Wed, 3 Oct 2012 12:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7GGgk9x6mz1 for ; Wed, 3 Oct 2012 12:53:19 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0CF11E8091 for ; Wed, 3 Oct 2012 12:53:19 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 99B17557F51 for ; Wed, 3 Oct 2012 12:53:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2656C18275C; Wed, 3 Oct 2012 12:53:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 988C2182758; Wed, 3 Oct 2012 12:53:16 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> <26D850DA-B53E-4F96-A370-34979DEE5585@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <26D850DA-B53E-4F96-A370-34979DEE5585@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <574308AC-5660-49C0-AA99-A356408AE869@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Wed, 3 Oct 2012 21:53:13 +0200 To: Bo Berry Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:53:19 -0000 On 3 oct. 2012, at 21:18, Bo Berry wrote: > Thanks for the comments on the draft. My thoughts on the state machine su= ggestion below. > -Bo >=20 >=20 > On Oct 3, 2012, at 11:24 AM, Stan Ratliff (sratliff) wrote: >=20 >>=20 >> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>=20 >>> On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson w= rote: >>>> I agree with the need for a defined protocol (UDP vs. TCP) as well as a= need to define a separate FSM for both the Router and the Modem. That will e= ase integration issues for everyone. >>>=20 >>> Yes, specific FSMs for both the discovery process, the normal message >>> transfer and the ACK mechanisms are necessary if we want to have a >>> chance to get interoperable implementations. >>=20 >> I disagree. I've not seen another IETF spec that contains "specific FSMs"= . That, IMO, crosses the line between documenting a protocol, and specifying= an implementation.=20 >=20 > The draft uses message flow ladder diagrams instead of state diagrams, sta= te tables, etc. Easier to present in text and are very useful for implement= ations (including college students) >=20 Message flow ladder diagrams are fine - no they're great - for giving exampl= es of instances of interaction. I don't quite think that state machines and m= essage flow ladder diagrams are equivalent in their expressiveness, though.=20= In this particular case, where the protocol revolves around establishing an= d maintaining a session between two "devices", I ended up having to draw a s= tate machine to follow the spec (and I got it wrong on the first try, btw), s= o I'd have thought it much helpful had it been in the spec. Best, Thomas >=20 >>>> Regarding the Ethernet MAC address comment, there are many L2 devices o= n the market that do not utilize the IEEE waveforms or phy, and cannot provi= de IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP ove= r the wireless interface due to bandwidth limitations. Pushing additional pr= otocols over bandwidth constrained waveforms can cripple user data throughpu= t or significantly reduce the user's perceived performance of their devices.= DLEP was designed to allow for optimized performance of wireless devices "= in general," not just IEEE wireless devices. Thus, we requested additional f= eatures to eliminate the redundant and chatty overhead of the protocols you m= entioned. Furthermore, one should also acknowledge that a modem device may n= ot be connected to the router via an Ethernet interface, but could be a PCI c= ard, USB connection, etc, and therefore not contain an Ethernet MAC address.= >>>=20 >>> Thats why I suggested increasing the size of the "Radio/Modem ID" to >>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide >>> an unique idea, but it doesn't make it mandatory to use a MAC. >>=20 >> The Modem ID/Router ID is intended as an internal (implementation specifi= c) tag to allow implementations to correlate the traffic to a specific neigh= bor.=20 >>=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> Henning Rogge >>>=20 >>> --=20 >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the sole u= se of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by o= thers is strictly prohibited. If you are not the intended recipient (or auth= orized to receive for the recipient), please contact the sender by reply ema= il and delete all copies of this message. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Wed Oct 3 13:05:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCF221F84B5 for ; Wed, 3 Oct 2012 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZJMEaUrBNzl for ; Wed, 3 Oct 2012 13:05:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EF14C21F84AE for ; Wed, 3 Oct 2012 13:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4767; q=dns/txt; s=iport; t=1349294718; x=1350504318; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ixz9pSQ29zVihjU8uzmvQh6oZZA7Dy8K5274cmtnZ3c=; b=X83X5r/AL53gfH8WGlpuFKdpzW5VznB+G2qUuP1B4Gzpjkvl8WhIAzYA yIy7IWjLNx6gCYxMwTj/RUmdB64lFxdabDt7b6JCDZAlZ/H9zu9O7mWsB RL/gBFb13IzNBoohd6GIp2JuL0jc/4HzjmlvK3ZsbmwxSH2G12tMajHhv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI2ZbFCtJV2Y/2dsb2JhbABFvnyBCIIgAQEBAwEBAQEPAVsLBQsCAQgYCiQnCyUCBAoEBQgah10GC5dmn34EiyMKhVBgA6QrgWmCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="128018069" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 03 Oct 2012 20:05:17 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q93K5H8d011835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 20:05:17 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.244]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 15:05:17 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAAevgIAAQVCAgAAJyICAAANeAA== Date: Wed, 3 Oct 2012 20:05:17 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1956@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> <26D850DA-B53E-4F96-A370-34979DEE5585@cisco.com> <574308AC-5660-49C0-AA99-A356408AE869@thomasclausen.org> In-Reply-To: <574308AC-5660-49C0-AA99-A356408AE869@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.214] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--48.493400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <60B409AF887FFC48AE114E742A5952CF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:05:19 -0000 On Oct 3, 2012, at 3:53 PM, Thomas Heide Clausen wrote: > On 3 oct. 2012, at 21:18, Bo Berry wrote: >=20 >> Thanks for the comments on the draft. My thoughts on the state machine = suggestion below. >> -Bo >>=20 >>=20 >> On Oct 3, 2012, at 11:24 AM, Stan Ratliff (sratliff) wrote: >>=20 >>>=20 >>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>=20 >>>> On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson wrote: >>>>> I agree with the need for a defined protocol (UDP vs. TCP) as well as= a need to define a separate FSM for both the Router and the Modem. That wi= ll ease integration issues for everyone. >>>>=20 >>>> Yes, specific FSMs for both the discovery process, the normal message >>>> transfer and the ACK mechanisms are necessary if we want to have a >>>> chance to get interoperable implementations. >>>=20 >>> I disagree. I've not seen another IETF spec that contains "specific FSM= s". That, IMO, crosses the line between documenting a protocol, and specify= ing an implementation.=20 >>=20 >> The draft uses message flow ladder diagrams instead of state diagrams, s= tate tables, etc. Easier to present in text and are very useful for implem= entations (including college students) >>=20 >=20 > Message flow ladder diagrams are fine - no they're great - for giving exa= mples of instances of interaction. I don't quite think that state machines = and message flow ladder diagrams are equivalent in their expressiveness, th= ough.=20 >=20 > In this particular case, where the protocol revolves around establishing= and maintaining a session between two "devices", I ended up having to draw= a state machine to follow the spec (and I got it wrong on the first try, b= tw), so I'd have thought it much helpful had it been in the spec. >=20 > Best, >=20 > Thomas >=20 =85and if the FSM was as complicated as OSPF, you'd have a fine point. Howe= ver, this FSM pretty much has 2 states: You're "in discovery", or you're "i= n session". Works that way for either the modem or the router. If a college= student needs that mapped out=85.=20 Regards, Stan >>=20 >>>>> Regarding the Ethernet MAC address comment, there are many L2 devices= on the market that do not utilize the IEEE waveforms or phy, and cannot pr= ovide IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP= over the wireless interface due to bandwidth limitations. Pushing addition= al protocols over bandwidth constrained waveforms can cripple user data thr= oughput or significantly reduce the user's perceived performance of their d= evices. DLEP was designed to allow for optimized performance of wireless d= evices "in general," not just IEEE wireless devices. Thus, we requested add= itional features to eliminate the redundant and chatty overhead of the prot= ocols you mentioned. Furthermore, one should also acknowledge that a modem= device may not be connected to the router via an Ethernet interface, but c= ould be a PCI card, USB connection, etc, and therefore not contain an Ether= net MAC address. >>>>=20 >>>> Thats why I suggested increasing the size of the "Radio/Modem ID" to >>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide >>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>=20 >>> The Modem ID/Router ID is intended as an internal (implementation speci= fic) tag to allow implementations to correlate the traffic to a specific ne= ighbor.=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>>=20 >>>> Henning Rogge >>>>=20 >>>> --=20 >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>> billions of percent in a tiny fraction of a second. Of course, that >>>> was before the present government." >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> ---- >> boberry@cisco.com >> This email may contain confidential and privileged material for the sole= use of the intended recipient. This email may contain information that is = protected by NDA. Any unauthorized review, use, distribution or disclosure = by others is strictly prohibited. If you are not the intended recipient (or= authorized to receive for the recipient), please contact the sender by rep= ly email and delete all copies of this message. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From salo@saloits.com Wed Oct 3 13:20:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA04721F8573 for ; Wed, 3 Oct 2012 13:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8f8fmRfhw3k for ; Wed, 3 Oct 2012 13:20:33 -0700 (PDT) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id C080521F84B8 for ; Wed, 3 Oct 2012 13:20:26 -0700 (PDT) Received: from [192.168.254.101] (mpls.saloits.com [216.243.132.62]) by server.saloits.com (8.14.4/8.14.3) with ESMTP id q93KKOfG012001; Wed, 3 Oct 2012 15:20:25 -0500 Message-ID: <506C9E11.1050605@saloits.com> Date: Wed, 03 Oct 2012 15:20:33 -0500 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: " List" References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:20:34 -0000 > I disagree. I've not seen another IETF spec that contains > "specific FSMs". That, IMO, crosses the line between documenting > a protocol, and specifying an implementation. RFC 793, September 1981. Figure 6. I have no idea if the inclusion of a finite state machine was controversial over 30 years ago, but the document appears to have served us well over the last generation. Of course, RFC 793 is TCP, edited by Jon Postel. -tjs From ietf@thomasclausen.org Wed Oct 3 13:22:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F711F042B for ; Wed, 3 Oct 2012 13:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s69GjXmTwT-G for ; Wed, 3 Oct 2012 13:22:23 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 927A41F0422 for ; Wed, 3 Oct 2012 13:22:23 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 3D9C2A614B for ; Wed, 3 Oct 2012 13:22:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D9B34182A96; Wed, 3 Oct 2012 13:22:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 56B2A182A94; Wed, 3 Oct 2012 13:22:21 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> <26D850DA-B53E-4F96-A370-34979DEE5585@cisco.com> <574308AC-5660-49C0-AA99-A356408AE869@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1956@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1956@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8BF408F2-094E-466F-A595-EE7647A7A52B@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Wed, 3 Oct 2012 22:22:15 +0200 To: "Stan Ratliff (sratliff)" Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:22:24 -0000 Sent from my iPad On 3 oct. 2012, at 22:05, "Stan Ratliff (sratliff)" wro= te: >=20 > On Oct 3, 2012, at 3:53 PM, Thomas Heide Clausen wrote: >=20 >> On 3 oct. 2012, at 21:18, Bo Berry wrote: >>=20 >>> Thanks for the comments on the draft. My thoughts on the state machine s= uggestion below. >>> -Bo >>>=20 >>>=20 >>> On Oct 3, 2012, at 11:24 AM, Stan Ratliff (sratliff) wrote: >>>=20 >>>>=20 >>>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>>=20 >>>>> On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson wrote: >>>>>> I agree with the need for a defined protocol (UDP vs. TCP) as well as= a need to define a separate FSM for both the Router and the Modem. That wil= l ease integration issues for everyone. >>>>>=20 >>>>> Yes, specific FSMs for both the discovery process, the normal message >>>>> transfer and the ACK mechanisms are necessary if we want to have a >>>>> chance to get interoperable implementations. >>>>=20 >>>> I disagree. I've not seen another IETF spec that contains "specific FSM= s". That, IMO, crosses the line between documenting a protocol, and specifyi= ng an implementation. >>>=20 >>> The draft uses message flow ladder diagrams instead of state diagrams, s= tate tables, etc. Easier to present in text and are very useful for impleme= ntations (including college students) >>=20 >> Message flow ladder diagrams are fine - no they're great - for giving exa= mples of instances of interaction. I don't quite think that state machines a= nd message flow ladder diagrams are equivalent in their expressiveness, thou= gh.=20 >>=20 >> In this particular case, where the protocol revolves around establishing= and maintaining a session between two "devices", I ended up having to draw a= state machine to follow the spec (and I got it wrong on the first try, btw)= , so I'd have thought it much helpful had it been in the spec. >>=20 >> Best, >>=20 >> Thomas >=20 > =E2=80=A6and if the FSM was as complicated as OSPF, you'd have a fine poin= t. However, this FSM pretty much has 2 states: You're "in discovery", or you= 're "in session". Works that way for either the modem or the router. If a co= llege student needs that mapped out=E2=80=A6.=20 Sure, you can draw any protocol with two states "turned on" and "turned off"= . The pictures I ended up drawing whilst reading through the I-D had conside= rably more than 2 states.... Thomas > Regards, > Stan >=20 >=20 >=20 >>>=20 >>>>>> Regarding the Ethernet MAC address comment, there are many L2 devices= on the market that do not utilize the IEEE waveforms or phy, and cannot pro= vide IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP o= ver the wireless interface due to bandwidth limitations. Pushing additional p= rotocols over bandwidth constrained waveforms can cripple user data throughp= ut or significantly reduce the user's perceived performance of their devices= . DLEP was designed to allow for optimized performance of wireless devices "= in general," not just IEEE wireless devices. Thus, we requested additional f= eatures to eliminate the redundant and chatty overhead of the protocols you m= entioned. Furthermore, one should also acknowledge that a modem device may n= ot be connected to the router via an Ethernet interface, but could be a PCI c= ard, USB connection, etc, and therefore not contain an Ethernet MAC address.= >>>>>=20 >>>>> Thats why I suggested increasing the size of the "Radio/Modem ID" to >>>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide= >>>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>>=20 >>>> The Modem ID/Router ID is intended as an internal (implementation speci= fic) tag to allow implementations to correlate the traffic to a specific nei= ghbor.=20 >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>=20 >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> --=20 >>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>> was before the present government." >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> ---- >>> boberry@cisco.com >>> This email may contain confidential and privileged material for the sole= use of the intended recipient. This email may contain information that is p= rotected by NDA. Any unauthorized review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply e= mail and delete all copies of this message. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Wed Oct 3 13:52:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5F1F0422 for ; Wed, 3 Oct 2012 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xofhjHIHBb4U for ; Wed, 3 Oct 2012 13:52:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1231F0421 for ; Wed, 3 Oct 2012 13:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5481; q=dns/txt; s=iport; t=1349297540; x=1350507140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vJK91RSPejaaBxSwvtqe42Zioi+tv3T7Ha/zvtm+CNs=; b=c/7jFNdF0bn0IwCit4/F0mxaRoHG6nU6Q8kQhfeeBRYgko4iDx++mgRv OIJMuuCVIlI0JKKTLJbEl+hOpW4Ncc7MiU05RviBtMl4MBRmuUMze0asp oCxmMh5k7Y7xoUQXtnOn8q4sAqCVG1LCVmkcqMb6Je9cdYPooPMs33IN7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJWkbFCtJV2Y/2dsb2JhbABFvn6BCIIgAQEBAwEBAQEPAVsLEAIBCBgKJCcLJQIECgQFCBqHXQYLl3ygAQSLIwqFUGADpCuBaYJtgWM0 X-IronPort-AV: E=Sophos;i="4.80,529,1344211200"; d="scan'208";a="127812095" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 03 Oct 2012 20:52:20 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q93KqKNB016211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 20:52:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.244]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 15:52:19 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAAevgIAAQVCAgAAJyICAAANeAIAABL6AgAAIZYA= Date: Wed, 3 Oct 2012 20:52:18 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1B39@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> <26D850DA-B53E-4F96-A370-34979DEE5585@cisco.com> <574308AC-5660-49C0-AA99-A356408AE869@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1956@xmb-aln-x03.cisco.com> <8BF408F2-094E-466F-A595-EE7647A7A52B@thomasclausen.org> In-Reply-To: <8BF408F2-094E-466F-A595-EE7647A7A52B@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.214] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--53.296800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:52:21 -0000 On Oct 3, 2012, at 4:22 PM, Thomas Heide Clausen wrote: >=20 >=20 > Sent from my iPad >=20 > On 3 oct. 2012, at 22:05, "Stan Ratliff (sratliff)" = wrote: >=20 >>=20 >> On Oct 3, 2012, at 3:53 PM, Thomas Heide Clausen wrote: >>=20 >>> On 3 oct. 2012, at 21:18, Bo Berry wrote: >>>=20 >>>> Thanks for the comments on the draft. My thoughts on the state machin= e suggestion below. >>>> -Bo >>>>=20 >>>>=20 >>>> On Oct 3, 2012, at 11:24 AM, Stan Ratliff (sratliff) wrote: >>>>=20 >>>>>=20 >>>>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>>>=20 >>>>>> On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson wrote: >>>>>>> I agree with the need for a defined protocol (UDP vs. TCP) as well = as a need to define a separate FSM for both the Router and the Modem. That = will ease integration issues for everyone. >>>>>>=20 >>>>>> Yes, specific FSMs for both the discovery process, the normal messag= e >>>>>> transfer and the ACK mechanisms are necessary if we want to have a >>>>>> chance to get interoperable implementations. >>>>>=20 >>>>> I disagree. I've not seen another IETF spec that contains "specific F= SMs". That, IMO, crosses the line between documenting a protocol, and speci= fying an implementation. >>>>=20 >>>> The draft uses message flow ladder diagrams instead of state diagrams,= state tables, etc. Easier to present in text and are very useful for impl= ementations (including college students) >>>=20 >>> Message flow ladder diagrams are fine - no they're great - for giving e= xamples of instances of interaction. I don't quite think that state machine= s and message flow ladder diagrams are equivalent in their expressiveness, = though.=20 >>>=20 >>> In this particular case, where the protocol revolves around establishi= ng and maintaining a session between two "devices", I ended up having to dr= aw a state machine to follow the spec (and I got it wrong on the first try,= btw), so I'd have thought it much helpful had it been in the spec. >>>=20 >>> Best, >>>=20 >>> Thomas >>=20 >> =85and if the FSM was as complicated as OSPF, you'd have a fine point. H= owever, this FSM pretty much has 2 states: You're "in discovery", or you're= "in session". Works that way for either the modem or the router. If a coll= ege student needs that mapped out=85.=20 >=20 > Sure, you can draw any protocol with two states "turned on" and "turned o= ff". The pictures I ended up drawing whilst reading through the I-D had con= siderably more than 2 states.... >=20 > Thomas If that's the case, I'd be interested in your notes. Are they in the docume= nt you posted to the list?=20 Regards, Stan >=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >>>>=20 >>>>>>> Regarding the Ethernet MAC address comment, there are many L2 devic= es on the market that do not utilize the IEEE waveforms or phy, and cannot = provide IEEE MAC addresses, nor do the developers wish to push ARP/ND or SN= MP over the wireless interface due to bandwidth limitations. Pushing additi= onal protocols over bandwidth constrained waveforms can cripple user data t= hroughput or significantly reduce the user's perceived performance of their= devices. DLEP was designed to allow for optimized performance of wireless= devices "in general," not just IEEE wireless devices. Thus, we requested a= dditional features to eliminate the redundant and chatty overhead of the pr= otocols you mentioned. Furthermore, one should also acknowledge that a mod= em device may not be connected to the router via an Ethernet interface, but= could be a PCI card, USB connection, etc, and therefore not contain an Eth= ernet MAC address. >>>>>>=20 >>>>>> Thats why I suggested increasing the size of the "Radio/Modem ID" to >>>>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provi= de >>>>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>>>=20 >>>>> The Modem ID/Router ID is intended as an internal (implementation spe= cific) tag to allow implementations to correlate the traffic to a specific = neighbor.=20 >>>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Henning Rogge >>>>>>=20 >>>>>> --=20 >>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>> was before the present government." >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> ---- >>>> boberry@cisco.com >>>> This email may contain confidential and privileged material for the so= le use of the intended recipient. This email may contain information that i= s protected by NDA. Any unauthorized review, use, distribution or disclosur= e by others is strictly prohibited. If you are not the intended recipient (= or authorized to receive for the recipient), please contact the sender by r= eply email and delete all copies of this message. >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>=20 From ietf@thomasclausen.org Wed Oct 3 13:56:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7E71F0425 for ; Wed, 3 Oct 2012 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAK6JF7X+ypF for ; Wed, 3 Oct 2012 13:56:13 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 395BC1F0421 for ; Wed, 3 Oct 2012 13:56:13 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id E1AB1A67E3 for ; Wed, 3 Oct 2012 13:56:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 63BEA182EF3; Wed, 3 Oct 2012 13:56:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C3B0A182EE8; Wed, 3 Oct 2012 13:56:11 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> <26D850DA-B53E-4F96-A370-34979DEE5585@cisco.com> <574308AC-5660-49C0-AA99-A356408AE869@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1956@xmb-aln-x03.cisco.com> <8BF408F2-094E-466F-A595-EE7647A7A52B@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1B39@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E1B39@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Wed, 3 Oct 2012 22:56:08 +0200 To: "Stan Ratliff (sratliff)" Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:56:13 -0000 On 3 oct. 2012, at 22:52, "Stan Ratliff (sratliff)" wro= te: >=20 > On Oct 3, 2012, at 4:22 PM, Thomas Heide Clausen wrote: >=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On 3 oct. 2012, at 22:05, "Stan Ratliff (sratliff)" w= rote: >>=20 >>>=20 >>> On Oct 3, 2012, at 3:53 PM, Thomas Heide Clausen wrote: >>>=20 >>>> On 3 oct. 2012, at 21:18, Bo Berry wrote: >>>>=20 >>>>> Thanks for the comments on the draft. My thoughts on the state machin= e suggestion below. >>>>> -Bo >>>>>=20 >>>>>=20 >>>>> On Oct 3, 2012, at 11:24 AM, Stan Ratliff (sratliff) wrote: >>>>>=20 >>>>>>=20 >>>>>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>>>>=20 >>>>>>> On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson wrote: >>>>>>>> I agree with the need for a defined protocol (UDP vs. TCP) as well a= s a need to define a separate FSM for both the Router and the Modem. That wi= ll ease integration issues for everyone. >>>>>>>=20 >>>>>>> Yes, specific FSMs for both the discovery process, the normal messag= e >>>>>>> transfer and the ACK mechanisms are necessary if we want to have a >>>>>>> chance to get interoperable implementations. >>>>>>=20 >>>>>> I disagree. I've not seen another IETF spec that contains "specific FS= Ms". That, IMO, crosses the line between documenting a protocol, and specify= ing an implementation. >>>>>=20 >>>>> The draft uses message flow ladder diagrams instead of state diagrams,= state tables, etc. Easier to present in text and are very useful for imple= mentations (including college students) >>>>=20 >>>> Message flow ladder diagrams are fine - no they're great - for giving e= xamples of instances of interaction. I don't quite think that state machines= and message flow ladder diagrams are equivalent in their expressiveness, th= ough.=20 >>>>=20 >>>> In this particular case, where the protocol revolves around establishi= ng and maintaining a session between two "devices", I ended up having to dra= w a state machine to follow the spec (and I got it wrong on the first try, b= tw), so I'd have thought it much helpful had it been in the spec. >>>>=20 >>>> Best, >>>>=20 >>>> Thomas >>>=20 >>> =E2=80=A6and if the FSM was as complicated as OSPF, you'd have a fine po= int. However, this FSM pretty much has 2 states: You're "in discovery", or y= ou're "in session". Works that way for either the modem or the router. If a c= ollege student needs that mapped out=E2=80=A6.=20 >>=20 >> Sure, you can draw any protocol with two states "turned on" and "turned o= ff". The pictures I ended up drawing whilst reading through the I-D had cons= iderably more than 2 states.... >>=20 >> Thomas >=20 >=20 > If that's the case, I'd be interested in your notes. Are they in the docum= ent you posted to the list?=20 >=20 No, they are - literally - on a napkin from my lunch when I worked through i= t today. After all, aren't all IETF protocols designed on napkins? ;) I've kept that napkin, as I thought it might come handy. I will try to find a= scanner and share it. Won't be tonight, though, and likely not tomorrow, bu= t probably Friday (and, if you don't have it then, remind me..) since that's= when I know that I'll be back in an office with a scanner. Cheers, Thomas =20 > Regards, > Stan >=20 >>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>=20 >>>>>=20 >>>>>>>> Regarding the Ethernet MAC address comment, there are many L2 devic= es on the market that do not utilize the IEEE waveforms or phy, and cannot p= rovide IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP= over the wireless interface due to bandwidth limitations. Pushing additiona= l protocols over bandwidth constrained waveforms can cripple user data throu= ghput or significantly reduce the user's perceived performance of their devi= ces. DLEP was designed to allow for optimized performance of wireless devic= es "in general," not just IEEE wireless devices. Thus, we requested addition= al features to eliminate the redundant and chatty overhead of the protocols y= ou mentioned. Furthermore, one should also acknowledge that a modem device m= ay not be connected to the router via an Ethernet interface, but could be a P= CI card, USB connection, etc, and therefore not contain an Ethernet MAC addr= ess. >>>>>>>=20 >>>>>>> Thats why I suggested increasing the size of the "Radio/Modem ID" to= >>>>>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provi= de >>>>>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>>>>=20 >>>>>> The Modem ID/Router ID is intended as an internal (implementation spe= cific) tag to allow implementations to correlate the traffic to a specific n= eighbor.=20 >>>>>>=20 >>>>>> Regards, >>>>>> Stan >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Henning Rogge >>>>>>>=20 >>>>>>> --=20 >>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>>> was before the present government." >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> ---- >>>>> boberry@cisco.com >>>>> This email may contain confidential and privileged material for the so= le use of the intended recipient. This email may contain information that is= protected by NDA. Any unauthorized review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply e= mail and delete all copies of this message. >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >=20 From hrogge@googlemail.com Thu Oct 4 01:07:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264DE21F865C for ; Thu, 4 Oct 2012 01:07: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4VyG7rYWM4U for ; Thu, 4 Oct 2012 01:07:41 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E621F861F for ; Thu, 4 Oct 2012 01:07:41 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so268637pad.31 for ; Thu, 04 Oct 2012 01:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=40ym8OHmzLRcpHWnWT+7MZeDKmtiKJ2MaRiEqAE6UyM=; b=gsZ2jsbMASiADNYjFCpsAfaCaBZbExUURpZSVSPi/iwo/m19F+BdzhWQfa0oS3BEDi KQWGoq/2ZGX6hyxiGSwNw9+WJdQIgXG1wXPypDhH9XAKDAmfsL1PyFM3IkcpoTH3bHfE H6hLKDa1xatE48GGjuJs1wWDShjDTVX8XaAx1d025cheN1daLEGT/iMrUPfm7AqWHKj+ IvKLFbtaA7598FHMRNcvkMS0EXY9fhUrUwzjFrQvxMARIWID3EXMi6yAquzBtgAMAKCx slrhVKgJ39T+JSGC8QruoUZi0hNp4AF6+sMS+ixuYvaPRpUOH+rnZ/sBRgCE1FoW9TT9 sv2Q== Received: by 10.68.130.194 with SMTP id og2mr19644448pbb.131.1349338061286; Thu, 04 Oct 2012 01:07:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Thu, 4 Oct 2012 01:07:21 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Thu, 4 Oct 2012 10:07:21 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 08:07:42 -0000 On Wed, Oct 3, 2012 at 5:24 PM, Stan Ratliff (sratliff) wrote: > On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >> Yes, specific FSMs for both the discovery process, the normal message >> transfer and the ACK mechanisms are necessary if we want to have a >> chance to get interoperable implementations. > > I disagree. I've not seen another IETF spec that contains "specific FSMs". That, IMO, crosses the line between documenting a protocol, and specifying an implementation. As Thomas Clausen said too, the FSM for DLEP is not that trivia. The "flow charts" are nice, but they do not tell the whole story, because you cannot see which parts of them are causally connected and which just happen one after another. Teco already raised the question about ACKs and if a Radio had to wait for an ACK before it sends the next data. A description of the protocols internal mechanism (similar to the one we have for NHDP or OLSRv2) would give an implementer an EXAMPLE how it could be implemented (and a template to test different implementation ideas against). >> Thats why I suggested increasing the size of the "Radio/Modem ID" to >> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide >> an unique idea, but it doesn't make it mandatory to use a MAC. > > The Modem ID/Router ID is intended as an internal (implementation specific) tag to allow implementations to correlate the traffic to a specific neighbor. I know... I just want to extend it to 6 byte... we will need an unique idea for each radio attached to a router. If the ID is 6 bytes, a radio who has some kind of MAC address (for example its ethernet mac address) it can use this as the default for an unique number. But the user of the radio could later change this ID. I do not want to change the semantics of the ID, I just want enough bytes to have a source for an unique number (like the MAC address). Everything you can do with a 4 byte ID you can do with a 6 byte ID too. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From boberry@cisco.com Thu Oct 4 14:31:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBF41F0C42 for ; Thu, 4 Oct 2012 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0r7CzjTZmZU for ; Thu, 4 Oct 2012 14:31:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D70511F0425 for ; Thu, 4 Oct 2012 14:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1948; q=dns/txt; s=iport; t=1349386281; x=1350595881; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XijJDC9GPB0fn14BdYoOa13BuCYr+tqJplVLUQYPqTU=; b=UPY5FnBkHMKNJdcuacd3nSO/DvwzZp958LTR9H6MQORnka0x6fdQ5wD6 YQUxZucMDLjxqdQMQBm9iezuBZyoXDYwNEeyO6ekxEf/R/8I6xUaNE5+S 1XcXTLZTTylbRjFQYPUrv/3rwiX3nsk3NCdw2dhXSQ76fz8OkRtfWcgLy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH7/bVCtJXG+/2dsb2JhbABFvxaBCIIgAQEBBBIBJz8QCw4KLlcGNYdjmB2gFIs+hT1gA5VpjkOBaYMJ X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="128451202" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 04 Oct 2012 21:31:20 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q94LVJTK002635; Thu, 4 Oct 2012 21:31:20 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Thu, 4 Oct 2012 17:31:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:31:21 -0000 Henning Thanks for the feedback. Further discussion below. On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: > ~~cut >> Regarding the Ethernet MAC address comment, there are many L2 = devices on the market that do not utilize the IEEE waveforms or phy, and = cannot provide IEEE MAC addresses, nor do the developers wish to push = ARP/ND or SNMP over the wireless interface due to bandwidth limitations. = Pushing additional protocols over bandwidth constrained waveforms can = cripple user data throughput or significantly reduce the user's = perceived performance of their devices. DLEP was designed to allow for = optimized performance of wireless devices "in general," not just IEEE = wireless devices. Thus, we requested additional features to eliminate = the redundant and chatty overhead of the protocols you mentioned. = Furthermore, one should also acknowledge that a modem device may not be = connected to the router via an Ethernet interface, but could be a PCI = card, USB connection, etc, and therefore not contain an Ethernet MAC = address. >=20 > Thats why I suggested increasing the size of the "Radio/Modem ID" to > six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide > an unique idea, but it doesn't make it mandatory to use a MAC. Currently there are two suggestions for the Router/Radio ID fields =20 1)move the RR-IDs into the DLSP message header 2)expand the fields from 4-byte field currently intended to be a uint32, to 6-bytes so MAC addresses can be used as the unique IDs. Another option, with the new DLEP formatting, is to drop the IDs and use the underlying transport/driver addressing information=20 as the discriminator. This would save 12-bytes plus TLV bytes from every message and the associated processing. =20 Checking with a few off-list, this has been received in positive=20 light.=20 Thoughts from the WG welcomed. Regard -Bo =20 From hrogge@googlemail.com Fri Oct 5 01:04:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC83321F8609 for ; Fri, 5 Oct 2012 01:04:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f3XlMmE-Swl for ; Fri, 5 Oct 2012 01:04:08 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id F088021F84F3 for ; Fri, 5 Oct 2012 01:04:07 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1470637pad.31 for ; Fri, 05 Oct 2012 01:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/cfNyH76E7tmZ0vlZ2yP8ZlRhrfhCQattnOzd83+fi4=; b=Coq6nw1lRotZB6BfeqlMJktr9Qm1aNL8Ec9SDPsJAdsjzOr+oB5d/j9Mq9oyXz9nFt B6hp4vqbbzPXaPOZy3J1lCTaeBR1x+ja2DlIXA08xja684eM7KizMdnM2M22e3eC+2JT zjIN6+VL/UILAyfA1bXnqDobZq9pZDR6jAPqgFozq2CW192WCA9pYsaIsYl985WDKTPe TCJLtpI+VgQJOcqojuMYHmNgSB25h9hV8ZAd222ShkxCW0k1RwVwBB83ehhOlDJoUt5o mQbwukkG3VB8zG1Ury0rnfSiL95FKraIuQ1ZfQoFZhxgS2cPNj/+bhMpYrqH9PO1iEun B+2w== Received: by 10.66.78.97 with SMTP id a1mr19595583pax.34.1349424247637; Fri, 05 Oct 2012 01:04:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Fri, 5 Oct 2012 01:03:47 -0700 (PDT) In-Reply-To: <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> From: Henning Rogge Date: Fri, 5 Oct 2012 10:03:47 +0200 Message-ID: To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 08:04:09 -0000 On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry wrote: > Henning > Thanks for the feedback. Further discussion below. > > On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >> Thats why I suggested increasing the size of the "Radio/Modem ID" to >> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide >> an unique idea, but it doesn't make it mandatory to use a MAC. > > Currently there are two suggestions for the Router/Radio ID fields > 1)move the RR-IDs into the DLSP message header > 2)expand the fields from 4-byte field currently intended to > be a uint32, to 6-bytes so MAC addresses can be used as > the unique IDs. > > Another option, with the new DLEP formatting, is to drop the > IDs and use the underlying transport/driver addressing information > as the discriminator. This would save 12-bytes plus TLV bytes > from every message and the associated processing. This might be an interesting option for "one line" radios/modems (hardware with a single layer-2 interface), similar to the design of NHDP where you can drop the THIS_IF TLV if you only have one and the src-ip can be used for THIS_IF. But there are some "multi line" Software Defined Radios, which are controlled over a single IP interface. With the current design of DLEP the port number has to be fixed (well known) on both sides of the connection, otherwise the "symmetric discovery" doesn't work. I think DLEP should allow to have multiple radio instances which can communicate to a router over the same IP interface. Maybe there could be a rule that IF DLEP uses UDP, then the combination of IP and port could be used as the ID of the router. Of course this means that the ID becomes a 16 or 18 byte string for IPv6. (I am still not convinced that allowing the router to play the active discovery part is a good idea, this can lead to all kinds of trouble including non-dlep aware radios suddenly sending DLEP-discovery beacons of the router over the air). > Checking with a few off-list, this has been received in positive > light. Can you maybe suggest that people that they come to this list and contribute? IETF protocols should be discussed and developed on this lists, but at the moment DLEP looks a bit like an one-way street of information. Henning -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Fri Oct 5 03:16:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E5D21F861B for ; Fri, 5 Oct 2012 03:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs0iU4NRofyk for ; Fri, 5 Oct 2012 03:16:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E535B21F8618 for ; Fri, 5 Oct 2012 03:16:19 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1929624vbb.31 for ; Fri, 05 Oct 2012 03:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tew1XWRpMoBWD/GfQKzUShZ0LNrTfRN6rHXhs3G+CHQ=; b=HUUU4BIay14boLdBJZ6SIpGQYw06JddPDrGKT28ogIqqLrU9vJ3DE5ThScs7CVd5xm wwjMsqNFrh3UlVzrfryNztBNWeyyXrX0pex6RRjunGNtynbjy/AzlftIdvD1gNgR2utK YDbRQodERQy5CSiDUfxpBikXtgl0EvdE4tsdJYPt5vXyQAnLzpq97dnJogMED4URiAEE z6OdFh529L+CQYJ9cepo3v6tf147W1IOIjMxt8ItsRRQXNJzFSAiA++cz+TJ4jgILyC0 DFTHpT2RJgsaSqr2C2R1/936LdoUShLbO05bYPFNWpcyzz/SS3DXx0/AmdeqaUA70JQn 98wg== MIME-Version: 1.0 Received: by 10.220.119.198 with SMTP id a6mr4933505vcr.23.1349432179336; Fri, 05 Oct 2012 03:16:19 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 5 Oct 2012 03:16:19 -0700 (PDT) In-Reply-To: <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> Date: Fri, 5 Oct 2012 11:16:19 +0100 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: multipart/alternative; boundary=bcaec54fb624b2a53604cb4d29a6 Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:16:21 -0000 --bcaec54fb624b2a53604cb4d29a6 Content-Type: text/plain; charset=ISO-8859-1 > > > Currently there are two suggestions for the Router/Radio ID fields > 1)move the RR-IDs into the DLSP message header > 2)expand the fields from 4-byte field currently intended to > be a uint32, to 6-bytes so MAC addresses can be used as > the unique IDs. > > Another option, with the new DLEP formatting, is to drop the > IDs and use the underlying transport/driver addressing information > as the discriminator. This would save 12-bytes plus TLV bytes > from every message and the associated processing. > > Checking with a few off-list, this has been received in positive > light. > Why it is positive? I think all options have advantages, but when I choose one I want to know why? > > Thoughts from the WG welcomed. > will do my best, > Regard > -Bo > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec54fb624b2a53604cb4d29a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
Curr= ently there are two suggestions for the Router/Radio ID fields
1)move the RR-IDs into the DLSP message header
2)expand the fields from 4-byte field currently intended to
=A0 be a uint32, to 6-bytes so MAC addresses can be used as
=A0 the unique IDs.

Another option, with the new DLEP formatting, is to drop the
IDs and use the underlying transport/driver addressing information
as the discriminator. =A0This would save 12-bytes plus TLV bytes
from every message and the associated processing.

Checking with a few off-list, this has been received in positive
light.
=A0
Why it is positive? I think all o= ptions have advantages, but when I choose one I want to know why?
=A0
=A0

Thoughts from the WG welcomed.
will do my best,=A0
=A0
Regard
-Bo


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec54fb624b2a53604cb4d29a6-- From boberry@cisco.com Fri Oct 5 04:01:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221F021F86A5 for ; Fri, 5 Oct 2012 04:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIwnEvkcv8Zb for ; Fri, 5 Oct 2012 04:01:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96521F86A3 for ; Fri, 5 Oct 2012 04:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3276; q=dns/txt; s=iport; t=1349434886; x=1350644486; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7Fd7S8Z9IlDkq9LFWNLDVZsjt0zpOfJdkJMn6dzuhpY=; b=F1jXOfbhJSd8wpiL2+wPZburytrYG04xHVvw1uPHDheEAlqwbF9Jfym6 1joHHVswZJ0lTpPMZbJDRt6YrZVD+cXLIQvPCPuG128lX/Ubogxl8JUaK AgfFsDndLGcJo4IJiSJcxa/ScrHRV2oK/bGP7LGbTxdBDmhuyRq27mj5Q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMC8blCtJV2c/2dsb2JhbABFvyCBCIIgAQEBAwESASc/BQsLDgouVwYTIoddBphToAaLPoUpYAOVa4ViiGOBaYMJgUc X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128654815" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 05 Oct 2012 11:01:25 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-65.cisco.com [10.81.230.65]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q95B1Pit023109; Fri, 5 Oct 2012 11:01:25 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Fri, 5 Oct 2012 07:01:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:01:27 -0000 On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: > On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry wrote: >> Henning >> Thanks for the feedback. Further discussion below. >>=20 >> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>> Thats why I suggested increasing the size of the "Radio/Modem ID" to >>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to = provide >>> an unique idea, but it doesn't make it mandatory to use a MAC. >>=20 >> Currently there are two suggestions for the Router/Radio ID fields >> 1)move the RR-IDs into the DLSP message header >> 2)expand the fields from 4-byte field currently intended to >> be a uint32, to 6-bytes so MAC addresses can be used as >> the unique IDs. >>=20 >> Another option, with the new DLEP formatting, is to drop the >> IDs and use the underlying transport/driver addressing information >> as the discriminator. This would save 12-bytes plus TLV bytes >> from every message and the associated processing. >=20 > This might be an interesting option for "one line" radios/modems > (hardware with a single layer-2 interface), similar to the design of > NHDP where you can drop the THIS_IF TLV if you only have one and the > src-ip can be used for THIS_IF. >=20 > But there are some "multi line" Software Defined Radios, which are > controlled over a single IP interface. With the current design of DLEP > the port number has to be fixed (well known) on both sides of the > connection, otherwise the "symmetric discovery" doesn't work. I think > DLEP should allow to have multiple radio instances which can > communicate to a router over the same IP interface. yes, I agree, DLEP should support multiple radios on the same i/f=20 if that i/f support such. Let us review this aspect. =20 >=20 > Maybe there could be a rule that IF DLEP uses UDP, then the > combination of IP and port could be used as the ID of the router. Of > course this means that the ID becomes a 16 or 18 byte string for IPv6. >=20 > (I am still not convinced that allowing the router to play the active > discovery part is a good idea, this can lead to all kinds of trouble > including non-dlep aware radios suddenly sending DLEP-discovery > beacons of the router over the air). >=20 >> Checking with a few off-list, this has been received in positive >> light. >=20 > Can you maybe suggest that people that they come to this list and > contribute? IETF protocols should be discussed and developed on this > lists, but at the moment DLEP looks a bit like an one-way street of > information. >=20 > Henning > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From abdussalambaryun@gmail.com Fri Oct 5 04:04:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6721F8588 for ; Fri, 5 Oct 2012 04:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqlhR+6zK-sf for ; Fri, 5 Oct 2012 04:04:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0321F8685 for ; Fri, 5 Oct 2012 04:04:06 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2061747vcb.31 for ; Fri, 05 Oct 2012 04:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mWMR3SoMGKCC8uudVXnMXShlJAba9D+2q2uSWm/PHfM=; b=PoJx4owezLa5u0LD8TeZTGGXzD5KETub5LlguE9OSc3ftW6cLSHNrn7QosEskavCmo N3+xFd5svksjw0a1dolK1fhkPPXYTvEFAwyY0betwvWjWQ+rt5KLWAWfPRCgSNBd8rzV S5cgXG/4LRucFo+ZHXfrrQSYrZu9OECbW9rF3ckEoUrOVERV+wm9YeM3P3eIgQUCs958 htuVkhOm5VQAx08eW8K14gZGGvnvWzo7F9NwmHjLqHrCO9Lgn2WE+nDJJ3fdZmRtW0cF zU8FWXSbEMz8dyt5smtq8TktX35/ATUm54gZgL7bE1IqFHjEP5VQA4K4G4ky14chxqpV 5BBw== MIME-Version: 1.0 Received: by 10.52.27.102 with SMTP id s6mr2078171vdg.99.1349435041698; Fri, 05 Oct 2012 04:04:01 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 5 Oct 2012 04:04:01 -0700 (PDT) In-Reply-To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> Date: Fri, 5 Oct 2012 12:04:01 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" , Bo Berry Content-Type: multipart/alternative; boundary=20cf307f371e4ed2a204cb4dd465 Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:04:08 -0000 --20cf307f371e4ed2a204cb4dd465 Content-Type: text/plain; charset=ISO-8859-1 Hi, I support that we need the FSM (as Teco and Henning requested), to clarify many issues. The problem with the flow diagram is that it is good only within a specific protocol, but DLEP states is not dependent only within one protocol in one layer, but it is a protocol that is interacting with a MANET Routing protocol. Therefore, IMO, the FSM approach is suitable for DLEP not flow diagram. I suggest that who suggested/supports the FSM to submit his/her views and suggestions, for progress, I will try to do the same Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++ On Thu, Oct 4, 2012 at 9:07 AM, Henning Rogge wrote: > On Wed, Oct 3, 2012 at 5:24 PM, Stan Ratliff (sratliff) > wrote: > > On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: > >> Yes, specific FSMs for both the discovery process, the normal message > >> transfer and the ACK mechanisms are necessary if we want to have a > >> chance to get interoperable implementations. > > > > I disagree. I've not seen another IETF spec that contains "specific > FSMs". That, IMO, crosses the line between documenting a protocol, and > specifying an implementation. > > As Thomas Clausen said too, the FSM for DLEP is not that trivia. > > The "flow charts" are nice, but they do not tell the whole story, > because you cannot see which parts of them are causally connected and > which just happen one after another. > > Teco already raised the question about ACKs and if a Radio had to wait > for an ACK before it sends the next data. A description of the > protocols internal mechanism (similar to the one we have for NHDP or > OLSRv2) would give an implementer an EXAMPLE how it could be > implemented (and a template to test different implementation ideas > against). > > >> Thats why I suggested increasing the size of the "Radio/Modem ID" to > >> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide > >> an unique idea, but it doesn't make it mandatory to use a MAC. > > > > The Modem ID/Router ID is intended as an internal (implementation > specific) tag to allow implementations to correlate the traffic to a > specific neighbor. > > I know... I just want to extend it to 6 byte... we will need an unique > idea for each radio attached to a router. If the ID is 6 bytes, a > radio who has some kind of MAC address (for example its ethernet mac > address) it can use this as the default for an unique number. > > But the user of the radio could later change this ID. > > I do not want to change the semantics of the ID, I just want enough > bytes to have a source for an unique number (like the MAC address). > > Everything you can do with a 4 byte ID you can do with a 6 byte ID too. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307f371e4ed2a204cb4dd465 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I support that we need the FSM (as Teco an= d Henning requested), to clarify many issues. The problem with the flow dia= gram is that it is good only within a specific=A0protocol, but DLEP states= =A0is not dependent only within one protocol in one layer, but it is a prot= ocol that is interacting with a MANET Routing protocol. Therefore, IMO, the= FSM approach is suitable for DLEP not=A0flow diagram.
=A0
I suggest that who suggested/supports the FSM to submit = his/her views and suggestions, for progress, I will try to do the same
=A0
Abdussalam Baryun
University of Glamorgan, UK=
++++++++++++++++++++++
On Thu, Oct= 4, 2012 at 9:07 AM, Henning Rogge <hrogge@googlemail.com> wrote:
On Wed, Oct 3, 2012 at 5:24 PM, Stan Rat= liff (sratliff)
<sratliff@cisco.com> wrote:=
> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote:
>> Yes, specific FSMs for both the discovery = process, the normal message
>> transfer and the ACK mechanisms are necessary if we want to have a=
>> chance to get interoperable implementations.
>
> I disagree. I've not seen another IETF spec that contains "sp= ecific FSMs". That, IMO, crosses the line between documenting a protoc= ol, and specifying an implementation.

As Thomas Clausen said too, the FSM for DLEP is not that trivia.

The "flow charts" are nice, but they do not tell the whole story,=
because you cannot see which parts of them are causally connected and
which just happen one after another.

Teco already raised the question about ACKs and if a Radio had to wait
for an ACK before it sends the next data. A description of the
protocols internal mechanism (similar to the one we have for NHDP or
OLSRv2) would give an implementer an EXAMPLE how it could be
implemented (and a template to test different implementation ideas
against).

>> Thats why I suggested increasing the size of the "Radio/Modem= ID" to
>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to pro= vide
>> an unique idea, but it doesn't make it mandatory to use a MAC.=
>
> The Modem ID/Router ID is intended as an internal (implementation spec= ific) tag to allow implementations to correlate the traffic to a specific n= eighbor.

I know... I just want to extend it to 6 byte... we will need an uniqu= e
idea for each radio attached to a router. If the ID is 6 bytes, a
radio who has some kind of MAC address (for example its ethernet mac
address) it can use this as the default for an unique number.

But the user of the radio could later change this ID.

I do not want to change the semantics of the ID, I just want enough
bytes to have a source for an unique number (like the MAC address).

Everything you can do with a 4 byte ID you can do with a 6 byte ID too.

Henning Rogge
--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307f371e4ed2a204cb4dd465-- From sratliff@cisco.com Fri Oct 5 06:40:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E021F876E for ; Fri, 5 Oct 2012 06:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYncucibb28c for ; Fri, 5 Oct 2012 06:40:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B780421F876D for ; Fri, 5 Oct 2012 06:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=835; q=dns/txt; s=iport; t=1349444456; x=1350654056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uNPsIo0xx23XB7VYVLFKzbuHZEcmd2lfiQ5irYhD8K4=; b=WJUF7Vpl1pOd9jgpEHVUs3T/tLy6/dT8rNv8lC7GMpBIP3znOjirMtYp nehdXuFXJuLufnzk2KMUAtc4NcE1WNywaZ7Zwmqrs1kGqLz0VYQ9Aq3vO o9AGvtgTodvagtO0LSR82lubkB6PJsqhFOzFGzKsmyOX0zjo0CXPyKvwF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGLiblCtJXG9/2dsb2JhbABFvx+BCIIgAQEBAwESASc/EAIBCA4UFBAyJQIEDg0ah10GmCWgDIs+hSlgA6QwgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128668746" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Oct 2012 13:40:56 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q95DeufG014788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 13:40:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.244]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 08:40:55 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgABeMoA= Date: Fri, 5 Oct 2012 13:40:55 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--23.776500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <995B900FEC3CF141A6662D3887D4BA1F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:40:57 -0000 On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >=20 > Can you maybe suggest that people that they come to this list and > contribute? [snip] ...DLEP looks a bit like an one-way street of > information. >=20 It would be difficult for me to disagree with you more on this. The DLEP co= -authors have presented the draft to the working group, discussed on this l= ist, and held meetings with a number of people, yourself included. To claim= that this is a "one-way street of information" is disingenuous, and offens= ive. We have accepted changes and additions to the draft, and have been as = responsive as our "day jobs" allow. Additionally, you assume facts not in evidence - specifically, that we *hav= en't* encouraged people to contribute on the list. Nothing could be further= from the truth.=20 Stan From sratliff@cisco.com Fri Oct 5 06:45:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EAA21F8709 for ; Fri, 5 Oct 2012 06:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIy38GMHa8Iv for ; Fri, 5 Oct 2012 06:44:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 191E921F8740 for ; Fri, 5 Oct 2012 06:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4200; q=dns/txt; s=iport; t=1349444699; x=1350654299; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eMQ7rDSs/jFiG3qCGwvcLgcfWKYHWJ7tf0Xw4/zRksI=; b=SfnN0U9Vm5RpalRT1ECpKG7kESQfqknWLOaM6+voYImF0avVV70FVvCO leyhzH91R1nQELDfsp8fe/rLgnnozvzrlZ7IYQWtaHKmuTyLWpo7wWZzm xC/oZPf/fORrvRTTvrflU6d4QHFFUEuHjwHBImyUrgpkEWhQn6hITTEod 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADrjblCtJXG//2dsb2JhbABFvx+BCIIgAQEBAwEBAQEPAVsLEAIBCBgKJCcLJQIEDgUIGoddBguYG6AIBIs+hSlgA6QwgWmCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128644602" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 05 Oct 2012 13:44:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q95DiuKJ021435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 13:44:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.244]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 08:44:56 -0500 From: "Stan Ratliff (sratliff)" To: "Bo Berry (boberry)" Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAAC2wgA== Date: Fri, 5 Oct 2012 13:44:56 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A91@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> In-Reply-To: <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--54.053600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <1A1BC714CB62BE4E96A4752AD9F5D1DF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:45:00 -0000 On Oct 5, 2012, at 7:01 AM, Bo Berry wrote: >=20 > On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >=20 >> On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry wrote: >>> Henning >>> Thanks for the feedback. Further discussion below. >>>=20 >>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>> Thats why I suggested increasing the size of the "Radio/Modem ID" to >>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide >>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>=20 >>> Currently there are two suggestions for the Router/Radio ID fields >>> 1)move the RR-IDs into the DLSP message header >>> 2)expand the fields from 4-byte field currently intended to >>> be a uint32, to 6-bytes so MAC addresses can be used as >>> the unique IDs. >>>=20 >>> Another option, with the new DLEP formatting, is to drop the >>> IDs and use the underlying transport/driver addressing information >>> as the discriminator. This would save 12-bytes plus TLV bytes >>> from every message and the associated processing. >>=20 >> This might be an interesting option for "one line" radios/modems >> (hardware with a single layer-2 interface), similar to the design of >> NHDP where you can drop the THIS_IF TLV if you only have one and the >> src-ip can be used for THIS_IF. >>=20 >> But there are some "multi line" Software Defined Radios, which are >> controlled over a single IP interface. With the current design of DLEP >> the port number has to be fixed (well known) on both sides of the >> connection, otherwise the "symmetric discovery" doesn't work. I think >> DLEP should allow to have multiple radio instances which can >> communicate to a router over the same IP interface. >=20 > yes, I agree, DLEP should support multiple radios on the same i/f=20 > if that i/f support such. Let us review this aspect. =20 The main issue we've seen with multiple radios on the same interface is how= the broadcast domains start to overlap. Assume that all "stations" have a = router, and 3 radios that are on different frequencies, etc=85 Now assume t= hat all radios can establish connection with all other radios - a full mesh= connection, on all of the radio devices. So, any router has 3 physical pat= hs (each of the different radios) to the same destination. But, all 3 of th= ose physical paths are represented by a single interface=85. so what happen= s to things like broadcast packets? Do they get picked up and sent via all = 3 radios?=20 Stan >=20 >>=20 >> Maybe there could be a rule that IF DLEP uses UDP, then the >> combination of IP and port could be used as the ID of the router. Of >> course this means that the ID becomes a 16 or 18 byte string for IPv6. >>=20 >> (I am still not convinced that allowing the router to play the active >> discovery part is a good idea, this can lead to all kinds of trouble >> including non-dlep aware radios suddenly sending DLEP-discovery >> beacons of the router over the air). >>=20 >>> Checking with a few off-list, this has been received in positive >>> light. >>=20 >> Can you maybe suggest that people that they come to this list and >> contribute? IETF protocols should be discussed and developed on this >> lists, but at the moment DLEP looks a bit like an one-way street of >> information. >>=20 >> Henning >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >=20 > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that is p= rotected by NDA. Any unauthorized review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y email and delete all copies of this message. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From l.wood@surrey.ac.uk Fri Oct 5 06:57:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7103421F86FF for ; Fri, 5 Oct 2012 06:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOavJ6gItDhu for ; Fri, 5 Oct 2012 06:57:40 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7B67521F86EE for ; Fri, 5 Oct 2012 06:57:40 -0700 (PDT) X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-3.tower-72.messagelabs.com!1349445459!12113094!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11571 invoked from network); 5 Oct 2012 13:57:39 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-3.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 5 Oct 2012 13:57:39 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.203]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 5 Oct 2012 14:57:38 +0100 From: To: , Date: Fri, 5 Oct 2012 14:57:33 +0100 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgABeMoD//63s+g== Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> , <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org, boberry@cisco.com Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:57:41 -0000 Stan, You have actively discouraged people with differing views from contributin= g, and you know it. It's not as if dlep is the only solution to this problem. I don't see broad= industry involvement in draft authorship, either. Isn't there a conflict b= etween the same person chairing the group and pushing dlep for Cisco? Doing= one of these things is fine. Doing both at the same time, no. Lloyd Wood http://sat-net.com/L.Wood/modem-router-integration ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Stan Rat= liff (sratliff) [sratliff@cisco.com] Sent: 05 October 2012 14:40 To: Henning Rogge Cc: List; Bo Berry (boberry) Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: > > Can you maybe suggest that people that they come to this list and > contribute? [snip] ...DLEP looks a bit like an one-way street of > information. > It would be difficult for me to disagree with you more on this. The DLEP co= -authors have presented the draft to the working group, discussed on this l= ist, and held meetings with a number of people, yourself included. To claim= that this is a "one-way street of information" is disingenuous, and offens= ive. We have accepted changes and additions to the draft, and have been as = responsive as our "day jobs" allow. Additionally, you assume facts not in evidence - specifically, that we *hav= en't* encouraged people to contribute on the list. Nothing could be further= from the truth. Stan _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Oct 5 07:41:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9B21F86F0 for ; Fri, 5 Oct 2012 07:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW9fnjwkHEzw for ; Fri, 5 Oct 2012 07:41:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D20AA21F86DA for ; Fri, 5 Oct 2012 07:41:28 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2358672vcb.31 for ; Fri, 05 Oct 2012 07:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W2rGCtnDnf0XlnIHZ4m//4eYgzxuMbtMBhuwbqPLvOc=; b=d29I4dWVwrtK0mVzpEB7EyAlpnX0VQpD6/fxjzOhe0618x4AJ8ciKSZpqa+zjBbNaw a7iWi8tcfm+5KXjTHneumSCeGsTo/Qso+Z/MNqDPaFzu+jTUzLpLGx8Y0CD4AkRT0t+6 RmkRvT19jWXRAdhs1qKQMhKSCLDg1rmd/6KaKnU2LWAUkvbLYV0rsXvkAxBDDscO3jVi A6Y92vHpP/7a7wl4LMuigxyqPAmRcqk8GIJSnWIjJZdts8P3cy6kU0Kphu48IFBL8vuP eji9PvYfGkQEmbDUM4jCwOkPMBqycM2j7O0Sw0w1jVP2A2FZZfMeRMXZcktyV1lJVbCq Xi/w== MIME-Version: 1.0 Received: by 10.220.37.194 with SMTP id y2mr5224176vcd.44.1349448088189; Fri, 05 Oct 2012 07:41:28 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 5 Oct 2012 07:41:27 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> Date: Fri, 5 Oct 2012 15:41:27 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=bcaec54eea8ef07b3e04cb50dde9 Cc: " List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:41:30 -0000 --bcaec54eea8ef07b3e04cb50dde9 Content-Type: text/plain; charset=ISO-8859-1 Hi Stan, > To claim that this is a "one-way street of information" is disingenuous, and offensive. We have accepted changes and additions to the draft, and have been as responsive as our "day jobs" allow. IMHO, I have experienced with one manet-draft that authors taken a one-way street of information approach, but I think we should not allow it for DLEP and other WG-drafts, because these are IETF MANET WG drafts, not authors or companies draft. I RECOMMEND the WG chair to consider input of the list and announce in the face-to-face meeting the list concerns. I thank you that you confirm that the dlep authors are not taking such approach, even though some participants may felt that for some reasons, AB ----- On Fri, Oct 5, 2012 at 2:40 PM, Stan Ratliff (sratliff) wrote: > > On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: > > > > > Can you maybe suggest that people that they come to this list and > > contribute? [snip] ...DLEP looks a bit like an one-way street of > > information. > > > > It would be difficult for me to disagree with you more on this. The DLEP > co-authors have presented the draft to the working group, discussed on this > list, and held meetings with a number of people, yourself included. To > claim that this is a "one-way street of information" is disingenuous, and > offensive. We have accepted changes and additions to the draft, and have > been as responsive as our "day jobs" allow. > > Additionally, you assume facts not in evidence - specifically, that we > *haven't* encouraged people to contribute on the list. Nothing could be > further from the truth. > > Stan > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec54eea8ef07b3e04cb50dde9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stan,
=A0
>=A0To claim that this is a "= one-way street of information" is disingenuous, and offensive. We have= accepted changes and additions to the draft, and have been as responsive a= s our "day jobs" allow.

IMHO, I have experienced with one=A0manet-draft that authors taken a=A0= one-way street of information approach, but I think we should not allow it = for DLEP and other WG-drafts, because these are IETF MANET WG drafts, not a= uthors or companies draft.
=A0
I RECOMMEND the WG chair to consider input of the list a= nd announce in the face-to-face meeting the list concerns. I thank you that= you confirm that the dlep authors are not taking such approach, even thoug= h some participants may felt that for some reasons,
=A0
AB
-----
=A0
On Fri, Oct 5, 2012 at 2:40 PM, Stan Ratliff (sratliff) <sratli= ff@cisco.com> wrote:

On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote:

>
> Can you maybe suggest that people that they co= me to this list and
> contribute? [snip] ...DLEP looks a bit like an one-way street of=
> information.
>

It would be difficult for me to disagree with you more on this. The DLEP co= -authors have presented the draft to the working group, discussed on this l= ist, and held meetings with a number of people, yourself included. To claim= that this is a "one-way street of information" is disingenuous, = and offensive. We have accepted changes and additions to the draft, and hav= e been as responsive as our "day jobs" allow.

Additionally, you assume facts not in evidence - specifically, that we *hav= en't* encouraged people to contribute on the list. Nothing could be fur= ther from the truth.

Stan

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec54eea8ef07b3e04cb50dde9-- From abdussalambaryun@gmail.com Fri Oct 5 07:59:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712AE21F869E for ; Fri, 5 Oct 2012 07:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjLz7g72Pahh for ; Fri, 5 Oct 2012 07:59:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F18921F8471 for ; Fri, 5 Oct 2012 07:59:36 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2386059vcb.31 for ; Fri, 05 Oct 2012 07:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q31jPlrrU0oaSRdp6MdFhDZ63ngnYvdMzfu5+Q6s8+I=; b=xa3I36vYUwUiWIWLA3d5ErT5aJKk30JD2qPROpUlaOQzRcZZn3oru+Gcgpuh24AcJ0 JcVhvqwexW5VN/5zzF3Obr1qARp5UGddS7QyHiyfPnPNT66JCjQxYTaenweGtkIniQ6W nzj0J1PxQogXag7VOYKtEL+c3GFylfkueyFGkOYmFI6tfXK1Cm+Se0aAv3skNM1q0h1t KHU5poKgK4M6QSbH3LxiL7IfSj8aIAySlSi2Ke+iz926XpTaA7RJZkaWBGYCl6ivKl27 5cbmYBcYHPDNne19UoM+ys+TL9joGBegUtpze8CYri6xsOc+im7X7Pn0/kNWIl225zWA Iz6Q== MIME-Version: 1.0 Received: by 10.58.12.231 with SMTP id b7mr5609187vec.28.1349449175954; Fri, 05 Oct 2012 07:59:35 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 5 Oct 2012 07:59:35 -0700 (PDT) Date: Fri, 5 Oct 2012 15:59:35 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7b41bf32c673b804cb511e70 Subject: [manet] MANET Charter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:59:37 -0000 --047d7b41bf32c673b804cb511e70 Content-Type: text/plain; charset=ISO-8859-1 To: MANET WG Chair, Please consider discussing to update the charter, also include this in the MANET face-to-face meeting. Please add this request to the agenda. This request is to respond to input [1]. I RECOMMEND that the charter considers input [3] or to amend and add some words in the following paragraph mentioned in the charter: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic network topologies with increased dynamics due to node motion, link breakage, or attacked node. The amendement is needed even if it maybe clear [2], but to avoid misunderstanding of participants. [1] http://www.ietf.org/mail-archive/web/manet/current/msg13292.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg13353.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg13348.html Best Regards AB --047d7b41bf32c673b804cb511e70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To: MANET WG Chair,
=A0
Please consider discussing to update the=A0charter, also include this=A0in= the MANET face-to-face meeting. Please add this request to the agenda.
This request=A0is to respond to input=A0[1].=A0 I=A0RECOMM= END that the charter considers=A0input [3]=A0or to amend and add some words= in the following paragraph mentioned in the charter:
The purpose of the MANET working group is to standardize I= P routing
protocol functionality suitable for wireless routing applicati= on within
both static and dynamic network topologies with increased dyna= mics=A0due to node
motion, link breakage,=A0or attacked node.
=A0=A0
The a= mendement is needed even if it maybe=A0clear [2], but to avoid misunderstan= ding=A0of participants.
=A0
=A0
=A0
Best Regards
AB

--047d7b41bf32c673b804cb511e70-- From ietf@thomasclausen.org Fri Oct 5 10:24:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB92A21F8619 for ; Fri, 5 Oct 2012 10:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95lBHfKoy9vO for ; Fri, 5 Oct 2012 10:24:20 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 089A521F860B for ; Fri, 5 Oct 2012 10:24:19 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id D383E557FB1 for ; Fri, 5 Oct 2012 10:24:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 61B2A1C0824; Fri, 5 Oct 2012 10:24:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.145.34.131] (unknown [37.160.17.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D765E1C0567; Fri, 5 Oct 2012 10:24:17 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <49CF9C90-418B-4F2E-BD5C-113089874458@thomasclausen.org> X-Mailer: iPhone Mail (10A403) From: Thomas Heide Clausen Date: Fri, 5 Oct 2012 19:24:13 +0200 To: "Stan Ratliff (sratliff)" Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:24:20 -0000 Throwing a bone at Stan and bo here: I have discussed dlep with Stan out-of-= band on many occasions, and he has (as far as I remember) always encouraged t= hat I bounce my thoughts off the mailing list (especially when he didn't agr= ee with me ;) ).=20 That I haven't done so as frequently as I maybe should have is entirely to b= lame on me. I've been trying to catch up, though... Of course, I cannot speak for the other folks Stan/Bo/etc have spoken to, bu= t I would assume that they've encouraged them to the same. I do agree that the more discussion happens on the list for WG documents, th= e better - of course. I guess that it goes without saying that the WG chairs= agree ;) Thomas=20 --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 5 oct. 2012, at 15:40, "Stan Ratliff (sratliff)" wro= te: >=20 > On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >=20 >>=20 >> Can you maybe suggest that people that they come to this list and >> contribute? [snip] ...DLEP looks a bit like an one-way street of >> information. >=20 > It would be difficult for me to disagree with you more on this. The DLEP c= o-authors have presented the draft to the working group, discussed on this l= ist, and held meetings with a number of people, yourself included. To claim t= hat this is a "one-way street of information" is disingenuous, and offensive= . We have accepted changes and additions to the draft, and have been as resp= onsive as our "day jobs" allow. >=20 > Additionally, you assume facts not in evidence - specifically, that we *ha= ven't* encouraged people to contribute on the list. Nothing could be further= from the truth.=20 >=20 > Stan >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Fri Oct 5 10:32:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA54421F87DE for ; Fri, 5 Oct 2012 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDiAY83TGtLJ for ; Fri, 5 Oct 2012 10:32:37 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AE9B921F87DB for ; Fri, 5 Oct 2012 10:32:37 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 33EDE557F46 for ; Fri, 5 Oct 2012 10:32:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BB8A51BDD397; Fri, 5 Oct 2012 10:32:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.84.217.48] (37-8-166-184.coucou-networks.fr [37.8.166.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 52D691BDD391; Fri, 5 Oct 2012 10:32:36 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A51@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <20380DC5-8289-4A88-9609-9E8FFC70C64A@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Fri, 5 Oct 2012 19:32:34 +0200 To: "" Cc: "manet@ietf.org" , "boberry@cisco.com" , "" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:32:38 -0000 Lloyd, That is a fairly serious accusation to make. =20 I'd like to go on record that while I know of cases in the IETF where a conf= lict-of-interest was at play, I have noticed no such thing in MANET. Thomas Sent from my iPad On 5 oct. 2012, at 15:57, wrote: >=20 > Stan, >=20 > You have actively discouraged people with differing views from contributi= ng, and you know it. >=20 > It's not as if dlep is the only solution to this problem. I don't see broa= d industry involvement in draft authorship, either. Isn't there a conflict b= etween the same person chairing the group and pushing dlep for Cisco? Doing o= ne of these things is fine. Doing both at the same time, no. >=20 > Lloyd Wood > http://sat-net.com/L.Wood/modem-router-integration >=20 > ________________________________________ > From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Stan Ra= tliff (sratliff) [sratliff@cisco.com] > Sent: 05 October 2012 14:40 > To: Henning Rogge > Cc: List; Bo Berry (boberry) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >=20 >>=20 >> Can you maybe suggest that people that they come to this list and >> contribute? [snip] ...DLEP looks a bit like an one-way street of >> information. >=20 > It would be difficult for me to disagree with you more on this. The DLEP c= o-authors have presented the draft to the working group, discussed on this l= ist, and held meetings with a number of people, yourself included. To claim t= hat this is a "one-way street of information" is disingenuous, and offensive= . We have accepted changes and additions to the draft, and have been as resp= onsive as our "day jobs" allow. >=20 > Additionally, you assume facts not in evidence - specifically, that we *ha= ven't* encouraged people to contribute on the list. Nothing could be further= from the truth. >=20 > Stan >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From adrian@olddog.co.uk Fri Oct 5 15:11:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79E521F8648 for ; Fri, 5 Oct 2012 15:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea4v6npcUbkT for ; Fri, 5 Oct 2012 15:11:02 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id EF77921F863B for ; Fri, 5 Oct 2012 15:11:01 -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 q95MB0UD010318 for ; Fri, 5 Oct 2012 23:11:00 +0100 Received: from 950129200 ([31.102.20.218]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q95MAw2R010300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Oct 2012 23:10:59 +0100 From: "Adrian Farrel" To: Date: Fri, 5 Oct 2012 23:10:58 +0100 Message-ID: <11e801cda346$4d1b37c0$e751a740$@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: Ac2jRkjjpKqjIM7gTCyHrQdW8J5nzQ== Content-Language: en-gb Subject: [manet] Take a breath over the weekend, please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 22:11:02 -0000 Hi, The discussion here seems to be getting a little more heated than might be considered productive. Please have a break over the weekend and come back on Monday with your technical discussions. FWIW, Stan is a WG co-chair and an author of DLEP. I am confident that he separates the two, and that Joe will take all management actions (including and especially consensus calls) wrt DLEP. If you have concerns about a WG chair's behavior you have every right to call them on it, but do be sure you have the back-up for what you say, and understand that I am the next person you should complain to. I will expect to be shown evidence in a put-up or shut-up fashion. One further point of note is that DLEP is a working group document. The authors are custodians of the text on behalf of the WG, and although they are expected to lead the editing and generation of new text, the WG can drive the content through discussion on the mailing list (with consensus calls if necessary). Understanding how rough consensus works is fundamental to the operation of the IETF and all of us (even ADs) find ourselves in the rough from time to time. Thanks, Adrian From adrian@olddog.co.uk Fri Oct 5 15:22:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600C621F8527 for ; Fri, 5 Oct 2012 15:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+w-2c1cxcYY for ; Fri, 5 Oct 2012 15:22:21 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5471A21F8682 for ; Fri, 5 Oct 2012 15:22:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q95MMIl7019209; Fri, 5 Oct 2012 23:22:18 +0100 Received: from 950129200 ([31.102.20.218]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q95MMFHP019195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Oct 2012 23:22:17 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: In-Reply-To: Date: Fri, 5 Oct 2012 23:22:13 +0100 Message-ID: <11e901cda347$e100bd60$a3023820$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11EA_01CDA350.42C79660" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLHxWzk+/o4nfcwp8q4cOWDX8waoJW3ApZA Content-Language: en-gb Cc: 'manet' Subject: Re: [manet] MANET Charter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 22:22:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_11EA_01CDA350.42C79660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Abdussalam, It might help everyone if you made a concrete proposal for the specific word changes that you want to see. I don't know that it will be helpful to spend WG time in the f2f meeting unless there is something that has already been floated for discussion. The WG is certainly free to spend cycles debating refinements to its charter, but please also remember who charters working groups, and who has to approve the text. You need to propose the specific change you want to see (not just propose that someone makes the change), you need to convince the rest of the WG of the change you want to make, and you have to convince me. Thanks, Adrian From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 05 October 2012 16:00 To: manet Subject: [manet] MANET Charter To: MANET WG Chair, Please consider discussing to update the charter, also include this in the MANET face-to-face meeting. Please add this request to the agenda. This request is to respond to input [1]. I RECOMMEND that the charter considers input [3] or to amend and add some words in the following paragraph mentioned in the charter: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic network topologies with increased dynamics due to node motion, link breakage, or attacked node. The amendement is needed even if it maybe clear [2], but to avoid misunderstanding of participants. [1] http://www.ietf.org/mail-archive/web/manet/current/msg13292.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg13353.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg13348.html Best Regards AB ------=_NextPart_000_11EA_01CDA350.42C79660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Abdussalam,

 

It might help everyone if you = made a concrete proposal for the specific word changes that you want to = see. I don't know that it will be helpful to spend WG time in the f2f = meeting unless there is something that has already been floated for = discussion.

 

The WG is certainly free to = spend cycles debating refinements to its charter, but please also = remember who charters working groups, and who has to approve the text. = You need to propose the specific change you want to see (not just = propose that someone makes the change), you need to convince the rest of = the WG of the change you want to make, and you have to convince me. =

 

Thanks,

Adrian

 

From: = manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of = Abdussalam Baryun
Sent: 05 October 2012 = 16:00
To: manet
Subject: [manet] MANET = Charter

 

To: MANET WG Chair,

 

Please consider discussing to update the charter, = also include this in the MANET face-to-face meeting. Please add = this request to the agenda.

This request is to respond to = input [1].  I RECOMMEND that the charter = considers input [3] or to amend and add some words in the = following paragraph mentioned in the = charter:

The purpose of = the MANET working group is to standardize IP routing
protocol = functionality suitable for wireless routing application within
both = static and dynamic network topologies with increased dynamics due = to node
motion, link breakage, or attacked = node.

  

The amendement is needed even if it maybe clear = [2], but to avoid misunderstanding of = participants.

 

 

 

Best Regards

AB

<= p class=3DMsoNormal> 

------=_NextPart_000_11EA_01CDA350.42C79660-- From teco@inf-net.nl Sat Oct 6 02:06:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D62C21F84A6 for ; Sat, 6 Oct 2012 02:06:20 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QejzHhPoQv9 for ; Sat, 6 Oct 2012 02:06:19 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9981921F8672 for ; Sat, 6 Oct 2012 02:06:11 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so1525459wib.1 for ; Sat, 06 Oct 2012 02:06:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=i5lM22ql/4jleocna9EGeApNv5ImaMehCJE8HtSRG8c=; b=gOHIEglJYWM//2Pa4gRQuekCf915htIOAYUg3DKWmJmx2uhaIJ2uPrCs4VjSKlCdqQ U2NykzUyggJzYJGE5cR552VHJmLsUOmuF8krAjI7a5FNTtsk1cApjZn3qHGQ2G0BHC0o FUQ4e1eDsnp0+UH280Qs6ct+7GIcFiMn8aUaZiL87QJDmj1TClondMO8q93Nt3HYw82M 8dptRRVFv0AAHXoiMuKe6vpgGo0Z7RaKPjukCVLVxpxCnGiiY6/u9YCcgKt0IenivO7+ HgVL6PYB4YhVaX4P0bfxY6TV5g4XYkIjUH+vKk+bAYtHR6xVZ9j2k5ksPX+f0E1dO9I7 v/dA== Received: by 10.180.82.34 with SMTP id f2mr8547025wiy.17.1349514360638; Sat, 06 Oct 2012 02:06:00 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id p4sm7938934wix.0.2012.10.06.02.05.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Oct 2012 02:06:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A91@xmb-aln-x03.cisco.com> Date: Sat, 6 Oct 2012 11:05:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18E8C672-F659-4E3D-BEE9-371E9BB35BDD@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E5A91@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl3JkJ+PwKmVpl+9W/spp7qcCQfCUpw3EiVtPXlnb2eApPlR7O5CFQ9KZWZIxgxKpDLwObU Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 09:06:20 -0000 Op 5 okt. 2012, om 15:44 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Oct 5, 2012, at 7:01 AM, Bo Berry wrote: >=20 >>=20 >> On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >>=20 >>> On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry wrote: >>>> Henning >>>> Thanks for the feedback. Further discussion below. >>>>=20 >>>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>>> Thats why I suggested increasing the size of the "Radio/Modem ID" = to >>>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to = provide >>>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>>=20 >>>> Currently there are two suggestions for the Router/Radio ID fields >>>> 1)move the RR-IDs into the DLSP message header >>>> 2)expand the fields from 4-byte field currently intended to >>>> be a uint32, to 6-bytes so MAC addresses can be used as >>>> the unique IDs. >>>>=20 >>>> Another option, with the new DLEP formatting, is to drop the >>>> IDs and use the underlying transport/driver addressing information >>>> as the discriminator. This would save 12-bytes plus TLV bytes >>>> from every message and the associated processing. >>>=20 >>> This might be an interesting option for "one line" radios/modems >>> (hardware with a single layer-2 interface), similar to the design of >>> NHDP where you can drop the THIS_IF TLV if you only have one and the >>> src-ip can be used for THIS_IF. >>>=20 >>> But there are some "multi line" Software Defined Radios, which are >>> controlled over a single IP interface. With the current design of = DLEP >>> the port number has to be fixed (well known) on both sides of the >>> connection, otherwise the "symmetric discovery" doesn't work. I = think >>> DLEP should allow to have multiple radio instances which can >>> communicate to a router over the same IP interface. >>=20 >> yes, I agree, DLEP should support multiple radios on the same i/f=20 >> if that i/f support such. Let us review this aspect. =20 >=20 > The main issue we've seen with multiple radios on the same interface = is how the broadcast domains start to overlap. Assume that all = "stations" have a router, and 3 radios that are on different = frequencies, etc=85 Now assume that all radios can establish connection = with all other radios - a full mesh connection, on all of the radio = devices. So, any router has 3 physical paths (each of the different = radios) to the same destination. But, all 3 of those physical paths are = represented by a single interface=85. so what happens to things like = broadcast packets? Do they get picked up and sent via all 3 radios?=20 This is a somewhat more complex scenario that can be supported easily. = STP is the old days solution. TRILL and other members in that family = could be used. With MANET, sub-IP protocols can take care of it. On how to support it: it is up to the radios to deliver the frame (it's = L2, so I use frame), they may use the wired link or the wireless link. I expect DLEP to provide data to the router, so the router can (should) = select the best L2-path to the L3 next-hop. If dlep-03 can't do it, = let's fix it. I proposed a solution for it multiple times (in the = 802.11s context). Teco =20 >=20 > Stan >=20 >>=20 >>>=20 >>> Maybe there could be a rule that IF DLEP uses UDP, then the >>> combination of IP and port could be used as the ID of the router. Of >>> course this means that the ID becomes a 16 or 18 byte string for = IPv6. >>>=20 >>> (I am still not convinced that allowing the router to play the = active >>> discovery part is a good idea, this can lead to all kinds of trouble >>> including non-dlep aware radios suddenly sending DLEP-discovery >>> beacons of the router over the air). >>>=20 >>>> Checking with a few off-list, this has been received in positive >>>> light. >>>=20 >>> Can you maybe suggest that people that they come to this list and >>> contribute? IETF protocols should be discussed and developed on this >>> lists, but at the moment DLEP looks a bit like an one-way street of >>> information. >>>=20 >>> Henning >>> --=20 >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>=20 >> ---- >> boberry@cisco.com >> This email may contain confidential and privileged material for the = sole use of the intended recipient. This email may contain information = that is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Sat Oct 6 02:08:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302F221F8433 for ; Sat, 6 Oct 2012 02:08:29 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXyz9jHF2ewF for ; Sat, 6 Oct 2012 02:08:28 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDDF21F842C for ; Sat, 6 Oct 2012 02:08:28 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1331050wib.13 for ; Sat, 06 Oct 2012 02:08:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Wqpm7i4/hyfQLPs8UCbsRjOUxu/yHZbr1JN+5ZDAyTM=; b=o20uKT/hck4iIAf1jE94XrqasQzlSQIIvkvc7O/XTfuPGkLjwNQbG2WfKzIVFb04m7 ou/9gNKyB1SNbNC8Vo/4oJA06pXXdMNn2bo/hCvS+gDpuHAXbDgWWM9U6zZ+e4Y2+D1O r41p4oLLnB6Zxceo/iEEDZsb5NfVLcpX70yKiU12yWwBCVPLlhYDJEWfqnSiuuii0PNk fABYGMEAf80HhZuwf7EMydfTG1BtIzPRtWtTaSyQCFWGUlVfUmWHvUb2s7s8aMjCDsGT Z6VpoDCT7xRMqerJyMd1G28qQjM3zv8vxnJpFpt6gFnYBnDAk6Qr+5FT0a/ELIAY52p6 jV8g== Received: by 10.180.100.97 with SMTP id ex1mr8597543wib.17.1349514507103; Sat, 06 Oct 2012 02:08:27 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id ei1sm7630231wid.7.2012.10.06.02.08.26 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Oct 2012 02:08:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sat, 6 Oct 2012 11:08:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3E114F@xmb-aln-x03.cisco.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmTpiPp6XM+/6oJFlTqrWMeroRwZWEzWefN1le7NzTvflICym8dfa6lxBRzZ2xRH/WjtPFF Cc: " List" , Bo Berry , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 09:08:29 -0000 Op 5 okt. 2012, om 13:04 heeft Abdussalam Baryun het volgende = geschreven: > I support that we need the FSM (as Teco and Henning requested), to = clarify many issues. I did not request FSM. My comment was that the -03 DLEP protocol is somewhat underspecified. = Especially on session setup, loss/retransmit and optional heartbeats. My = suggestion was to simplify the protocol and keep using RFC 5444, on a = more efficient way. Teco From pcgayan@yahoo.com Sun Oct 7 03:05:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2587A21F84FF for ; Sun, 7 Oct 2012 03:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.22 X-Spam-Level: ** X-Spam-Status: No, score=2.22 tagged_above=-999 required=5 tests=[BAYES_50=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUM8kPHhNhAY for ; Sun, 7 Oct 2012 03:05:52 -0700 (PDT) Received: from nm27-vm4.bullet.mail.ne1.yahoo.com (nm27-vm4.bullet.mail.ne1.yahoo.com [98.138.91.187]) by ietfa.amsl.com (Postfix) with SMTP id 7827621F84F8 for ; Sun, 7 Oct 2012 03:05:52 -0700 (PDT) Received: from [98.138.226.180] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2012 10:05:41 -0000 Received: from [98.138.226.161] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2012 10:05:41 -0000 Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 07 Oct 2012 10:05:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 475427.50282.bm@omp1062.mail.ne1.yahoo.com Received: (qmail 10059 invoked by uid 60001); 7 Oct 2012 10:05:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1349604341; bh=S/9QG52BOr+j6XzLnYcdz9rMkn6l443ks69BZrZ8zTg=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=jZ/e65xPycW4FN0YJZ4uODjG8wzuy/6yPbWrOVuUSJazElJF0felo3zsPH9QPGP8chL8bjxg4ruAOGBOrwLQi0CwAoFQV5e3v++lDgZKlvEQngHQIEG9S2YxYOH271ojs/kLF6NSHlEu48DCacbtLyncF828KIjZZUeoUTLDrno= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=SDRU0Mk/nl/EjcY5bJm5iyqBRpbAb+opgkUML58RH+UCoGKc8FkHBCRXAXa9SKiIsy2jRPLcWvlaKCgyM0GwDdGrysd7Ct4E6xwBdaOwketKIGg6cVOi1FRQH9eJJ2To0sLsfjsrW9BQ9wyE5ZN2ImqjpppXfM1WIRAQQUiZI88=; X-YMail-OSG: 6KiKhd0VM1kQKjlDj_dLhYM22LthoPkQNIs7yCtpeHSLXYD RWijJcHBmPwuzrpp6cwEqZVf7LBLjbsl3LT7M0ZWzGkMK24khiAK8IHzQsl4 mhxY_YS1JNsURxoRmceg_G1Tddf1F69fxTOYYjhQcF5yEjuBjFB0BHjm2dkP 4K8dwoNhOS3fCQrLufYozeqeHPu1xjHbdge60suOoMp0ydU2PovJi_5Hu2hK jKn0NNhm3sru75CNkFV6qQiu_v0dMPNKsoWh9Gtn_LE181RqE4IKab5FgwWM O4qe_tBx30q6XGkNgw.mv2mrX7Xzs37NpSQ3UBisI6.o0fJKCXHfg6zq7pTe ZguqXCM401V.jLx6BOkHAxOF6S8qM4bXym9C0LoHCtXLk7hSRn12TMQ5.W.d 0R6tob3ucvp.CZwmii1gs0mY4pZjubVkFo0ZPCUsOof3u4sSyIergO31Nc5M Kak0c86iT_LysDodRn_DZlxcxiATaLVRV6TnKPaeLMe3uCkJg2vehXj77N.A sGuMoapOq8LAuC5qTn7d_DEwKDfKICe_iksCK5mCsQtH6NZhD1Zj_qzqDUPl YMG3SiFWQH0kInDES.Ap93qB6fiwVvFFtCL80dWdtBxrVUkH_RH0423M_Jw- - Received: from [89.73.195.7] by web125004.mail.ne1.yahoo.com via HTTP; Sun, 07 Oct 2012 03:05:40 PDT X-Mailer: YahooMailWebService/0.8.122.442 Message-ID: <1349604340.9980.BPMail_high_noncarrier@web125004.mail.ne1.yahoo.com> Date: Sun, 7 Oct 2012 03:05:40 -0700 (PDT) From: gayan priyanatha To: hetkith9021@hotmail.com, shanindra@yahoo.com, avrotec@sltnet.lk, gayanyp@yahoo.com, cvs@imasopen.com, manet@ietf.org, cprasadini@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Fw: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:05:53 -0000 http://berlitzuniontokyo.org/service/community.news.php?lucky=jfovazjnrucite From davidgorender@gmail.com Sat Oct 6 21:32:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494C421F8491 for ; Sat, 6 Oct 2012 21:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYlc1NyYpZjI for ; Sat, 6 Oct 2012 21:32:10 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 501B621F8487 for ; Sat, 6 Oct 2012 21:32:10 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1960228wib.13 for ; Sat, 06 Oct 2012 21:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=PE11ZWv8hnaNmuOk4x/LKY9aRXw2OraeR740XM14yT8=; b=FNN8Jiw7cXTUsix+aJIUN+kfZ0KBfC3gNjpOfAv+qP1DEw1yLhWZamP7hOHgbnkipq tbm7gXmtTqFFf74HTp3ijPvKsu5QSzcpVpd8Nqdhj/ICnmC9Evc4063Vuvpmc34v0W/I 0++BbgSieQ4gMin5Xk+IItg7v7q1obcqRx9WbssH3wBMk98m8Cusxkl0YLqhORoMb5RH epxa3Jjd9iJDqM5lxBIFWuMCtx8lyQWRejZsiVPkQcU1EPKiCBY3dyJJ1QyUSjJXwMKr yQyd+tykzkYAAkq/Mh8P3J0jFiyfKGRL+UHuA72edo3VLVaMHToUvDba71z/ygo7b7JF 51Wg== Received: by 10.180.79.34 with SMTP id g2mr12602966wix.19.1349584329140; Sat, 06 Oct 2012 21:32:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.239.74 with HTTP; Sat, 6 Oct 2012 21:31:48 -0700 (PDT) From: David Gorender Date: Sun, 7 Oct 2012 01:31:48 -0300 Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d041825d888680904cb70963e X-Mailman-Approved-At: Sun, 07 Oct 2012 10:56:09 -0700 Subject: [manet] Uses of MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 04:35:44 -0000 --f46d041825d888680904cb70963e Content-Type: text/plain; charset=ISO-8859-1 Hi, My name is David Gorender and I am a graduation student at Federal Univesity of Bahia, Brazil. I don't know if im sending this to the right list, if not, please, give me an orientation about where to send it. Months ago i started to get interested in MANET technology, as well as multicast routing protocol. My question is: is MANET applicable outside the army, army-like enviroments or VANETs? Or even better: can it be used on the regular day to suport applications in some sort of situation? I found very frustrating that the idea of intrinsic trust fail to attend my expectations of generating a MANET public network of any kind. I'm very unmotivated with all this at the moment. =/ --f46d041825d888680904cb70963e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

My name is David Gorender and I am a graduation student at Feder= al Univesity of Bahia, Brazil. I don't know if im sending this to the r= ight list, if not, please, give me an orientation about where to send it. Months ago i started to get interested in MANET technology, as well as mult= icast routing protocol. My question is: is MANET applicable outside the arm= y, army-like enviroments or VANETs? Or even
better: can it be used on th= e regular day to suport applications in some sort of situation?

I found very frustrating that the idea of intrinsic trust fail to atten= d my expectations of generating a MANET public network of any kind.

= I'm very unmotivated with all this at the moment. =3D/
--f46d041825d888680904cb70963e-- From profidz@gmail.com Sun Oct 7 08:46:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FB621F86FC for ; Sun, 7 Oct 2012 08:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iADQ2kueIiuE for ; Sun, 7 Oct 2012 08:46:14 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66C5321F86F7 for ; Sun, 7 Oct 2012 08:46:14 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1149101dan.31 for ; Sun, 07 Oct 2012 08:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vwGdat1c7IfiuvgdIPHxMcxgf7pjjH2ls/Xnf44290k=; b=meGnSTfwqzZqXQidEfDBkrLFJXKFyGzvglRMTgmBL5McuIoBmyBjeR7gLzh49ClLHG K2VwLLcY9/Q26sQsehWJUE/zGFj6Ohi7NjIX1r9A3oi5GuM4mxQJdFpRPnGxsOHtAiu1 EFOElXJLQJDJzUgLoovb33v0FnKRFR2f3Ve8cVhHq6hgZL+r7JgZR0GzWGZnNg8zXaqu N4ov9j+czvkgY5lH8kHnXvCc49BzBJMtO9DtAcr9WH211pcL6p0muQQpRrGgUhdfL3Mt 0fKGsIDkJSTxJGEc9jsaFwiTvRbdOEfcgw7uvEpLTOTsYuDczdoNhxqdLD8nqLWrkfPx 3VNQ== MIME-Version: 1.0 Received: by 10.66.79.69 with SMTP id h5mr36630089pax.12.1349624774123; Sun, 07 Oct 2012 08:46:14 -0700 (PDT) Received: by 10.66.146.161 with HTTP; Sun, 7 Oct 2012 08:46:14 -0700 (PDT) Date: Sun, 7 Oct 2012 23:46:14 +0800 Message-ID: From: hafidz khalili To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d042de5613de24904cb7a0183 X-Mailman-Approved-At: Sun, 07 Oct 2012 10:56:09 -0700 Subject: [manet] how to do a testbed on aodv protocol? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 16:33:00 -0000 --f46d042de5613de24904cb7a0183 Content-Type: text/plain; charset=ISO-8859-1 hello My name hafidz and i'm from malaysia, i want to do a proof of concept on AODV protocol.How can i do this? is there any complete reference/technical report on how to implement AODV step by step? thanks in advance Hafidz --f46d042de5613de24904cb7a0183 Content-Type: text/html; charset=ISO-8859-1 hello

My name hafidz and i'm from malaysia,

i want to do a proof of concept on AODV protocol.How can i do this? is there any complete reference/technical report on how to implement AODV step by step?

thanks in advance

Hafidz
--f46d042de5613de24904cb7a0183-- From hrogge@googlemail.com Sun Oct 7 10:59:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA24921F870F for ; Sun, 7 Oct 2012 10:59:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sggb0fECqGY7 for ; Sun, 7 Oct 2012 10:59:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF41421F8718 for ; Sun, 7 Oct 2012 10:59:40 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3431813pbb.31 for ; Sun, 07 Oct 2012 10:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iSz+WBJKvLkon7mj127vqeVij7KWUlEg0gvDt9nTvM8=; b=Ql+Ohresmor6LX4f+4My8mtLeghqYsR9bpvZrxqUv7RgyRKpkZ+4TVBmpxxd/PcNBf SwSVIDrm+9aG3880jPb2Z+jVJDHR74fVLOVSJecxKptUDoUWICBMDSaI7Rv7c+XudbmV wkB7l5kMWQ1M0++OvZlImIax5a4z1LO5s69r5HMXzDu53OneV2FxzfmgJclVjkf6AqM4 8DJA+exvVkU0jLJ+zk0i8a/pGmaIStFLsO+wMi93SRGUyolSuGjTzLHfFzxyBwClCpQG AJxygtZi77VnJG0Mrqf7ryyl8i5h0BbhY/CZrEE5zK6KGlo2vFeYcdn8kCQHWMcDqJMK kuOQ== Received: by 10.68.202.168 with SMTP id kj8mr46934990pbc.8.1349632780446; Sun, 07 Oct 2012 10:59:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sun, 7 Oct 2012 10:59:20 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sun, 7 Oct 2012 19:59:20 +0200 Message-ID: To: David Gorender Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Uses of MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:59:42 -0000 A lot of MANET protocols are used for Wireless Community Mesh Networks... used by people to build up large scale IP networks all over cities or even (parts of) countries. Henning Rogge On Sun, Oct 7, 2012 at 6:31 AM, David Gorender wrote: > Hi, > > My name is David Gorender and I am a graduation student at Federal Univesity > of Bahia, Brazil. I don't know if im sending this to the right list, if not, > please, give me an orientation about where to send it. > Months ago i started to get interested in MANET technology, as well as > multicast routing protocol. My question is: is MANET applicable outside the > army, army-like enviroments or VANETs? Or even > better: can it be used on the regular day to suport applications in some > sort of situation? > > I found very frustrating that the idea of intrinsic trust fail to attend my > expectations of generating a MANET public network of any kind. > > I'm very unmotivated with all this at the moment. =/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From nataraju.sip@gmail.com Sun Oct 7 11:12:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3F621F86EB for ; Sun, 7 Oct 2012 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrXyfxJVF8+s for ; Sun, 7 Oct 2012 11:12:50 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D20021F86E8 for ; Sun, 7 Oct 2012 11:12:50 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4107801vcb.31 for ; Sun, 07 Oct 2012 11:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TsaJ5zVCEBW/Tv6ZM2Mh3vCm9JEVVM15xGnlidTUUn4=; b=F/1acd6tVCZGHtFKgWynCP0nIkk8ssBxubPC2txRq3kjy5AweqCNKHuqdLb4XWcbrX pAghMd3QW6S77qtqDcygY+Cj35kqGQR9l1lvrJ2FHiHgmf/pMgpTXssc3dRInH+uha5A w202mgAhsSbI/bBoTFpq121V1m5foY/+2uCmIOOEWvP0c4Hn4bHuxxIvmBnXLXhuyhG6 +Stj6+BS/6fqa1KK+umMVDeVHaULeTj2vh8chIHUH0bBBtdLAmjSTeEZ5Ei3+c1mRrUW VFjehuOFsIdrUNqo+S3gG8YkccteJsB8f9JIKngspLEf1kspiTQKxohvIyNNoTBgi7D2 tHrg== MIME-Version: 1.0 Received: by 10.52.34.37 with SMTP id w5mr6848402vdi.86.1349633569900; Sun, 07 Oct 2012 11:12:49 -0700 (PDT) Received: by 10.59.10.72 with HTTP; Sun, 7 Oct 2012 11:12:49 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Oct 2012 23:42:49 +0530 Message-ID: From: "Nataraju A.B" To: hafidz khalili Content-Type: multipart/alternative; boundary=20cf30780cf882c91504cb7c0d73 Cc: manet@ietf.org Subject: Re: [manet] how to do a testbed on aodv protocol? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 18:12:51 -0000 --20cf30780cf882c91504cb7c0d73 Content-Type: text/plain; charset=ISO-8859-1 hafidz, Best place to start understanding AODV or for that matter wireless protocols, is to start with NS-2. you may refer to The Network Simulator - *ns-2* Thanks, Nataraju A B +91-98455-95744 On Sun, Oct 7, 2012 at 9:16 PM, hafidz khalili wrote: > hello > > My name hafidz and i'm from malaysia, > > i want to do a proof of concept on AODV protocol.How can i do this? is > there any complete reference/technical report on how to implement AODV step > by step? > > thanks in advance > > Hafidz > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- Thanks, Nataraju A.B. --20cf30780cf882c91504cb7c0d73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hafidz,=A0

Best place to start understanding AODV or for= that matter wireless protocols, is to start with NS-2.


Thanks,
Nataraju A B
+91-98455-9574= 4

On Sun, Oct 7, 2012 at 9:16 PM, = hafidz khalili <profidz@gmail.com> wrote:
hello

My name hafidz and = i'm from malaysia,

i want to do a proof of con= cept on AODV protocol.How can i do this? is there any complete reference/te= chnical report on how to implement AODV step by step?

thanks in advance

Hafidz

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
= Thanks,
Nataraju A.B.

--20cf30780cf882c91504cb7c0d73-- From boberry@cisco.com Sun Oct 7 16:00:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B581221F86B7 for ; Sun, 7 Oct 2012 16:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx7S3A1kBZc5 for ; Sun, 7 Oct 2012 16:00:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 80DB521F86B4 for ; Sun, 7 Oct 2012 16:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3593; q=dns/txt; s=iport; t=1349650822; x=1350860422; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=gDFY2wIzSDI9yupoACkRjxeMSTGAF9F2lJnCBhyPtDc=; b=YRXpKjkcRvLzVW8E+0ReM1AsG9iXZpaVoyGoeUPN8NJGU9mDvP3xhWgw hAaaJzU8DSddT05eXoLiFuQ6duTx1P35cywYTMFGHEasKAc5UzLwa2s6t Il3iIUvyBTW9OGKtuvh1koWpR5H1SIYTZOE9R1pHC2h4CmwFMnNztW64V w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEIJclCtJXG8/2dsb2JhbABFvyKBCIIgAQEBBBIBJ08LDgouVwYBEiKHY5kNnneLT4UwYAOVa4ViiGOBaYMJ X-IronPort-AV: E=Sophos;i="4.80,549,1344211200"; d="scan'208";a="129148360" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 07 Oct 2012 23:00:20 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-62.cisco.com [10.81.230.62]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q97N0JCb008499; Sun, 7 Oct 2012 23:00:19 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Bo Berry In-Reply-To: <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> Date: Sun, 7 Oct 2012 19:00:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> To: Henning Rogge , Nelson Powell lll , List X-Mailer: Apple Mail (2.1085) Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 23:00:23 -0000 Henning, All, hope everyone had a great weekend.=20 I'll try to highlight the three points in this thread=20 so we do not miss one, and offer a proposal that we can=20 work towards consensus. Relative to the IDs, suggest we remove the Router/Radio IDs to reduce the overhead on every message and leverage the transport/driver. In the case of UDP, we can leverage the src addr/port and dest addr/port for discrimination.=20 Relative to router side discovery, suggest we drop the=20 router side discovery and simplify the discovery process. =20 The router becomes passive (server). The radio is the=20 active node responsible for initiating the discovery=20 process. This would essentially revert back to the=20 original text. Relative to DLEP supporting multiple radios on an interface,=20 suggest DLEP allow for multiple radios on an interface that=20 supports such. Similar to UDP above, DLEP can leverage the src addr/port and dest addr/port information.=20 Thanks -Bo On Oct 5, 2012, at 7:01 AM, Bo Berry wrote: >=20 > On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >=20 >> On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry wrote: >>> Henning >>> Thanks for the feedback. Further discussion below. >>>=20 >>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>> Thats why I suggested increasing the size of the "Radio/Modem ID" = to >>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to = provide >>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>=20 >>> Currently there are two suggestions for the Router/Radio ID fields >>> 1)move the RR-IDs into the DLSP message header >>> 2)expand the fields from 4-byte field currently intended to >>> be a uint32, to 6-bytes so MAC addresses can be used as >>> the unique IDs. >>>=20 >>> Another option, with the new DLEP formatting, is to drop the >>> IDs and use the underlying transport/driver addressing information >>> as the discriminator. This would save 12-bytes plus TLV bytes >>> from every message and the associated processing. >>=20 >> This might be an interesting option for "one line" radios/modems >> (hardware with a single layer-2 interface), similar to the design of >> NHDP where you can drop the THIS_IF TLV if you only have one and the >> src-ip can be used for THIS_IF. >>=20 >> But there are some "multi line" Software Defined Radios, which are >> controlled over a single IP interface. With the current design of = DLEP >> the port number has to be fixed (well known) on both sides of the >> connection, otherwise the "symmetric discovery" doesn't work. I think >> DLEP should allow to have multiple radio instances which can >> communicate to a router over the same IP interface. >=20 > yes, I agree, DLEP should support multiple radios on the same i/f=20 > if that i/f support such. Let us review this aspect. =20 >=20 >>=20 >> Maybe there could be a rule that IF DLEP uses UDP, then the >> combination of IP and port could be used as the ID of the router. Of >> course this means that the ID becomes a 16 or 18 byte string for = IPv6. >>=20 >> (I am still not convinced that allowing the router to play the active >> discovery part is a good idea, this can lead to all kinds of trouble >> including non-dlep aware radios suddenly sending DLEP-discovery >> beacons of the router over the air). Agree, the router side discovery can be removed.=20 > ~~~cut --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From teco@inf-net.nl Sun Oct 7 22:43:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA8321F859A for ; Sun, 7 Oct 2012 22:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7cy-8wCIVcQ for ; Sun, 7 Oct 2012 22:43:31 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 541AD21F8595 for ; Sun, 7 Oct 2012 22:43:30 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1744810bkc.31 for ; Sun, 07 Oct 2012 22:43:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=I5Gq/j75o742Hoz2ZNfQXgOSK8LaIlqVV6ykr0xzc0Q=; b=QzAp4475SoH/2uxZ6WYqaPMBA10KlXnohr7yIUVyvq9G3klF04gTFW21hAE7499a2m 0cHlSTnAoSYH5ieCGgNm2eMO1pWr8dV/UCqU/xJ51Ne52QaCQKpdxIZ4Abw8YOyg2qNT IOaF8w7UU9O+9r9Oza4mhGlW9bhsddD6JKV4w1Sk26RodQI1fQgHJ4GaxbiygvaPb9db j9g9Ik3/P5ra6vs6+GnUK31o+gqCIaGjrAzeoo+cYVgCVIXm9v6PHKhqJ9P0jaE++w0E 7IRLLkDiWcRicaef5mhjj0Pg7smYclXA0MyS9n/ca7IS+yXu6i5HgH6CLAEjD+M7J1os Bdwg== Received: by 10.204.13.25 with SMTP id z25mr4938557bkz.119.1349675009489; Sun, 07 Oct 2012 22:43:29 -0700 (PDT) Received: from [10.87.57.57] ([80.187.201.33]) by mx.google.com with ESMTPS id k21sm11189273bkv.1.2012.10.07.22.43.22 (version=SSLv3 cipher=OTHER); Sun, 07 Oct 2012 22:43:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Mon, 8 Oct 2012 07:43:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnHbCGvjliEyrrAW91xi0LmT5SuQNG8z6sEkp9UJmusa11/AMpWeagE+xuCamCJYZpHXpVQ Cc: List Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 05:43:32 -0000 Op 8 okt. 2012, om 01:00 heeft Bo Berry het volgende geschreven: > Henning, All, hope everyone had a great weekend.=20 I did :-) >=20 > I'll try to highlight the three points in this thread=20 > so we do not miss one, and offer a proposal that we can=20 > work towards consensus. There are more topics in this thread. Please check my 1st=20 posting, or summary below. Good idea to use the ticketing system? >=20 > Relative to the IDs, suggest we remove the Router/Radio IDs > to reduce the overhead on every message and leverage the > transport/driver. In the case of UDP, we can leverage the > src addr/port and dest addr/port for discrimination. For the DLEP session, source address would be OK, I think. This is more or less how IP works. For the remote router, I still think a MAC address would be the best choice. 6-byte ID field is OK. >=20 > Relative to router side discovery, suggest we drop the=20 > router side discovery and simplify the discovery process. =20 > The router becomes passive (server). The radio is the=20 > active node responsible for initiating the discovery=20 > process. This would essentially revert back to the=20 > original text. With radio sending data with refresh interval and validity time, there is no need for discovery.=20 Or as alternative: radio sends announcements, and router=20 asks for more. >=20 > Relative to DLEP supporting multiple radios on an interface,=20 > suggest DLEP allow for multiple radios on an interface that=20 > supports such. Similar to UDP above, DLEP can leverage > the src addr/port and dest addr/port information. I didn't get the need for addr/port. Maybe because I don't get the reason for the complexity in the current protocol. Why can't the radio not just send out the data? And allow multiple radio's and multiple routers on same link? Multiple radio's, with links to same destination, could be a sub-IP problem. Other scenario's are OK. Other comments I posted, where you did not respond before: - please add change log - terminology radio, modem, server and participant for same object is not as clear as it could be. Please reduce to one or two. - please specify transport protocol, so we make sure implementations are compatible - please add OLSRv2 compliant dimensionless metric, and make this one mandatory. Rest can be optional. - please split the draft and remove in the proposed=20 standard document only the elements that requires a new protocol. Much of what is in current draft overlaps what we have today already. - please remove the reliable protocol function and use validity time, as for example NHDP/OLSR. If not, ACKs are mandatory. And there is a lot more to specify a=20 reliable protocol. Therefore I suggest TCP for a reliable unicast connection. And there is the RFC 5444 discussion. Teco >=20 >=20 > Thanks > -Bo >=20 >=20 > On Oct 5, 2012, at 7:01 AM, Bo Berry wrote: >>=20 >> On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >>=20 >>> On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry wrote: >>>> Henning >>>> Thanks for the feedback. Further discussion below. >>>>=20 >>>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>>> Thats why I suggested increasing the size of the "Radio/Modem ID" = to >>>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to = provide >>>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>>=20 >>>> Currently there are two suggestions for the Router/Radio ID fields >>>> 1)move the RR-IDs into the DLSP message header >>>> 2)expand the fields from 4-byte field currently intended to >>>> be a uint32, to 6-bytes so MAC addresses can be used as >>>> the unique IDs. >>>>=20 >>>> Another option, with the new DLEP formatting, is to drop the >>>> IDs and use the underlying transport/driver addressing information >>>> as the discriminator. This would save 12-bytes plus TLV bytes >>>> from every message and the associated processing. >>>=20 >>> This might be an interesting option for "one line" radios/modems >>> (hardware with a single layer-2 interface), similar to the design of >>> NHDP where you can drop the THIS_IF TLV if you only have one and the >>> src-ip can be used for THIS_IF. >>>=20 >>> But there are some "multi line" Software Defined Radios, which are >>> controlled over a single IP interface. With the current design of = DLEP >>> the port number has to be fixed (well known) on both sides of the >>> connection, otherwise the "symmetric discovery" doesn't work. I = think >>> DLEP should allow to have multiple radio instances which can >>> communicate to a router over the same IP interface. >>=20 >> yes, I agree, DLEP should support multiple radios on the same i/f=20 >> if that i/f support such. Let us review this aspect. =20 >>=20 >>>=20 >>> Maybe there could be a rule that IF DLEP uses UDP, then the >>> combination of IP and port could be used as the ID of the router. Of >>> course this means that the ID becomes a 16 or 18 byte string for = IPv6. >>>=20 >>> (I am still not convinced that allowing the router to play the = active >>> discovery part is a good idea, this can lead to all kinds of trouble >>> including non-dlep aware radios suddenly sending DLEP-discovery >>> beacons of the router over the air). >=20 > Agree, the router side discovery can be removed.=20 >=20 >=20 >> ~~~cut >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Mon Oct 8 02:05:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A5D21F8753 for ; Mon, 8 Oct 2012 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv92QRhtu2qq for ; Mon, 8 Oct 2012 02:05:53 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD4B21F8759 for ; Mon, 8 Oct 2012 02:05:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,551,1344207600"; d="scan'208";a="276553115" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Oct 2012 10:05:52 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9895pJh023258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 10:05:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Mon, 8 Oct 2012 10:05:51 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , David Gorender Thread-Topic: [manet] Uses of MANET Thread-Index: AQHNpLUM40Px2t9kMkC5TTlIA5rcy5euEMUAgAENp1A= Date: Mon, 8 Oct 2012 09:05:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Uses of MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 09:05:54 -0000 Many people have considered MANETs in disaster situations. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 07 October 2012 18:59 To: David Gorender Cc: manet@ietf.org Subject: Re: [manet] Uses of MANET ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- A lot of MANET protocols are used for Wireless Community Mesh Networks... used by people to build up large scale IP networks all over cities or even (parts of) countries. Henning Rogge On Sun, Oct 7, 2012 at 6:31 AM, David Gorender wr= ote: > Hi, > > My name is David Gorender and I am a graduation student at Federal Unives= ity > of Bahia, Brazil. I don't know if im sending this to the right list, if n= ot, > please, give me an orientation about where to send it. > Months ago i started to get interested in MANET technology, as well as > multicast routing protocol. My question is: is MANET applicable outside t= he > army, army-like enviroments or VANETs? Or even > better: can it be used on the regular day to suport applications in some > sort of situation? > > I found very frustrating that the idea of intrinsic trust fail to attend = my > expectations of generating a MANET public network of any kind. > > I'm very unmotivated with all this at the moment. =3D/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From philippe.jacquet@inria.fr Mon Oct 8 02:06:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B7221F875B for ; Mon, 8 Oct 2012 02:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpueEszmIvPg for ; Mon, 8 Oct 2012 02:06:47 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 67FF321F8753 for ; Mon, 8 Oct 2012 02:06:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,551,1344204000"; d="scan'208";a="176226538" Received: from zmbs5.inria.fr ([128.93.142.18]) by mail1-relais-roc.national.inria.fr with ESMTP; 08 Oct 2012 11:06:46 +0200 Date: Mon, 8 Oct 2012 11:06:46 +0200 (CEST) From: Philippe Jacquet To: David Gorender Message-ID: <936229623.6783090.1349687205959.JavaMail.root@inria.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [64.208.49.214] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - SAF3 (Mac)/7.2.0_GA_2669) Cc: manet@ietf.org Subject: Re: [manet] Uses of MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 09:06:49 -0000 Yes, it can be used, and is used, outside military or VANET framework, but = I don't know if it answers your "unmotivations"... Philippe=20 ----- Mail original ----- De: "David Gorender" =C0: manet@ietf.org Envoy=E9: Dimanche 7 Octobre 2012 06:31:48 Objet: [manet] Uses of MANET Hi, My name is David Gorender and I am a graduation student at Federal Univesity of Bahia, Brazil. I don't know if im sending this to the right list, if not, please, give me an orientation about where to send it. Months ago i started to get interested in MANET technology, as well as multicast routing protocol. My question is: is MANET applicable outside the army, army-like enviroments or VANETs? Or even better: can it be used on the regular day to suport applications in some sort of situation? I found very frustrating that the idea of intrinsic trust fail to attend my expectations of generating a MANET public network of any kind. I'm very unmotivated with all this at the moment. =3D/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Mon Oct 8 02:19:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F4421F855B for ; Mon, 8 Oct 2012 02:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HybVuR+xhhVF for ; Mon, 8 Oct 2012 02:19:38 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE2121F8582 for ; Mon, 8 Oct 2012 02:19:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,551,1344207600"; d="scan'208";a="276560459" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Oct 2012 10:19:28 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q989JRfi001053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 10:19:27 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Mon, 8 Oct 2012 10:19:27 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot , Bo Berry Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlA= Date: Mon, 8 Oct 2012 09:19:27 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 09:19:39 -0000 Teco > And there is the RFC 5444 discussion. I think that, the draft being where it is, it's appropriate for anyone sayi= ng it should be 5444 to propose concretely how (I think we are agreed not t= he previous version) and why that is an improvement. Note that I'm not argu= ing one way or the other. Note that the WG mandate to use 5444 applies to p= rotocols using the manet protocol/port, not protocols developed by the WG. = If the protocol is an AHRP the presumption is that it should use that proto= col/port, but that doesn't apply to DLEP. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Oct 8 03:54:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2BC21F8549 for ; Mon, 8 Oct 2012 03:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECpuggzKWfdw for ; Mon, 8 Oct 2012 03:54:40 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6B221F8679 for ; Mon, 8 Oct 2012 03:54:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,551,1344207600"; d="scan'208";a="276603028" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Oct 2012 11:54:34 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q98ArGAv006871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 11:54:32 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Mon, 8 Oct 2012 11:54:28 +0100 From: "Dearlove, Christopher (UK)" To: "Taylor, Rick" , Teco Boot , Bo Berry Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAABaa0IAAAwqw Date: Mon, 8 Oct 2012 10:54:27 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net><39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com><9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 10:54:42 -0000 5444 is a solution (I won't comment on how good a solution, as I'm not neut= ral) to the basic problem of how to flexibly associate pieces of informatio= n with addresses (that are assumed to identify something, typically another= router in a network) plus to include some flexible information not associa= ted with addresses. If you want to do this (flexibly include pieces of information in this way,= some associated with addresses - which actually means any size identifiers= ) then 5444 is a possibly way to format such information, with advantages a= nd disadvantages. If you want to carry information not of that form you can= of course do it (you can carry almost anything, within the size limits) bu= t it will have more disadvantages and fewer advantages. So 5444 for DLEP (which I'm neither advocating for or against) would need t= o be set against that, one or more candidates produced, and pros and cons a= ssessed. As I've said, the onus at this point must be on a proponent, if an= y, to do so. I don't think any actual worked out good candidate was ever published here,= only pieces of one. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Taylor, Rick [mailto:Rick.Taylor@cassidian.com]=20 Sent: 08 October 2012 11:43 To: Dearlove, Christopher (UK); Teco Boot; Bo Berry Cc: List Subject: RE: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Teco, With the greatest respect, I can't see how 5444 is applicable to DLEP. Yes, it is possible to reshape the DLEP protocol into 5444, but it reduces = the clarity of the protocol as it is transformed. But more importantly, DLEP is not intended to travel over the network. It = is link-local by design. Any communication between devices required to pro= vide state for a DLEP implementation might use a 5444 formatted protocol, b= ut as Stan so elegantly says, that's just 'radio magic' and is a layer hidd= en from DLEP. DLEP describes the link-local communication between a router and some modem= s. It should be formatted to maximize A) Clarity and correctness, B) Ease = of implementation. Efficient on the wire representation is not a requireme= nt. I previously had an extended exchange with Henning on this list, and betwee= n us we managed to fit DLEP-00 into RFC5444 in several ways. But the more = I consider it, the more I must conclude that we were solving the wrong prob= lem. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Dearlove, Christopher (UK) > Sent: 08 October 2012 10:19 > To: Teco Boot; Bo Berry > Cc: List > Subject: Re: [manet] Some comments on manet-dlep-03 > > > Teco > > And there is the RFC 5444 discussion. > > I think that, the draft being where it is, it's appropriate for anyone > saying it should be 5444 to propose concretely how (I think we are agreed > not the previous version) and why that is an improvement. Note that I'm > not arguing one way or the other. Note that the WG mandate to use 5444 > applies to protocols using the manet protocol/port, not protocols > developed by the WG. If the protocol is an AHRP the presumption is that i= t > should use that protocol/port, but that doesn't apply to DLEP. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From boberry@cisco.com Mon Oct 8 04:09:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EC621F867E for ; Mon, 8 Oct 2012 04:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugzUrcz3q9dl for ; Mon, 8 Oct 2012 04:09:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1434421F8653 for ; Mon, 8 Oct 2012 04:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6825; q=dns/txt; s=iport; t=1349694589; x=1350904189; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tDPKCaEPlDjVil+/6rLYWyYh02ovrlEIpGfslnpWQTk=; b=hcCpLsR7oOk53COabaMls0sbO+qr94HhJygOltWdpLHm6kBBobO0jkeV 2wcu932Kug62Gmg6FrAbXy08vMey/+TW72eRmeMQsE5sHuhfFCQrICBYp dWl5+J82k2r4HMC5J6EihXK7CgXgw00irS49bJkBYHO9Ow8xV6/FgkEBW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABi0clCtJXHB/2dsb2JhbAA7Cr8kgQiCIAEBAQMBAQEBDwEnGxkDCAUHBAsRBAEBKAcnHwkIBhECGweHXQYLmUWfKotPEAQGCIUOYAOVa4ViiGOBaYMJIoEcCQ X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="129291298" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 08 Oct 2012 11:09:46 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-57.cisco.com [10.81.230.57]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q98B9j7W029176; Mon, 8 Oct 2012 11:09:45 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Mon, 8 Oct 2012 07:09:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01793004-53CD-4842-A0AA-723B117C83F5@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net><39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com><9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1085) Cc: List Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:09:50 -0000 DLEP started with 5444 but ran into problems getting closure IP/MAC TLVs that were defined, and we could not get changes to 5444. Hence discussion lead to the simplier, standard TLV draft, as I understand=20 things. =46rom my perspective, I like the using standard TLVs. -Bo On Oct 8, 2012, at 6:54 AM, Dearlove, Christopher (UK) wrote: > 5444 is a solution (I won't comment on how good a solution, as I'm not = neutral) to the basic problem of how to flexibly associate pieces of = information with addresses (that are assumed to identify something, = typically another router in a network) plus to include some flexible = information not associated with addresses. >=20 > If you want to do this (flexibly include pieces of information in this = way, some associated with addresses - which actually means any size = identifiers) then 5444 is a possibly way to format such information, = with advantages and disadvantages. If you want to carry information not = of that form you can of course do it (you can carry almost anything, = within the size limits) but it will have more disadvantages and fewer = advantages. >=20 > So 5444 for DLEP (which I'm neither advocating for or against) would = need to be set against that, one or more candidates produced, and pros = and cons assessed. As I've said, the onus at this point must be on a = proponent, if any, to do so. >=20 > I don't think any actual worked out good candidate was ever published = here, only pieces of one. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Taylor, Rick [mailto:Rick.Taylor@cassidian.com]=20 > Sent: 08 October 2012 11:43 > To: Dearlove, Christopher (UK); Teco Boot; Bo Berry > Cc: List > Subject: RE: [manet] Some comments on manet-dlep-03 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Teco, >=20 > With the greatest respect, I can't see how 5444 is applicable to DLEP. >=20 > Yes, it is possible to reshape the DLEP protocol into 5444, but it = reduces the clarity of the protocol as it is transformed. >=20 > But more importantly, DLEP is not intended to travel over the network. = It is link-local by design. Any communication between devices required = to provide state for a DLEP implementation might use a 5444 formatted = protocol, but as Stan so elegantly says, that's just 'radio magic' and = is a layer hidden from DLEP. >=20 > DLEP describes the link-local communication between a router and some = modems. It should be formatted to maximize A) Clarity and correctness, = B) Ease of implementation. Efficient on the wire representation is not = a requirement. >=20 > I previously had an extended exchange with Henning on this list, and = between us we managed to fit DLEP-00 into RFC5444 in several ways. But = the more I consider it, the more I must conclude that we were solving = the wrong problem. >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Dearlove, Christopher (UK) >> Sent: 08 October 2012 10:19 >> To: Teco Boot; Bo Berry >> Cc: List >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >>=20 >> Teco >>> And there is the RFC 5444 discussion. >>=20 >> I think that, the draft being where it is, it's appropriate for = anyone >> saying it should be 5444 to propose concretely how (I think we are = agreed >> not the previous version) and why that is an improvement. Note that = I'm >> not arguing one way or the other. Note that the WG mandate to use = 5444 >> applies to protocols using the manet protocol/port, not protocols >> developed by the WG. If the protocol is an AHRP the presumption is = that it >> should use that protocol/port, but that doesn't apply to DLEP. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to = this e-mail is private and in addition may include commercially = sensitive information. The contents of this e-mail are for the intended = recipient only and therefore if you wish to disclose the information = contained within this e-mail or attached files, please contact the = sender prior to any such disclosure. If you are not the intended = recipient, any disclosure, copying or distribution is prohibited. Please = also contact the sender and inform them of the error and delete the = e-mail, including any attached files from your system. Cassidian = Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, = Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From boberry@cisco.com Mon Oct 8 04:23:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74E121F8754 for ; Mon, 8 Oct 2012 04:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0-bTZIloty5 for ; Mon, 8 Oct 2012 04:23:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E874221F86B7 for ; Mon, 8 Oct 2012 04:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6458; q=dns/txt; s=iport; t=1349695403; x=1350905003; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ccdk3eu1FWxwsRveq/HLL/DIl115EM4qzbY8cCNDJTI=; b=kFVDZ91C3EU8Cy4ESNx77PslTjnuKSS0PX8iD9N9QmPJg5iOGJUdIgD0 2fWUtiBONtf2bmwmFgcEtVPiE7lOzOYweaT7UEvhjiu6ogconV1dY4kHI gThKzraMPX5lYQSLyPXMdRdgdCABYR+JgHqD3W9Dsbu/CKdIoyIyVH3ct 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGy2clCtJXG8/2dsb2JhbABFvySBCIIgAQEBAwEBAQEPASc0CxALGC4nMAYTIoddBguZQJ8nBItPJIUMYAOVa4ViiGOBaYMJgT4H X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="129294626" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 08 Oct 2012 11:23:22 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-57.cisco.com [10.81.230.57]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q98BNL6P025939; Mon, 8 Oct 2012 11:23:21 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Mon, 8 Oct 2012 07:23:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <303D7687-77D9-4409-9016-E0EB60599C5A@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> To: Teco Boot X-Mailer: Apple Mail (2.1085) Cc: List Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:23:24 -0000 Teco On Oct 8, 2012, at 1:43 AM, Teco Boot wrote: >=20 > Op 8 okt. 2012, om 01:00 heeft Bo Berry het volgende geschreven: >=20 >> Henning, All, hope everyone had a great weekend.=20 > I did :-) >=20 >>=20 >> I'll try to highlight the three points in this thread=20 >> so we do not miss one, and offer a proposal that we can=20 >> work towards consensus. > There are more topics in this thread. Please check my 1st=20 > posting, or summary below. >=20 > Good idea to use the ticketing system? after last week, simply making an effort to start fresh with the items in my thread, not implying these are all topics.=20 Trust that is OK with you, everyone. Thanks for your comments and other suggestions below, they=20 have helped the discussion as evident by the threads. >=20 >>=20 >> Relative to the IDs, suggest we remove the Router/Radio IDs >> to reduce the overhead on every message and leverage the >> transport/driver. In the case of UDP, we can leverage the >> src addr/port and dest addr/port for discrimination. > For the DLEP session, source address would be OK, I think. > This is more or less how IP works. >=20 > For the remote router, I still think a MAC address would be > the best choice. 6-byte ID field is OK. >=20 >>=20 >> Relative to router side discovery, suggest we drop the=20 >> router side discovery and simplify the discovery process. =20 >> The router becomes passive (server). The radio is the=20 >> active node responsible for initiating the discovery=20 >> process. This would essentially revert back to the=20 >> original text. > With radio sending data with refresh interval and validity > time, there is no need for discovery.=20 >=20 > Or as alternative: radio sends announcements, and router=20 > asks for more. >=20 >>=20 >> Relative to DLEP supporting multiple radios on an interface,=20 >> suggest DLEP allow for multiple radios on an interface that=20 >> supports such. Similar to UDP above, DLEP can leverage >> the src addr/port and dest addr/port information. > I didn't get the need for addr/port. Maybe because I don't > get the reason for the complexity in the current protocol. > Why can't the radio not just send out the data? And allow > multiple radio's and multiple routers on same link? > Multiple radio's, with links to same destination, could be > a sub-IP problem. Other scenario's are OK. >=20 >=20 > Other comments I posted, where you did not respond before: > - please add change log > - terminology radio, modem, server and participant for > same object is not as clear as it could be. Please > reduce to one or two. > - please specify transport protocol, so we make sure > implementations are compatible > - please add OLSRv2 compliant dimensionless metric, > and make this one mandatory. Rest can be optional. > - please split the draft and remove in the proposed=20 > standard document only the elements that requires a > new protocol. Much of what is in current draft overlaps > what we have today already. > - please remove the reliable protocol function and use > validity time, as for example NHDP/OLSR. If not, ACKs > are mandatory. And there is a lot more to specify a=20 > reliable protocol. Therefore I suggest TCP for a > reliable unicast connection. > And there is the RFC 5444 discussion. >=20 > Teco >=20 >>=20 >>=20 >> Thanks >> -Bo >>=20 >>=20 >> On Oct 5, 2012, at 7:01 AM, Bo Berry wrote: >>>=20 >>> On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >>>=20 >>>> On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry = wrote: >>>>> Henning >>>>> Thanks for the feedback. Further discussion below. >>>>>=20 >>>>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>>>> Thats why I suggested increasing the size of the "Radio/Modem ID" = to >>>>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to = provide >>>>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>>>=20 >>>>> Currently there are two suggestions for the Router/Radio ID fields >>>>> 1)move the RR-IDs into the DLSP message header >>>>> 2)expand the fields from 4-byte field currently intended to >>>>> be a uint32, to 6-bytes so MAC addresses can be used as >>>>> the unique IDs. >>>>>=20 >>>>> Another option, with the new DLEP formatting, is to drop the >>>>> IDs and use the underlying transport/driver addressing information >>>>> as the discriminator. This would save 12-bytes plus TLV bytes >>>>> from every message and the associated processing. >>>>=20 >>>> This might be an interesting option for "one line" radios/modems >>>> (hardware with a single layer-2 interface), similar to the design = of >>>> NHDP where you can drop the THIS_IF TLV if you only have one and = the >>>> src-ip can be used for THIS_IF. >>>>=20 >>>> But there are some "multi line" Software Defined Radios, which are >>>> controlled over a single IP interface. With the current design of = DLEP >>>> the port number has to be fixed (well known) on both sides of the >>>> connection, otherwise the "symmetric discovery" doesn't work. I = think >>>> DLEP should allow to have multiple radio instances which can >>>> communicate to a router over the same IP interface. >>>=20 >>> yes, I agree, DLEP should support multiple radios on the same i/f=20 >>> if that i/f support such. Let us review this aspect. =20 >>>=20 >>>>=20 >>>> Maybe there could be a rule that IF DLEP uses UDP, then the >>>> combination of IP and port could be used as the ID of the router. = Of >>>> course this means that the ID becomes a 16 or 18 byte string for = IPv6. >>>>=20 >>>> (I am still not convinced that allowing the router to play the = active >>>> discovery part is a good idea, this can lead to all kinds of = trouble >>>> including non-dlep aware radios suddenly sending DLEP-discovery >>>> beacons of the router over the air). >>=20 >> Agree, the router side discovery can be removed.=20 >>=20 >>=20 >>> ~~~cut >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we = created them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From boberry@cisco.com Mon Oct 8 04:24:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59A021F85C3 for ; Mon, 8 Oct 2012 04:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2zugUyLPs5U for ; Mon, 8 Oct 2012 04:24:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 565BA21F8732 for ; Mon, 8 Oct 2012 04:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8275; q=dns/txt; s=iport; t=1349695444; x=1350905044; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=q3u5Iri9Rx4XZH3AJtiTgCZoH4F+MpxL6r8pii0xv6w=; b=Ppt55xDZaqyvDUfzbBSILDxQTqH3Q0fWsm5CufMnJjRhSGS8bCqeDdQ1 vV93hwHCxfQlTxJrZ1BJDNTTnVKw5q9nj6c/zZaaQ+SKEL0n0UbOk4NPK cuCI1XwDLp9kh264Pq5ik/agLyEGFku9F5tQ+UD+k8daOoWFsQfvxHy3/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJq2clCtJXG8/2dsb2JhbABFvySBCIIgAQEBAwEBAQEPAScbGQsFBwQLEQQBAQEnBycfCQgGEyKHXQYLmUOfK4tPFAYKhQxgA5VrhWKIY4FpgwmBPgk X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="129293768" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 08 Oct 2012 11:24:03 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-57.cisco.com [10.81.230.57]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q98BNL6Q025939; Mon, 8 Oct 2012 11:24:03 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Mon, 8 Oct 2012 07:24:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C5C3EBA-7FE3-4C96-B6C4-66C7634F8547@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net><39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com><9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> To: "Taylor, Rick" X-Mailer: Apple Mail (2.1085) Cc: List Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:24:05 -0000 On Oct 8, 2012, at 6:52 AM, Taylor, Rick wrote: > Teco, >=20 > Sorry, I am catching up on the MANET backlog... >=20 > I really don't want to see an OLSRv2 compliant dimensionless metric in = DLEP. agree >=20 > My understanding of one of the purposes of DLEP is to provide hard, = measured metrics to routers from modems. If an OLSRv2 implementation = wishes to use a DLEP module to reduce the available metrics provided by = modems to a metric for its own use then that is fine, but there are = other consumers of DLEP metrics who have no need of the OLSRv2 metric. >=20 > As a counter-argument: why shouldn't DLEP report an OSPF hop-count? >=20 > I am not a radio-engineer, but from my perspective DLEP should present = metrics that generically cover: Latency, Bandwidth, Reliability, = Availability and Congestion. agree >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Teco Boot >> Sent: 08 October 2012 06:43 >> To: Bo Berry >> Cc: List >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >>=20 >>=20 >> Op 8 okt. 2012, om 01:00 heeft Bo Berry het volgende geschreven: >>=20 >>> Henning, All, hope everyone had a great weekend. >> I did :-) >>=20 >>>=20 >>> I'll try to highlight the three points in this thread >>> so we do not miss one, and offer a proposal that we can >>> work towards consensus. >> There are more topics in this thread. Please check my 1st >> posting, or summary below. >>=20 >> Good idea to use the ticketing system? >>=20 >>>=20 >>> Relative to the IDs, suggest we remove the Router/Radio IDs >>> to reduce the overhead on every message and leverage the >>> transport/driver. In the case of UDP, we can leverage the >>> src addr/port and dest addr/port for discrimination. >> For the DLEP session, source address would be OK, I think. >> This is more or less how IP works. >>=20 >> For the remote router, I still think a MAC address would be >> the best choice. 6-byte ID field is OK. >>=20 >>>=20 >>> Relative to router side discovery, suggest we drop the >>> router side discovery and simplify the discovery process. >>> The router becomes passive (server). The radio is the >>> active node responsible for initiating the discovery >>> process. This would essentially revert back to the >>> original text. >> With radio sending data with refresh interval and validity >> time, there is no need for discovery. >>=20 >> Or as alternative: radio sends announcements, and router >> asks for more. >>=20 >>>=20 >>> Relative to DLEP supporting multiple radios on an interface, >>> suggest DLEP allow for multiple radios on an interface that >>> supports such. Similar to UDP above, DLEP can leverage >>> the src addr/port and dest addr/port information. >> I didn't get the need for addr/port. Maybe because I don't >> get the reason for the complexity in the current protocol. >> Why can't the radio not just send out the data? And allow >> multiple radio's and multiple routers on same link? >> Multiple radio's, with links to same destination, could be >> a sub-IP problem. Other scenario's are OK. >>=20 >>=20 >> Other comments I posted, where you did not respond before: >> - please add change log >> - terminology radio, modem, server and participant for >> same object is not as clear as it could be. Please >> reduce to one or two. >> - please specify transport protocol, so we make sure >> implementations are compatible >> - please add OLSRv2 compliant dimensionless metric, >> and make this one mandatory. Rest can be optional. >> - please split the draft and remove in the proposed >> standard document only the elements that requires a >> new protocol. Much of what is in current draft overlaps >> what we have today already. >> - please remove the reliable protocol function and use >> validity time, as for example NHDP/OLSR. If not, ACKs >> are mandatory. And there is a lot more to specify a >> reliable protocol. Therefore I suggest TCP for a >> reliable unicast connection. >> And there is the RFC 5444 discussion. >>=20 >> Teco >>=20 >>>=20 >>>=20 >>> Thanks >>> -Bo >>>=20 >>>=20 >>> On Oct 5, 2012, at 7:01 AM, Bo Berry wrote: >>>>=20 >>>> On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote: >>>>=20 >>>>> On Thu, Oct 4, 2012 at 11:31 PM, Bo Berry = wrote: >>>>>> Henning >>>>>> Thanks for the feedback. Further discussion below. >>>>>>=20 >>>>>> On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote: >>>>>>> Thats why I suggested increasing the size of the "Radio/Modem = ID" to >>>>>>> six bytes. This ALLOWS the Radio/Modem to use a MAC address to >> provide >>>>>>> an unique idea, but it doesn't make it mandatory to use a MAC. >>>>>>=20 >>>>>> Currently there are two suggestions for the Router/Radio ID = fields >>>>>> 1)move the RR-IDs into the DLSP message header >>>>>> 2)expand the fields from 4-byte field currently intended to >>>>>> be a uint32, to 6-bytes so MAC addresses can be used as >>>>>> the unique IDs. >>>>>>=20 >>>>>> Another option, with the new DLEP formatting, is to drop the >>>>>> IDs and use the underlying transport/driver addressing = information >>>>>> as the discriminator. This would save 12-bytes plus TLV bytes >>>>>> from every message and the associated processing. >>>>>=20 >>>>> This might be an interesting option for "one line" radios/modems >>>>> (hardware with a single layer-2 interface), similar to the design = of >>>>> NHDP where you can drop the THIS_IF TLV if you only have one and = the >>>>> src-ip can be used for THIS_IF. >>>>>=20 >>>>> But there are some "multi line" Software Defined Radios, which are >>>>> controlled over a single IP interface. With the current design of = DLEP >>>>> the port number has to be fixed (well known) on both sides of the >>>>> connection, otherwise the "symmetric discovery" doesn't work. I = think >>>>> DLEP should allow to have multiple radio instances which can >>>>> communicate to a router over the same IP interface. >>>>=20 >>>> yes, I agree, DLEP should support multiple radios on the same i/f >>>> if that i/f support such. Let us review this aspect. >>>>=20 >>>>>=20 >>>>> Maybe there could be a rule that IF DLEP uses UDP, then the >>>>> combination of IP and port could be used as the ID of the router. = Of >>>>> course this means that the ID becomes a 16 or 18 byte string for = IPv6. >>>>>=20 >>>>> (I am still not convinced that allowing the router to play the = active >>>>> discovery part is a good idea, this can lead to all kinds of = trouble >>>>> including non-dlep aware radios suddenly sending DLEP-discovery >>>>> beacons of the router over the air). >>>=20 >>> Agree, the router side discovery can be removed. >>>=20 >>>=20 >>>> ~~~cut >>>=20 >>> --- >>> We cannot solve our problems with the same thinking we used when we >> created them. >>> Albert Einstein >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to = this e-mail is private and in addition may include commercially = sensitive information. The contents of this e-mail are for the intended = recipient only and therefore if you wish to disclose the information = contained within this e-mail or attached files, please contact the = sender prior to any such disclosure. If you are not the intended = recipient, any disclosure, copying or distribution is prohibited. Please = also contact the sender and inform them of the error and delete the = e-mail, including any attached files from your system. Cassidian = Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, = Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From Chris.Dearlove@baesystems.com Mon Oct 8 05:35:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991E121F8522 for ; Mon, 8 Oct 2012 05:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciSIlvIPcQ-R for ; Mon, 8 Oct 2012 05:35:43 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 112FC21F874A for ; Mon, 8 Oct 2012 05:35:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,554,1344207600"; d="scan'208";a="276644120" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Oct 2012 13:35:36 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q98CZYjj016466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 13:35:35 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Mon, 8 Oct 2012 13:35:34 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAABaa0IAAAwqw///194CAACegEA== Date: Mon, 8 Oct 2012 12:35:34 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net><39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com><9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <01793004-53CD-4842-A0AA-723B117C83F5@cisco.com> In-Reply-To: <01793004-53CD-4842-A0AA-723B117C83F5@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 12:35:44 -0000 While, as I have said, I'm not arguing for or against use of 5444, I think = that when it was being discussed it was clear that MAC address should be th= e address type indexed against, which 5444 supports, and IP addresses then = needed a TLV. Getting TLVs does not require a change to 5444. (Getting an I= P-address carrying TLV might run into disagreements over e.g. to compress = or not to compress, but that's another story.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Bo Berry [mailto:boberry@cisco.com]=20 Sent: 08 October 2012 12:10 To: Dearlove, Christopher (UK) Cc: Taylor, Rick; Teco Boot; List Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- DLEP started with 5444 but ran into problems getting closure IP/MAC TLVs that were defined, and we could not get changes to 5444. Hence discussion lead to the simplier, standard TLV draft, as I understand=20 things. From my perspective, I like the using standard TLVs. -Bo On Oct 8, 2012, at 6:54 AM, Dearlove, Christopher (UK) wrote: > 5444 is a solution (I won't comment on how good a solution, as I'm not ne= utral) to the basic problem of how to flexibly associate pieces of informat= ion with addresses (that are assumed to identify something, typically anoth= er router in a network) plus to include some flexible information not assoc= iated with addresses. >=20 > If you want to do this (flexibly include pieces of information in this wa= y, some associated with addresses - which actually means any size identifie= rs) then 5444 is a possibly way to format such information, with advantages= and disadvantages. If you want to carry information not of that form you c= an of course do it (you can carry almost anything, within the size limits) = but it will have more disadvantages and fewer advantages. >=20 > So 5444 for DLEP (which I'm neither advocating for or against) would need= to be set against that, one or more candidates produced, and pros and cons= assessed. As I've said, the onus at this point must be on a proponent, if = any, to do so. >=20 > I don't think any actual worked out good candidate was ever published her= e, only pieces of one. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Taylor, Rick [mailto:Rick.Taylor@cassidian.com]=20 > Sent: 08 October 2012 11:43 > To: Dearlove, Christopher (UK); Teco Boot; Bo Berry > Cc: List > Subject: RE: [manet] Some comments on manet-dlep-03 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Teco, >=20 > With the greatest respect, I can't see how 5444 is applicable to DLEP. >=20 > Yes, it is possible to reshape the DLEP protocol into 5444, but it reduce= s the clarity of the protocol as it is transformed. >=20 > But more importantly, DLEP is not intended to travel over the network. I= t is link-local by design. Any communication between devices required to p= rovide state for a DLEP implementation might use a 5444 formatted protocol,= but as Stan so elegantly says, that's just 'radio magic' and is a layer hi= dden from DLEP. >=20 > DLEP describes the link-local communication between a router and some mod= ems. It should be formatted to maximize A) Clarity and correctness, B) Eas= e of implementation. Efficient on the wire representation is not a require= ment. >=20 > I previously had an extended exchange with Henning on this list, and betw= een us we managed to fit DLEP-00 into RFC5444 in several ways. But the mor= e I consider it, the more I must conclude that we were solving the wrong pr= oblem. >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Dearlove, Christopher (UK) >> Sent: 08 October 2012 10:19 >> To: Teco Boot; Bo Berry >> Cc: List >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >>=20 >> Teco >>> And there is the RFC 5444 discussion. >>=20 >> I think that, the draft being where it is, it's appropriate for anyone >> saying it should be 5444 to propose concretely how (I think we are agree= d >> not the previous version) and why that is an improvement. Note that I'm >> not arguing one way or the other. Note that the WG mandate to use 5444 >> applies to protocols using the manet protocol/port, not protocols >> developed by the WG. If the protocol is an AHRP the presumption is that = it >> should use that protocol/port, but that doesn't apply to DLEP. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to th= is e-mail is private and in addition may include commercially sensitive inf= ormation. The contents of this e-mail are for the intended recipient only a= nd therefore if you wish to disclose the information contained within this = e-mail or attached files, please contact the sender prior to any such discl= osure. If you are not the intended recipient, any disclosure, copying or di= stribution is prohibited. Please also contact the sender and inform them of= the error and delete the e-mail, including any attached files from your sy= stem. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs= , Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.c= om >=20 --- We cannot solve our problems with the same thinking we used when we created= them.=20 Albert Einstein From davidgorender@gmail.com Mon Oct 8 06:52:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11CF21F857E for ; Mon, 8 Oct 2012 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yAsAvzDPMOy for ; Mon, 8 Oct 2012 06:52:18 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1D21F84CF for ; Mon, 8 Oct 2012 06:52:17 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so3267796wib.1 for ; Mon, 08 Oct 2012 06:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AvZfBKnwFZEdK4VOFJTSEh5HGWon/IPTOYP4ltcthiA=; b=MihFnU/roL9+OVAMkz2haFfW6cRz6O+rVvUnkM7X8nOSafTDVcYUu0iz2C4ji6ua4I NprdXQnQ0L4frBu/8b8Hi3v/GwIZ7I9e/IKvaRM2qCF/hiXK15Vfhsf1sQXZ/rcb6Ie+ ErXjctT2kOXnMPGHBIRz00YlvcHjjGBVTBUCUZi0h4TmD6u57s5/XsHyvX+7xFGkegJT rkZ6pidfTKL8WMMyXEEk6m0EF6iADTufp72RKeQO7v7yeJMRgIu4StF6DcK3hhmMuFOP nj5OsBn63DOKETKBKWnQFTJG3ZXIflHLqIDCi+o706RhwaDW3oUYsqmvjg5kgTFJA5Ab xiOw== Received: by 10.180.108.45 with SMTP id hh13mr21494493wib.15.1349704336881; Mon, 08 Oct 2012 06:52:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.239.74 with HTTP; Mon, 8 Oct 2012 06:51:56 -0700 (PDT) In-Reply-To: <936229623.6783090.1349687205959.JavaMail.root@inria.fr> References: <936229623.6783090.1349687205959.JavaMail.root@inria.fr> From: David Gorender Date: Mon, 8 Oct 2012 10:51:56 -0300 Message-ID: To: Philippe Jacquet Content-Type: multipart/alternative; boundary=e89a8f3bab8d8d399204cb8c876d X-Mailman-Approved-At: Mon, 08 Oct 2012 07:17:51 -0700 Cc: manet@ietf.org Subject: Re: [manet] Uses of MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:52:18 -0000 --e89a8f3bab8d8d399204cb8c876d Content-Type: text/plain; charset=ISO-8859-1 First of all thank you all very much for answering my questions. One of the reasons why im unmotivated is the lack of places where i can discuss such subjects. Even here i was a little afraid to post anything since the emails were so technical. Now, please, don't get me wrong, im not a startup or entrepreneurship kind of guy - not that its a bad thing, i just want to get more experience before thinking on any of that stuff, since i'm still at graduation - as i've been doing research for the past three years. That been said, i found the idea of Wireless Community Mesh Networks and VoIP with MANET protocols very interesting. What i fail to see is how a colaborative network, where all nodes can act like routers is safe enough for such big networks, where you can't control who's acessing it. I know there's some security issues that can be treated on the application layer, but I don't know... maybe i didn't study enough on this to be talking to you guys. I'm very grateful for your help, nonetheless. --e89a8f3bab8d8d399204cb8c876d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First of all thank you all very much for answering my questions. One of the= reasons why im unmotivated is
the lack of places where i can discuss su= ch subjects. Even here i was a little afraid to post anything since
the = emails were so technical.

Now, please, don't get me wrong, im not a startup or entrepreneursh= ip kind of guy - not that its a bad thing,
i just want to get more exper= ience before thinking on any of that stuff, since i'm still at graduati= on - as i've
been doing research for the past three years.

That been said, i foun= d the idea of Wireless Community Mesh Networks and VoIP with MANET protocol= s
very interesting. What i fail to see is how a colaborative network, wh= ere all nodes can act like routers
is safe enough for such big networks, where you can't control who's= acessing it. I know there's some
security issues that can be treat= ed on the application layer, but I don't know... maybe i didn't stu= dy enough
on this to be talking to you guys. I'm very grateful for your help, non= etheless.
 --e89a8f3bab8d8d399204cb8c876d-- From sratliff@cisco.com Mon Oct 8 07:49:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7246121F87EE for ; Mon, 8 Oct 2012 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.515 X-Spam-Level: X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYpeoWM4gdpU for ; Mon, 8 Oct 2012 07:49:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 901B221F852C for ; Mon, 8 Oct 2012 07:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2694; q=dns/txt; s=iport; t=1349707752; x=1350917352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x6TR+3cBq5ZsIypGH/NbObmdvvU1Ry39AKn/MPLWPdE=; b=FP1dx//E4AFiJt8LjKFJGRfA2si+6lEJHptEsGPljhtYTWVD8v0dvgh/ TuPGe56I+mAEHJFcRvsgF5BYX/b7LP8DCSrIn/fFSFhVEeiTnkDu86bIg F3kcmXbELozmA+9DTaa4M8Kjth3M+pTPtnAG8YspsyuyQ+NXr6VVN4YgV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIHnclCtJV2c/2dsb2JhbAA7Cr8qgQiCIQEBBBIBZhACAQgiJDIlAgQODRqHY5l9n0mLXxSFDGADpDCBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="129390345" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 08 Oct 2012 14:49:04 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q98En4N0013366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 14:49:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 09:49:03 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgACYe4A= Date: Mon, 8 Oct 2012 14:49:03 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--43.816800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <2C4D4B39F545914CB62A0B83F7EB7B02@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 14:49:13 -0000 Teco,=20 OK, I've tried to pare this down some - only because the thread is getting = pretty long. If I've left anything off, please let me know. A couple of the= se issues have been brought up, and declined.=20 So far, the issues brought up are basically:=20 1. Use the ticketing system - No promises, but I'll look into it=85 ;-) 2. The ID TLV: This was intended solely as a transport-independent mechani= sm for a router or a radio to correlate traffic. As it turns out, nobody is= using it. We're recommending that the correlation occur via the normal, st= andard 4-tuple that exists for any UDP traffic (source address, source port= , dest address, dest port). The correlation is needed to support 1-N connec= tion models (e.g. multiple radios feeding to 1 router, or multiple routers,= feeding to 1 radio). And yes, we *do* have a "multiple routers to 1 radio"= scenario in mind. That being said, the issue still exists with overlapping= broadcast domains with multiple radios - whether a packet gets transmitted= multiple times, across the multiple radios. However, the current DLEP prot= ocol doesn't *force* you to put one (and only one) radio on a given interfa= ce. We're still advocating using MAC address to identify the far-end neighb= or (aka the remote router). So, I'm with the others on the list who are goo= d with removing it altogether. 3. Change log: My vote is "No". The existing IETF toolset contains the abil= ity to "diff" 2 versions of a draft; it is far better than humans are in id= entifying the changes from version to version. I say we let the tools do wh= at they do best.=20 4. Terminology: I've made multiple runs at this, and apparently, still have= n't satisfied you. Suggest some text.=20 5. Transport protocol: I thought the draft made it pretty clear that DLEP u= ses UDP, with port numbers to be assigned by IANA. If that's not clear, the= n suggest some text.=20 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is currently r= outing protocol agnostic; I think it's best to keep it that way. If we add = an "OLSRv2 metric", then why not an "OSPFv2 metric", and/or an "OSPFv3 metr= ic", and/or a "BGP metric", and/or=85. 7. Splitting the draft into two: Same as above. No. DLEP as currently speci= fied has core and optional parts. I don't see any overlap. Also, as an impl= ementer of the protocol, I like it when all of the pertinent information (o= n both core and optional parts) is in one document.=20 8. "=85remove reliable protocol function and use validity time": Again, I d= isagree. That IMO increases the complexity dramatically.=20 Regards, Stan [snip]= From Chris.Dearlove@baesystems.com Mon Oct 8 08:46:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A7721F87B5 for ; Mon, 8 Oct 2012 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH-7tUi-fLKc for ; Mon, 8 Oct 2012 08:46:25 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2B61B21F87B3 for ; Mon, 8 Oct 2012 08:46:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,554,1344207600"; d="scan'208";a="276719277" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Oct 2012 16:46:24 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q98FkNo5026920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 16:46:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Mon, 8 Oct 2012 16:46:23 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgACYe4CAAB7GMA== Date: Mon, 8 Oct 2012 15:46:22 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:46:26 -0000 As a matter of process, declined by whom? And when "nobody is using it", wh= at's the set of people considered? I agree with point 3. I started writing something on point 6, starting from "what does OLSRv2 met= ric mean" but scrapped it when it was going to take too long to write. But = in short I agree, but had to go through that argument (not presented) to do= so. It leaves it open to others to disagree, but they need to explain what= they are actually specifying in a lot more detail to then be considered. I don't have any comments currently on the other points. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff (sratliff) Sent: 08 October 2012 15:49 To: Teco Boot Cc: List; Bo Berry (boberry) Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Teco,=20 OK, I've tried to pare this down some - only because the thread is getting = pretty long. If I've left anything off, please let me know. A couple of the= se issues have been brought up, and declined.=20 So far, the issues brought up are basically:=20 1. Use the ticketing system - No promises, but I'll look into it. ;-) 2. The ID TLV: This was intended solely as a transport-independent mechani= sm for a router or a radio to correlate traffic. As it turns out, nobody is= using it. We're recommending that the correlation occur via the normal, st= andard 4-tuple that exists for any UDP traffic (source address, source port= , dest address, dest port). The correlation is needed to support 1-N connec= tion models (e.g. multiple radios feeding to 1 router, or multiple routers,= feeding to 1 radio). And yes, we *do* have a "multiple routers to 1 radio"= scenario in mind. That being said, the issue still exists with overlapping= broadcast domains with multiple radios - whether a packet gets transmitted= multiple times, across the multiple radios. However, the current DLEP prot= ocol doesn't *force* you to put one (and only one) radio on a given interfa= ce. We're still advocating using MAC address to identify the far-end neighb= or (aka the remote router). So, I'm with the others on the list who are goo= d with removing it altogether. 3. Change log: My vote is "No". The existing IETF toolset contains the abil= ity to "diff" 2 versions of a draft; it is far better than humans are in id= entifying the changes from version to version. I say we let the tools do wh= at they do best.=20 4. Terminology: I've made multiple runs at this, and apparently, still have= n't satisfied you. Suggest some text.=20 5. Transport protocol: I thought the draft made it pretty clear that DLEP u= ses UDP, with port numbers to be assigned by IANA. If that's not clear, the= n suggest some text.=20 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is currently r= outing protocol agnostic; I think it's best to keep it that way. If we add = an "OLSRv2 metric", then why not an "OSPFv2 metric", and/or an "OSPFv3 metr= ic", and/or a "BGP metric", and/or.. 7. Splitting the draft into two: Same as above. No. DLEP as currently speci= fied has core and optional parts. I don't see any overlap. Also, as an impl= ementer of the protocol, I like it when all of the pertinent information (o= n both core and optional parts) is in one document.=20 8. ".remove reliable protocol function and use validity time": Again, I dis= agree. That IMO increases the complexity dramatically.=20 Regards, Stan [snip] _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Mon Oct 8 09:41:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4721F87F2 for ; Mon, 8 Oct 2012 09:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26z+yURV+KSV for ; Mon, 8 Oct 2012 09:41:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94D21F87EC for ; Mon, 8 Oct 2012 09:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5489; q=dns/txt; s=iport; t=1349714472; x=1350924072; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y6j3Y/E/cdcFWbZDLellSzzbKeeMce7mk/WzG+zwdtk=; b=VhBncTaZ9kqrwMURdWyyQyrcbzQ2xoNc7XcmWO8K+pFpPmf/yKf5ZYHS s89ZvqxUubYse8j5K7Ppv++wCzEGMYNNcqy9cCn2AYHo16gWhDzIwnjHt CCddNXfo/Z479ck8Q85tW5D6Kr/bTpTfvjhk8PLO+j4KNI+BPCfFL+xoT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMEAc1CtJV2c/2dsb2JhbAA7Cr8qgQiCIAEBAQMBAQEBDwFCGQMIBQcEAgEIEQQBAQsdBycLFAkIAgQOAwIIGoddBguaF59ei08QBAYIAoUMYAOII5wNgWmCbT6BHAk0 X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="129453121" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 08 Oct 2012 16:41:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q98GfCWa023004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 16:41:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 11:41:11 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgACYe4CAABAEAIAAD06A Date: Mon, 8 Oct 2012 16:41:10 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FC201@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--64.940400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 16:41:14 -0000 On Oct 8, 2012, at 11:46 AM, Dearlove, Christopher (UK) wrote: > As a matter of process, declined by whom? And when "nobody is using it", = what's the set of people considered? My apologies, I should have been clearer about that. The points were discus= sed on the WG mail list; there wasn't consensus behind them. Regards, Stan >=20 > I agree with point 3. >=20 > I started writing something on point 6, starting from "what does OLSRv2 m= etric mean" but scrapped it when it was going to take too long to write. Bu= t in short I agree, but had to go through that argument (not presented) to = do so. It leaves it open to others to disagree, but they need to explain wh= at they are actually specifying in a lot more detail to then be considered. >=20 > I don't have any comments currently on the other points. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Stan Ratliff (sratliff) > Sent: 08 October 2012 15:49 > To: Teco Boot > Cc: List; Bo Berry (boberry) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Teco,=20 >=20 > OK, I've tried to pare this down some - only because the thread is gettin= g pretty long. If I've left anything off, please let me know. A couple of t= hese issues have been brought up, and declined.=20 >=20 > So far, the issues brought up are basically:=20 >=20 >=20 > 1. Use the ticketing system - No promises, but I'll look into it. ;-) >=20 > 2. The ID TLV: This was intended solely as a transport-independent mecha= nism for a router or a radio to correlate traffic. As it turns out, nobody = is using it. We're recommending that the correlation occur via the normal, = standard 4-tuple that exists for any UDP traffic (source address, source po= rt, dest address, dest port). The correlation is needed to support 1-N conn= ection models (e.g. multiple radios feeding to 1 router, or multiple router= s, feeding to 1 radio). And yes, we *do* have a "multiple routers to 1 radi= o" scenario in mind. That being said, the issue still exists with overlappi= ng broadcast domains with multiple radios - whether a packet gets transmitt= ed multiple times, across the multiple radios. However, the current DLEP pr= otocol doesn't *force* you to put one (and only one) radio on a given inter= face. We're still advocating using MAC address to identify the far-end neig= hbor (aka the remote router). So, I'm with the others on the list who are g= ood with removing it altogether. >=20 > 3. Change log: My vote is "No". The existing IETF toolset contains the ab= ility to "diff" 2 versions of a draft; it is far better than humans are in = identifying the changes from version to version. I say we let the tools do = what they do best.=20 >=20 > 4. Terminology: I've made multiple runs at this, and apparently, still ha= ven't satisfied you. Suggest some text.=20 >=20 > 5. Transport protocol: I thought the draft made it pretty clear that DLEP= uses UDP, with port numbers to be assigned by IANA. If that's not clear, t= hen suggest some text.=20 >=20 > 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is currently= routing protocol agnostic; I think it's best to keep it that way. If we ad= d an "OLSRv2 metric", then why not an "OSPFv2 metric", and/or an "OSPFv3 me= tric", and/or a "BGP metric", and/or.. >=20 > 7. Splitting the draft into two: Same as above. No. DLEP as currently spe= cified has core and optional parts. I don't see any overlap. Also, as an im= plementer of the protocol, I like it when all of the pertinent information = (on both core and optional parts) is in one document.=20 >=20 > 8. ".remove reliable protocol function and use validity time": Again, I d= isagree. That IMO increases the complexity dramatically.=20 >=20 > Regards, > Stan >=20 > [snip] > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From abdussalambaryun@gmail.com Mon Oct 8 09:58:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8121F84AE for ; Mon, 8 Oct 2012 09:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWyYksWMlzWz for ; Mon, 8 Oct 2012 09:58:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E352F21F846B for ; Mon, 8 Oct 2012 09:58:28 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5371170vcb.31 for ; Mon, 08 Oct 2012 09:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TWMVpMap4Y0U7Fp2JTgP+DqAdxf1QVO5rx5eY3tSp8E=; b=hDMzk+6b3E6yle91sD3rhz2xT1G4bZzwWUvb/neqh0WCqNjlxTvnAO54gohAyqu3Fm 3rbQYyOfL5Cm+o9/QWywWmY1CsItuITKgpb5NIF3VwVmvEYbnzpXbRNVdX8/q9wADbAH 36ZbMPedUeNzPmgLi8L2rJeywJ/OIOxY67wcJl0ikf04PNEfpUgnvqKiNAHdIFVzONlR WJh2SFKsKOmnx0YL0aP5ZqiDxQUDXZ64SA0GMsFRaTcxboxpzzzPHvSunQ4ZFlGR+InP XPLts954gLQwldqc7dGvvMSyBsjSQOtGMUbmxsEhzLYYtZtnZIZWr99Z5EZn+3rDqTrA ALBw== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr10158270vca.14.1349715508354; Mon, 08 Oct 2012 09:58:28 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 8 Oct 2012 09:58:28 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> Date: Mon, 8 Oct 2012 17:58:28 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=bcaec54b46c46c5f1704cb8f218d Cc: List , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 16:58:29 -0000 --bcaec54b46c46c5f1704cb8f218d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 my vote in line below, > > So far, the issues brought up are basically: > > > 1. Use the ticketing system - No promises, but I'll look into it=85 ;-) > no objection > > 2. The ID TLV: This was intended solely as a transport-independent > mechanism for a router or a radio to correlate traffic. As it turns out, > nobody is using it. We're recommending that the correlation occur via the > normal, standard 4-tuple that exists for any UDP traffic (source address, > source port, dest address, dest port). The correlation is needed to suppo= rt > 1-N connection models (e.g. multiple radios feeding to 1 router, or > multiple routers, feeding to 1 radio). And yes, we *do* have a "multiple > routers to 1 radio" scenario in mind. That being said, the issue still > exists with overlapping broadcast domains with multiple radios - whether = a > packet gets transmitted multiple times, across the multiple radios. > However, the current DLEP protocol doesn't *force* you to put one (and on= ly > one) radio on a given interface. We're still advocating using MAC address > to identify the far-end neighbor (aka the remote router). So, I'm with th= e > others on the list who are good with removing it altogether. > agreed > > 3. Change log: My vote is "No". The existing IETF toolset contains the > ability to "diff" 2 versions of a draft; it is far better than humans are > in identifying the changes from version to version. I say we let the tool= s > do what they do best. > agree with No vote, > > 4. Terminology: I've made multiple runs at this, and apparently, still > haven't satisfied you. Suggest some text. > still needed details, > > 5. Transport protocol: I thought the draft made it pretty clear that DLEP > uses UDP, with port numbers to be assigned by IANA. If that's not clear, > then suggest some text. > agree its clear > > 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is currently > routing protocol agnostic; I think it's best to keep it that way. If we a= dd > an "OLSRv2 metric", then why not an "OSPFv2 metric", and/or an "OSPFv3 > metric", and/or a "BGP metric", and/or=85. > agreed with No vote, > > 7. Splitting the draft into two: Same as above. No. DLEP as currently > specified has core and optional parts. I don't see any overlap. Also, as = an > implementer of the protocol, I like it when all of the pertinent > information (on both core and optional parts) is in one document. > agreed with No vote > > 8. "=85remove reliable protocol function and use validity time": Again, I > disagree. That IMO increases the complexity dramatically. > no objection AB --bcaec54b46c46c5f1704cb8f218d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1
my vote in=A0line below,

So far, the issues brought up are basically:


1. Use the ticketing system - No promises, but I'll look into it=85 ;-)=
no objection=A0

2. The ID TLV: =A0This was intended solely as a transport-independent mecha= nism for a router or a radio to correlate traffic. As it turns out, nobody = is using it. We're recommending that the correlation occur via the norm= al, standard 4-tuple that exists for any UDP traffic (source address, sourc= e port, dest address, dest port). The correlation is needed to support 1-N = connection models (e.g. multiple radios feeding to 1 router, or multiple ro= uters, feeding to 1 radio). And yes, we *do* have a "multiple routers = to 1 radio" scenario in mind. That being said, the issue still exists = with overlapping broadcast domains with multiple radios - whether a packet = gets transmitted multiple times, across the multiple radios. However, the c= urrent DLEP protocol doesn't *force* you to put one (and only one) radi= o on a given interface. We're still advocating using MAC address to ide= ntify the far-end neighbor (aka the remote router). So, I'm with the ot= hers on the list who are good with removing it altogether.
agreed=A0

3. Change log: My vote is "No". The existing IETF toolset contain= s the ability to "diff" 2 versions of a draft; it is far better t= han humans are in identifying the changes from version to version. I say we= let the tools do what they do best.
agree with=A0No vote,=A0

4. Terminology: I've made multiple runs at this, and apparently, still = haven't satisfied you. Suggest some text.
still ne= eded=A0details,

5. Transport protocol: I thought the draft made it pretty clear that DLEP u= ses UDP, with port numbers to be assigned by IANA. If that's not clear,= then suggest some text.
agree its clear=A0

6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is c= urrently routing protocol agnostic; I think it's best to keep it that w= ay. If we add an "OLSRv2 metric", then why not an "OSPFv2 me= tric", and/or an "OSPFv3 metric", and/or a "BGP metric&= quot;, and/or=85.
agreed with =A0No vote,

7. Splitting the draft into two: Same as above. No. DLEP as currently speci= fied has core and optional parts. I don't see any overlap. Also, as an = implementer of the protocol, I like it when all of the pertinent informatio= n (on both core and optional parts) is in one document.
agreed with No vote=A0

8. "=85remove reliable protocol function and use validity time": = Again, I disagree. That IMO increases the complexity dramatically.
=A0no objection
=A0
AB=A0
--bcaec54b46c46c5f1704cb8f218d-- From davidgorender@gmail.com Mon Oct 8 12:01:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D161F041F for ; Mon, 8 Oct 2012 12:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxWpHl4KlyMQ for ; Mon, 8 Oct 2012 12:01:53 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED81F0420 for ; Mon, 8 Oct 2012 12:01:52 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so3443144wib.13 for ; Mon, 08 Oct 2012 12:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Z0oCYJrIUJutFcIvqFKzhivXs+WtCkoTpZld4tIFylI=; b=izhrSU7AvBEHSzihUaHVZlkH8LJBCOCvR0w6DHwqiwPVf4E4/mtDL3DIQHBmWqU0ot wEz/GY647jFqMI2+tYtOn1MWaBU1XU6fc3SHK/DSMm17eiK8N/Hf4ujYDFilxPsXYovB nZgrwg9eK0BrY5QB0zUyO+vSTZYV6fIcjOUTus823Bop/zogBDJiMuvwQbfMXwlLwJOp PBL3j69Wx+B6KiefcTdBJ9t3LEf+K+4JMWwaHPmnZXxpRSJCYnhS7/nxqwQwdBxUHqHo jP/D48olWtgLe6821b9FkE/VeGmn7xS9xLlNS+kYLZnKT5VlLM5AzgnrXQykBgXeU5VI P0eA== Received: by 10.216.44.3 with SMTP id m3mr2654960web.129.1349722903722; Mon, 08 Oct 2012 12:01:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.239.74 with HTTP; Mon, 8 Oct 2012 12:01:23 -0700 (PDT) In-Reply-To: References: <936229623.6783090.1349687205959.JavaMail.root@inria.fr> From: David Gorender Date: Mon, 8 Oct 2012 16:01:23 -0300 Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=e0cb4e43d23738bced04cb90dae4 X-Mailman-Approved-At: Mon, 08 Oct 2012 12:24:16 -0700 Subject: Re: [manet] Uses of MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 19:01:53 -0000 --e0cb4e43d23738bced04cb90dae4 Content-Type: text/plain; charset=ISO-8859-1 Well, I got what I was looking for. No need to reply on that. Thank you guys. 2012/10/8 David Gorender > First of all thank you all very much for answering my questions. One of > the reasons why im unmotivated is > the lack of places where i can discuss such subjects. Even here i was a > little afraid to post anything since > the emails were so technical. > > Now, please, don't get me wrong, im not a startup or entrepreneurship kind > of guy - not that its a bad thing, > i just want to get more experience before thinking on any of that stuff, > since i'm still at graduation - as i've > been doing research for the past three years. > > That been said, i found the idea of Wireless Community Mesh Networks and > VoIP with MANET protocols > very interesting. What i fail to see is how a colaborative network, where > all nodes can act like routers > is safe enough for such big networks, where you can't control who's > acessing it. I know there's some > security issues that can be treated on the application layer, but I don't > know... maybe i didn't study enough > on this to be talking to you guys. I'm very grateful for your help, > nonetheless. > --e0cb4e43d23738bced04cb90dae4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, I got what I was looking for. No need to reply on that.

Thank = you guys.

2012/10/8 David Gorender <davidgorender@gmail.com>
First of all thank you all very much for ans= wering my questions. One of the reasons why im unmotivated is
the lack o= f places where i can discuss such subjects. Even here i was a little afraid= to post anything since
the emails were so technical.

Now, please, don't get me wrong, im not a startup or entrepreneursh= ip kind of guy - not that its a bad thing,
i just want to get more exper= ience before thinking on any of that stuff, since i'm still at graduati= on - as i've
been doing research for the past three years.

That been said, i foun= d the idea of Wireless Community Mesh Networks and VoIP with MANET protocol= s
very interesting. What i fail to see is how a colaborative network, wh= ere all nodes can act like routers
is safe enough for such big networks, where you can't control who's= acessing it. I know there's some
security issues that can be treat= ed on the application layer, but I don't know... maybe i didn't stu= dy enough
on this to be talking to you guys. I'm very grateful for your help, non= etheless.

--e0cb4e43d23738bced04cb90dae4-- From henning.rogge@fkie.fraunhofer.de Tue Oct 9 04:12:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BB621F889B for ; Tue, 9 Oct 2012 04:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVw+rK3R6jBc for ; Tue, 9 Oct 2012 04:12:49 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7820321F8898 for ; Tue, 9 Oct 2012 04:12:48 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLXjz-0004NP-08 for manet@ietf.org; Tue, 09 Oct 2012 13:12:47 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLXjy-0005VT-Tk for manet@ietf.org; Tue, 09 Oct 2012 13:12:46 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Oct 2012 13:12:46 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 13:12:46 +0200 Message-ID: <507406AD.5090001@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 13:12:45 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030608000102030207050602" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 09 Oct 2012 11:12:46.0761 (UTC) FILETIME=[02EFE990:01CDA60F] X-Virus-Scanned: yes (ClamAV 0.97.5/15443/Tue Oct 9 03:08:24 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 676a75961403c53da43f811dd9e91d0e Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:12:49 -0000 --------------ms030608000102030207050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/08/2012 01:00 AM, Bo Berry wrote: > Henning, All, hope everyone had a great weekend. > > I'll try to highlight the three points in this thread > so we do not miss one, and offer a proposal that we can > work towards consensus. > > Relative to the IDs, suggest we remove the Router/Radio IDs > to reduce the overhead on every message and leverage the > transport/driver. In the case of UDP, we can leverage the > src addr/port and dest addr/port for discrimination. The combination of this four should easily identify a "session" (pair of = DLEP radio and router). of course the routers port number will be fixed (IANA assigned), but=20 that shouldn't matter. > Relative to router side discovery, suggest we drop the > router side discovery and simplify the discovery process. > The router becomes passive (server). The radio is the > active node responsible for initiating the discovery > process. This would essentially revert back to the > original text. I support this, I am not even sure why the change was introduced in the=20 first place. This will remove both the starvation (passive discovery on router AND=20 radio) and the race condition (active discovery on router AND radio).=20 And it prevents a router from spamming non-DLEP radio (which will most=20 likely be also bridges) with discovery beacons. > Relative to DLEP supporting multiple radios on an interface, > suggest DLEP allow for multiple radios on an interface that > supports such. Similar to UDP above, DLEP can leverage > the src addr/port and dest addr/port information. If each radio-instance runs on a different port (which the router can=20 learn by listening to the discovery beacons of both) this should work. I would have preferred a "single socket" solution, but this is still an=20 easy way to do it. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030608000102030207050602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDkxMTEyNDVaMCMGCSqGSIb3DQEJBDEWBBTh9AZiMAcOdFoY2vjSuDc3Pzi55zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAMJnhcWdgQ2NQFVS01JvHMTCRYT+JkSoXcSUxeof7q1QZ jxAFmIYvqYm/6FbinU/A7mvsqPKh/nvvZW6HmKX0ys7QiNWqOtsy3abdKHkZIzc4vCuGOH9I KHGpiw3m6TBoAPSMFGsoNcSvsjiCHpdjL+310/VH7Kq+FLtkXkgNYzkV8ltj49phDqsUuK4A yuxyFX5F71df254rMgGYm3H3pC/SvmpzcNEngRhelEEP6xTQv1RM901DjkvwKUk3prbTFj1h ohmeSy2y51uvJBrTrshSTtQBQ9YGXerepBOy5G4c59e0zp9vpwzz7C3PlI6MuAEQNIrdrQSg 0Shc27iK2AAAAAAAAA== --------------ms030608000102030207050602-- From henning.rogge@fkie.fraunhofer.de Tue Oct 9 04:18:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972C321F86D6 for ; Tue, 9 Oct 2012 04:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL21w7L2D9YP for ; Tue, 9 Oct 2012 04:18:32 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7048921F86CA for ; Tue, 9 Oct 2012 04:18:32 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLXpX-00064u-KM for manet@ietf.org; Tue, 09 Oct 2012 13:18:31 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLXpX-0005e0-Hl for manet@ietf.org; Tue, 09 Oct 2012 13:18:31 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Oct 2012 13:18:31 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 13:18:30 +0200 Message-ID: <50740805.3020603@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 13:18:29 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030700040609070905020605" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 09 Oct 2012 11:18:31.0392 (UTC) FILETIME=[D05A6E00:01CDA60F] X-Virus-Scanned: yes (ClamAV 0.97.5/15443/Tue Oct 9 03:08:24 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8835b956789c73e36836d429bb2623bb Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:18:33 -0000 --------------ms030700040609070905020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: > Teco >> And there is the RFC 5444 discussion. > > I think that, the draft being where it is, it's appropriate for > anyone saying it should be 5444 to propose concretely how (I think we > are agreed not the previous version) and why that is an improvement. I could do this if the list wants to see it. I would like to see RFC5444 in DLEP, but I think working on the protocol = mechanisms and tie down the specification so we get a high chance of=20 interoperability is more important. At the moment I think it will be easy to build multiple DLEP=20 implementations that are consistent with the draft and are NOT=20 interoperable with each other. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030700040609070905020605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDkxMTE4MjlaMCMGCSqGSIb3DQEJBDEWBBTB/vBa7IwxEwSbr1XSYebKLdF0tDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAnLPTd7UE6vtiIEv1cQarg8p0BLPS95ZIxABkHPfWPlWh mm//5qgdV/IzE8JwHMRwLvVeS+nTh+Q5fQCnDs+IQwEEGaibfrCYV1VpRD2OeDuwkSbRqiBm WpYMxPKF6H38Gb4PygI+1KTdt+Do/jicJKbM7+36oufP6FxYbsb639/HT62KJ4aKxuShp2z6 e4kcwe2sZKMZxBcGe1z1Ia9vHFMEAcfqGUrpEbOf5cg4nyZBEe0gcrh3qjfbkT+QpHIKf8eW S+4Udkz8i4Mr/dbwonRqsJcna8VuvNWkebJ7HtUW7vueT67EPHE3x/GMUgF8yzszAGdUPb3u 3/6Oov35LwAAAAAAAA== --------------ms030700040609070905020605-- From henning.rogge@fkie.fraunhofer.de Tue Oct 9 04:23:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2E321F88E2 for ; Tue, 9 Oct 2012 04:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lGnAzqL1jYW for ; Tue, 9 Oct 2012 04:23:22 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD2021F88E0 for ; Tue, 9 Oct 2012 04:23:18 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLXu9-0007ik-4q for manet@ietf.org; Tue, 09 Oct 2012 13:23:17 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLXu9-0005mF-2C for manet@ietf.org; Tue, 09 Oct 2012 13:23:17 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Oct 2012 13:23:16 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 13:23:16 +0200 Message-ID: <50740923.8040502@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 13:23:15 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040306050008010605090906" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 09 Oct 2012 11:23:16.0926 (UTC) FILETIME=[7A8B75E0:01CDA610] X-Virus-Scanned: yes (ClamAV 0.97.5/15443/Tue Oct 9 03:08:24 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2d58c557eff95fe6d1f20ba5c7a78ca3 Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:23:23 -0000 --------------ms040306050008010605090906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/08/2012 04:49 PM, Stan Ratliff (sratliff) wrote: > 2. The ID TLV: This was intended solely as a transport-independent > mechanism for a router or a radio to correlate traffic. As it turns > out, nobody is using it. We're recommending that the correlation > occur via the normal, standard 4-tuple that exists for any UDP > traffic (source address, source port, dest address, dest port). The > correlation is needed to support 1-N connection models (e.g. multiple > radios feeding to 1 router, or multiple routers, feeding to 1 radio). > And yes, we *do* have a "multiple routers to 1 radio" scenario in > mind. Are you talking about connecting a DLEP radio locally to multiple DLEP=20 routers (I think I mentioned something similar a few months ago). > 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is > currently routing protocol agnostic; I think it's best to keep it > that way. If we add an "OLSRv2 metric", then why not an "OSPFv2 > metric", and/or an "OSPFv3 metric", and/or a "BGP metric", and/or=85. One question about the "relative link quality". Why is the range 0-100? If we decide to use a single byte, wouldn't it=20 be better to use 0-255? I know PPPoE use 0-100, but just because PPPoE does strange things we=20 don't need to follow their example. > 8. "=85remove reliable protocol function and use validity time": Again,= > I disagree. That IMO increases the complexity dramatically. It can simplify the protocol but add the need for a few more timers in=20 the implementation. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040306050008010605090906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDkxMTIzMTVaMCMGCSqGSIb3DQEJBDEWBBRjDwYCgYNsM4bfEygkoP2x7rec4jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAwBlHg7qZPAlYoIPeqTyRNmMJUdJPT2WQnLrlpgcChzHP CfGfVnTmpFMh84/hw2wbXYRUKWq8EEU4vQyeLApjJvvAquGqx7bi2WOy8DzgIunZlg0AHXR1 74KWTOtT4SpzzrdBq0JLuPlLYI6+tun0wM+0Ek4U2Jknf3/Uq+3b0/ecHgWarqjYegR6z1qs lnkcyB9qiJoqJSS/VGUbXffwYYks4zZfP6kC/GdPQNYxhdvSI4m9dFm0MWzmRWaiZTHUX6Am 3miRq2u6XFpB/hkyDeJu1Cml8sTdbcydH89tWt46aKN7xSBHteuqQzhevV2m+DCHpf7m8A7S WFpGeSU3nwAAAAAAAA== --------------ms040306050008010605090906-- From ietf@thomasclausen.org Tue Oct 9 04:30:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D768B21F87FC for ; Tue, 9 Oct 2012 04:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-12SqWllPH0 for ; Tue, 9 Oct 2012 04:30:58 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1707821F8800 for ; Tue, 9 Oct 2012 04:30:58 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id CD228557FB3 for ; Tue, 9 Oct 2012 04:30:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8DFD31BD2818; Tue, 9 Oct 2012 04:30:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id DAA861BD280C; Tue, 9 Oct 2012 04:30:52 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Clausen In-Reply-To: <50740805.3020603@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 13:30:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1498) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:30:59 -0000 I'd like to second what Henning says, but in a different way. I think that the first order of business is to tie down the protocol = features -- it seems that there still is divergence on if some features = should/should-not be in there. For example, sessions, timers, periodic = signals, and some of the other things that Teco mentioned (stuff already = done by other protocols, or not?) .... The second order of business is to specify the mechanics of those = protocol features, by way of state machines, procedural descriptions, = pseudocode or whatnot. And then, we can fiddle with the frame format used ;) (Like Chris, I am not neutral as to the RFC5444 discussion) Thomas On Oct 9, 2012, at 1:18 PM, Henning Rogge = wrote: > On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >> Teco >>> And there is the RFC 5444 discussion. >>=20 >> I think that, the draft being where it is, it's appropriate for >> anyone saying it should be 5444 to propose concretely how (I think we >> are agreed not the previous version) and why that is an improvement. >=20 > I could do this if the list wants to see it. >=20 > I would like to see RFC5444 in DLEP, but I think working on the = protocol mechanisms and tie down the specification so we get a high = chance of interoperability is more important. >=20 > At the moment I think it will be easy to build multiple DLEP = implementations that are consistent with the draft and are NOT = interoperable with each other. >=20 > Henning Rogge >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Tue Oct 9 04:41:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8524A21F88CA for ; Tue, 9 Oct 2012 04:41:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lGoip2o7mxN for ; Tue, 9 Oct 2012 04:41:11 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C239821F8897 for ; Tue, 9 Oct 2012 04:41:10 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3673647eek.31 for ; Tue, 09 Oct 2012 04:41:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=cknUR4xVAlvRvBrQukx74218767Uo/GSCQhh3kNgIxk=; b=od7y3Y6aZCgI9wAEeMY22A7pSLyZxdFOAbkS37juYYxWrrZTdV2L+LAgXK9O4AHcZ5 zoPbZl48xhktnGi7tTkWdaVE2+bNbbuV+wQopUxzis/Wsw3fZXvfCcyZtcNpZAr8aXt/ d6iaqDXtyvh7qxxk52R0wcW8QvMrswgtPSIgwwStQ7zWyqoPmNXR7XalJ17XeSccXD4P PQly+1LpzeuAybtDs+0uvyBlzIl58OKyMvmA5DNLdrd67Ai3sRPYCmuemwLKVyyTg9r/ TPtufPGwKUZIeXDoS66A1Z7dFr2TuuZ5wyJYxWHworV/Yj1kcTTLcYiqKoT+eaK9Z3wF 1feQ== Received: by 10.14.194.72 with SMTP id l48mr4190328een.9.1349782869929; Tue, 09 Oct 2012 04:41:09 -0700 (PDT) Received: from [172.16.4.99] ([188.205.88.52]) by mx.google.com with ESMTPS id i41sm33879489eem.7.2012.10.09.04.41.08 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 04:41:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <507406AD.5090001@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 13:41:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66AEEFC7-B58F-4D09-85E8-29A1C2B699C9@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <507406AD.5090001@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkQqH3FRg5hSfx2rKWWEmbD6tUTOhhGYWIuAyDwNR/MLfvvXv7Lx5789ULJAdiOHG0j49NK Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:41:11 -0000 Op 9 okt. 2012, om 13:12 heeft Henning Rogge het volgende geschreven: > On 10/08/2012 01:00 AM, Bo Berry wrote: >>=20 >=20 >> Relative to router side discovery, suggest we drop the >> router side discovery and simplify the discovery process. >> The router becomes passive (server). The radio is the >> active node responsible for initiating the discovery >> process. This would essentially revert back to the >> original text. >=20 > I support this, I am not even sure why the change was introduced in = the first place. >=20 > This will remove both the starvation (passive discovery on router AND = radio) and the race condition (active discovery on router AND radio). = And it prevents a router from spamming non-DLEP radio (which will most = likely be also bridges) with discovery beacons. We have to add text for dlep filters on the radio. For non-dlep radio's = we run into problems in that the dlep traffic is bridged into the = wireless network over there. Using VLANs would be a solution, but I do = not prefer making VLANs mandatory. So we could add text saying that the = dlep filters are necessary and that we cannot solve problems with links = between router and radio, with multiple radio's, where some of them are = non-delp. Teco From henning.rogge@fkie.fraunhofer.de Tue Oct 9 04:47:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B0421F885E for ; Tue, 9 Oct 2012 04:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HVBXfJa3O3N for ; Tue, 9 Oct 2012 04:47:56 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 05E0921F849A for ; Tue, 9 Oct 2012 04:47:56 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLYHz-0007hY-6I; Tue, 09 Oct 2012 13:47:55 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLYHz-0006U9-3c; Tue, 09 Oct 2012 13:47:55 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Oct 2012 13:47:54 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 13:47:54 +0200 Message-ID: <50740EE9.6010101@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 13:47:53 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Teco Boot References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <507406AD.5090001@fkie.fraunhofer.de> <66AEEFC7-B58F-4D09-85E8-29A1C2B699C9@inf-net.nl> In-Reply-To: <66AEEFC7-B58F-4D09-85E8-29A1C2B699C9@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030108030404030509010101" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 09 Oct 2012 11:47:54.0966 (UTC) FILETIME=[EB867760:01CDA613] X-Virus-Scanned: yes (ClamAV 0.97.5/15443/Tue Oct 9 03:08:24 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 912e0972ada2ab87c171579937f55793 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:47:56 -0000 --------------ms030108030404030509010101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/09/2012 01:41 PM, Teco Boot wrote: > > Op 9 okt. 2012, om 13:12 heeft Henning Rogge het volgende > geschreven: > >> On 10/08/2012 01:00 AM, Bo Berry wrote: >>> >> >>> Relative to router side discovery, suggest we drop the router >>> side discovery and simplify the discovery process. The router >>> becomes passive (server). The radio is the active node >>> responsible for initiating the discovery process. This would >>> essentially revert back to the original text. >> >> I support this, I am not even sure why the change was introduced in >> the first place. >> >> This will remove both the starvation (passive discovery on router >> AND radio) and the race condition (active discovery on router AND >> radio). And it prevents a router from spamming non-DLEP radio >> (which will most likely be also bridges) with discovery beacons. > > We have to add text for dlep filters on the radio. For non-dlep > radio's we run into problems in that the dlep traffic is bridged into > the wireless network over there. Using VLANs would be a solution, but > I do not prefer making VLANs mandatory. So we could add text saying > that the dlep filters are necessary and that we cannot solve problems > with links between router and radio, with multiple radio's, where > some of them are non-delp. If only the radio produces multicast packets (for discovery) and all=20 answers of the router (if any at all) are unicasts, we will not have=20 this problem. The switch between the router and the radios should learn about the=20 unicast target by listening to the DLEP-radios Source-MAC address of the = discovery packets. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030108030404030509010101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDkxMTQ3NTNaMCMGCSqGSIb3DQEJBDEWBBRWC4x9OS/3o3po25F1wm4Y2l/ttzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAbS4r8Ss7kstzVKsPuuQJSY1OmHqhkS9OpXhSRwRHVJVd FTzEflfzVYviqB0PxMyxbaTnlSBPMWKierRr8fBv+gDR51/JgXWLBY1sVs2FRToXUjgDX4y+ BmY2P2lV7rvelw+6ffQtqIHb9aEg1cEeG2Qql2s5RCCZQZYby33q5NlNrenTilxDxfT2S7Ng /4prYBYcqFB+cq4xDB53XBrOdkJjdlU6OO1OUv6WFdfPX6IpoGC5s7nkrgS1qmUUu01jNuyn +UOpO1X5twpPhWCZKLzyM1FNrSgfgHWRNT5Y4vGU0WzupYu6wh6bJF2zKLKFjXWUQU/FJF9a CSbE4LnVDgAAAAAAAA== --------------ms030108030404030509010101-- From teco@inf-net.nl Tue Oct 9 04:48:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7821F8518 for ; Tue, 9 Oct 2012 04:48:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRrxqxqwOcF8 for ; Tue, 9 Oct 2012 04:48:42 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id DAE1521F854F for ; Tue, 9 Oct 2012 04:48:41 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so327714eaa.31 for ; Tue, 09 Oct 2012 04:48:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=PB1hwtvj02OmIm25q7tl2itKE+ZAjeAWMgUu2NlKuZo=; b=nB0urHIKClCcGc9Sty1ABsNF/V5wWI4+mOUc/9EsqOX5yF4L6ic8LV9kh26ZLGKdPU oTpMFIiY+dbbZ2DecI/XahHJD3KXVgnmEw9HuroLbgUH5LgDCLTiUwpe6sQEdnlowNSO BI7D5IlyHvkH/b2sDTWGZF/5c9pV/rFDng0Tz+bRS3jC/mImzSz9UtASBcCfQTN8rl/c /3WhN/3M9jmGb1g/FOPST3LS0KreaTo6YuasvDAFaRYd3aiFzrLynH5xNrA9171l9sD1 1wVqPZC77gDbCbhhBiYOOzKtMX4SghWxlxFV11Xw/yUTLlTS7y9US+tjDAXzbs5Yvlnx SpbQ== Received: by 10.14.202.71 with SMTP id c47mr27072762eeo.42.1349783320173; Tue, 09 Oct 2012 04:48:40 -0700 (PDT) Received: from [172.16.4.99] ([188.205.88.52]) by mx.google.com with ESMTPS id 42sm33926559eee.0.2012.10.09.04.48.39 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 04:48:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <50740923.8040502@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 13:48:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmcOJmKGB+pXMYmAap2lH5DeXiYOALSx08z2kZUe7XsgHSlZsrL+6eu8t/3LX/zhAQagbr6 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:48:43 -0000 Op 9 okt. 2012, om 13:23 heeft Henning Rogge het volgende geschreven: > On 10/08/2012 04:49 PM, Stan Ratliff (sratliff) wrote: >> 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is >> currently routing protocol agnostic; I think it's best to keep it >> that way. If we add an "OLSRv2 metric", then why not an "OSPFv2 >> metric", and/or an "OSPFv3 metric", and/or a "BGP metric", and/or=85. >=20 > One question about the "relative link quality". >=20 > Why is the range 0-100? If we decide to use a single byte, wouldn't it = be better to use 0-255? >=20 > I know PPPoE use 0-100, but just because PPPoE does strange things we = don't need to follow their example. +1 (it is PPPoE Extensions for Credit Flow and Link Metrics, RFC 5578) >=20 >> 8. "=85remove reliable protocol function and use validity time": = Again, >> I disagree. That IMO increases the complexity dramatically. >=20 > It can simplify the protocol but add the need for a few more timers in = the implementation. Could be one timer, for housekeeping. The protocols should be designed = in such a way the dat in information databases is explicitly revoked and = nothing depends on the housekeeping timer, except the cleanup. Many = protocols we have today work this way.=20 Teco From teco@inf-net.nl Tue Oct 9 05:01:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7E621F8899 for ; Tue, 9 Oct 2012 05:01:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMSqoRA8f-Ow for ; Tue, 9 Oct 2012 05:01:05 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C25221F8898 for ; Tue, 9 Oct 2012 05:01:05 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so329569eaa.31 for ; Tue, 09 Oct 2012 05:01:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mYb/wO7i80n3LfAz+5U8eToLdVIStGxsTzhjNcHjZLE=; b=mTCTuhEYC+5sQ+93nNizzHf1sxi3Ws0/I08bu6r5W6ftEecO34pzPXkJqNlE3Qjhdf UgmszTOlFuPGrVgv1SyzJUhQ/NfIAXXJ+5QoyFJWffjHh8gjRnZNTSLEdng6454N0F+r Nsy5p5ebaM5prHlWLh+9ETQWGWwF0772SJbAjgoaO9uTP36XPvOy/D/HYIE7e37icVSt V2ivhLf1F1fJzJ13uLGW95QCqCYXyV8CRb8enkwIGPfDZO6bnGwdruz512aoDQ9KEBZB HV4yiASZYADyFwUPfu2M0KHyksXz9FNjgx3Hw++rg7amLOj0UGY+P+cBjNDYHlcFq/k+ /+jA== Received: by 10.14.218.5 with SMTP id j5mr27188564eep.41.1349784064452; Tue, 09 Oct 2012 05:01:04 -0700 (PDT) Received: from [172.16.4.99] ([188.205.88.52]) by mx.google.com with ESMTPS id c6sm33970910eep.17.2012.10.09.05.01.03 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 05:01:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <50740EE9.6010101@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 14:01:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E0EA37A-E54C-4E57-B7A2-55A412A3E86D@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <507406AD.5090001@fkie.fraunhofer.de> <66AEEFC7-B58F-4D09-85E8-29A1C2B699C9@inf-net.nl> <50740EE9.6010101@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlYQueoyFVlwFJxKv1Jezv4wLDGHQf6OWy8Oz/kFwnJvJ6BxLxjh+Noh2Ru+65mUdNlLR3+ Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:01:06 -0000 Op 9 okt. 2012, om 13:47 heeft Henning Rogge het volgende geschreven: > On 10/09/2012 01:41 PM, Teco Boot wrote: >>=20 >> Op 9 okt. 2012, om 13:12 heeft Henning Rogge het volgende >> geschreven: >>=20 >>> On 10/08/2012 01:00 AM, Bo Berry wrote: >>>>=20 >>>=20 >>>> Relative to router side discovery, suggest we drop the router >>>> side discovery and simplify the discovery process. The router >>>> becomes passive (server). The radio is the active node >>>> responsible for initiating the discovery process. This would >>>> essentially revert back to the original text. >>>=20 >>> I support this, I am not even sure why the change was introduced in >>> the first place. >>>=20 >>> This will remove both the starvation (passive discovery on router >>> AND radio) and the race condition (active discovery on router AND >>> radio). And it prevents a router from spamming non-DLEP radio >>> (which will most likely be also bridges) with discovery beacons. >>=20 >> We have to add text for dlep filters on the radio. For non-dlep >> radio's we run into problems in that the dlep traffic is bridged into >> the wireless network over there. Using VLANs would be a solution, but >> I do not prefer making VLANs mandatory. So we could add text saying >> that the dlep filters are necessary and that we cannot solve problems >> with links between router and radio, with multiple radio's, where >> some of them are non-delp. >=20 > If only the radio produces multicast packets (for discovery) and all = answers of the router (if any at all) are unicasts, we will not have = this problem. The dlep multicast packets are seen by the other, non-dlep radio. Then, = they are forwarded towards the wireless net. >=20 > The switch between the router and the radios should learn about the = unicast target by listening to the DLEP-radios Source-MAC address of the = discovery packets. This is unicast. For multicast and IGMP/MGP snooping and related tricks: I have some = experiences with bad implementations. I simply turn such off.=20 In case of DLEP, what can stop multicast from one dlep radio, to another = non-dlep radio, towards the wireless network? I can think of the = following: - Separate interfaces, VLANS are OK. - Multicast filters on switch, with IGMP/MDP snooping (buggy). - L2 filters on these non-dlep radio's. Hard to implement on existing = gear. - Usage of unicast, use multicast for discovery only. There are L2 = discovery protocols already, so we could integrate. - Simply add text: "don't do that". Teco From boberry@cisco.com Tue Oct 9 05:04:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F73021F86E1 for ; Tue, 9 Oct 2012 05:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMSfaHGzk14S for ; Tue, 9 Oct 2012 05:04:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC9321F86A5 for ; Tue, 9 Oct 2012 05:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2859; q=dns/txt; s=iport; t=1349784293; x=1350993893; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EcVHn/m/kO+cKaelLLoLVQ5TDBdI1a/vYuj4cWjp0qw=; b=AAtrvSiwrdhAThUS2xpJX2tBOn3U67yFtm3J+VwdSnVrmkHNyPHYEadZ AofQUH7iRTRb/hoq+zv2y8b3wQc4n/OUXGJ0h+2c33b1Kci7tgyZs+lAk LnDZPFf6w4IAF9Nw3pKFqCW5xmlb+boMLk0yqLGQ3UWXqcepuizlQyDgP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACYSdFCtJV2a/2dsb2JhbAA7Cr8ugQiCIAEBAQMBAQEBDwFbCwULCxgnBycfEQYTGweHXQYLmwyPVpA7izkQhSNgA5VqhWKIY4Frgwk X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129691927" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 09 Oct 2012 12:04:52 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-73.cisco.com [10.81.230.73]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q99C4qim004208; Tue, 9 Oct 2012 12:04:52 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <507406AD.5090001@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 08:04:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9A69B43C-70ED-4A49-AE44-725BF46D9384@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <507406AD.5090001@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:04:54 -0000 Henning, All My reading of the discussion on these topics, it seems we are reaching consensus. If there are disagreements, please let us know.=20 Suggest we agree to close on these topics end of this week=20 if no further discussion. =20 Thanks -Bo On Oct 9, 2012, at 7:12 AM, Henning Rogge wrote: > On 10/08/2012 01:00 AM, Bo Berry wrote: >> Henning, All, hope everyone had a great weekend. >>=20 >> I'll try to highlight the three points in this thread >> so we do not miss one, and offer a proposal that we can >> work towards consensus. >>=20 >> Relative to the IDs, suggest we remove the Router/Radio IDs >> to reduce the overhead on every message and leverage the >> transport/driver. In the case of UDP, we can leverage the >> src addr/port and dest addr/port for discrimination. >=20 > The combination of this four should easily identify a "session" (pair = of DLEP radio and router). >=20 > of course the routers port number will be fixed (IANA assigned), but = that shouldn't matter. >=20 >> Relative to router side discovery, suggest we drop the >> router side discovery and simplify the discovery process. >> The router becomes passive (server). The radio is the >> active node responsible for initiating the discovery >> process. This would essentially revert back to the >> original text. >=20 > I support this, I am not even sure why the change was introduced in = the first place. >=20 > This will remove both the starvation (passive discovery on router AND = radio) and the race condition (active discovery on router AND radio). = And it prevents a router from spamming non-DLEP radio (which will most = likely be also bridges) with discovery beacons. >=20 >> Relative to DLEP supporting multiple radios on an interface, >> suggest DLEP allow for multiple radios on an interface that >> supports such. Similar to UDP above, DLEP can leverage >> the src addr/port and dest addr/port information. >=20 > If each radio-instance runs on a different port (which the router can = learn by listening to the discovery beacons of both) this should work. >=20 > I would have preferred a "single socket" solution, but this is still = an easy way to do it. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From boberry@cisco.com Tue Oct 9 05:12:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6667F21F8804 for ; Tue, 9 Oct 2012 05:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtzHumFdvr+z for ; Tue, 9 Oct 2012 05:11:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AF1FA21F87F2 for ; Tue, 9 Oct 2012 05:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2060; q=dns/txt; s=iport; t=1349784716; x=1350994316; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LC4j07xozWbsRI5+/retpVQeGDTqSTg1afFgN/h56bQ=; b=a57P1w1cPw6uOXQ8/zm9kC4ShhXHD00cG/6JiZgOpRosDCaGguFlHww2 gcasoRgeYn1wtj0qKV1vktfD9qC4Jt+BF9r5CQCOEb2XQpbaIo6X+lm/j 0SIiz6D0hwQRRbAa6TnYlGv4DxeK71F2Bapo6Q3Qxg9U772lefcg0VjrI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADwTdFCtJXHB/2dsb2JhbABFvy6BCIIgAQEBAwEBAQEPAVsLEAsYLicwBhMih10GC5sLj1aQNwSLOYUzYAOVaoViiGOBa4MJgT4h X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129730191" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2012 12:11:56 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-73.cisco.com [10.81.230.73]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q99CBtg6019848; Tue, 9 Oct 2012 12:11:55 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Bo Berry In-Reply-To: <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> Date: Tue, 9 Oct 2012 08:11:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:12:02 -0000 Teco, Henning in-line On Oct 9, 2012, at 7:48 AM, Teco Boot wrote: >=20 > Op 9 okt. 2012, om 13:23 heeft Henning Rogge het volgende geschreven: >=20 >> On 10/08/2012 04:49 PM, Stan Ratliff (sratliff) wrote: >>> 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is >>> currently routing protocol agnostic; I think it's best to keep it >>> that way. If we add an "OLSRv2 metric", then why not an "OSPFv2 >>> metric", and/or an "OSPFv3 metric", and/or a "BGP metric", and/or=85. >>=20 >> One question about the "relative link quality". >>=20 >> Why is the range 0-100? If we decide to use a single byte, wouldn't = it be better to use 0-255? >>=20 >> I know PPPoE use 0-100, but just because PPPoE does strange things we = don't need to follow their example. > +1 > (it is PPPoE Extensions for Credit Flow and Link Metrics, RFC 5578) The RLQ is defined as a percentage value to facilitate consistent definition across different radio types. When processing the RLQ, the router can apply the same heuristics to the RLQ. Otherwise there is risk of that the router would have to aware of these differences. We've been through this discussion many times. So=20 from our experiences, my vote is to leave the RLQ as defined. =20 >>> 8. "=85remove reliable protocol function and use validity time": = Again, >>> I disagree. That IMO increases the complexity dramatically. >>=20 >> It can simplify the protocol but add the need for a few more timers = in the implementation. > Could be one timer, for housekeeping. The protocols should be designed = in such a way the dat in information databases is explicitly revoked and = nothing depends on the housekeeping timer, except the cleanup. Many = protocols we have today work this way.=20 >=20 > Teco >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From teco@inf-net.nl Tue Oct 9 05:32:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267FA1F0C42 for ; Tue, 9 Oct 2012 05:32:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxOfqzULxRoj for ; Tue, 9 Oct 2012 05:32:49 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 538A621F8779 for ; Tue, 9 Oct 2012 05:32:48 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3715797eek.31 for ; Tue, 09 Oct 2012 05:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MvM4q2hYSEyamEO/oTUeLOBfBOFoxVbeCvKxTpppAM8=; b=LraWrv/8zMH4OacJe4x/t7O5V9TzviVY1LiY5n4PrAabJYyNRsmVXRDQDmi4FJAeTQ BwOMAV8whqSqkOmR2Zf/WF+3B6yNe6XsOB1fthyxLsLB+cDo2uQi0L5Ac/z1b8gLIO23 chP/AJp966UrLHaM0EgVh04opgExULydDXCv+Xn2q94TQ4Mqs64v6YHArrQv3N0+U2yS 2G4CcllbFAvr5yzBTzTjqy3ms9NmT4cRexDmt2x9HbAampkVhI41UuTx9/AA+vNvA0uB SKIbiZpEg6FVzQAPGC+xVKbp8JotxQRzmE0IyLbsVnw37GfaH/sc2Dq7xaxVYMhC+Jtq JChQ== Received: by 10.14.0.68 with SMTP id 44mr6195176eea.1.1349785967952; Tue, 09 Oct 2012 05:32:47 -0700 (PDT) Received: from [172.16.4.99] ([188.205.88.52]) by mx.google.com with ESMTPS id 42sm34109122eee.0.2012.10.09.05.32.46 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 05:32:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Tue, 9 Oct 2012 14:32:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlRNXmySW+VA6m57ScYVsuIs1YaYd7+UGvN9/08grHEOdwnhG4ed9A2E99E+KMX//Aqd0Q2 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:32:50 -0000 Op 9 okt. 2012, om 14:11 heeft Bo Berry het volgende geschreven: > Teco, Henning > in-line >=20 > On Oct 9, 2012, at 7:48 AM, Teco Boot wrote: >=20 >>=20 >> Op 9 okt. 2012, om 13:23 heeft Henning Rogge het volgende geschreven: >>=20 >>> On 10/08/2012 04:49 PM, Stan Ratliff (sratliff) wrote: >>>> 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is >>>> currently routing protocol agnostic; I think it's best to keep it >>>> that way. If we add an "OLSRv2 metric", then why not an "OSPFv2 >>>> metric", and/or an "OSPFv3 metric", and/or a "BGP metric", and/or=85.= >>>=20 >>> One question about the "relative link quality". >>>=20 >>> Why is the range 0-100? If we decide to use a single byte, wouldn't = it be better to use 0-255? >>>=20 >>> I know PPPoE use 0-100, but just because PPPoE does strange things = we don't need to follow their example. >> +1 >> (it is PPPoE Extensions for Credit Flow and Link Metrics, RFC 5578) >=20 > The RLQ is defined as a percentage value to facilitate consistent > definition across different radio types. When processing the RLQ, > the router can apply the same heuristics to the RLQ. Otherwise > there is risk of that the router would have to aware of these > differences. We've been through this discussion many times. So=20 > from our experiences, my vote is to leave the RLQ as defined. =20 Having a minimum and a maximum is OK. I don't see much difference in = semantics, just improved efficiency of bits used, or even better, use = more bits. >=20 >>>> 8. "=85remove reliable protocol function and use validity time": = Again, >>>> I disagree. That IMO increases the complexity dramatically. >>>=20 >>> It can simplify the protocol but add the need for a few more timers = in the implementation. >> Could be one timer, for housekeeping. The protocols should be = designed in such a way the dat in information databases is explicitly = revoked and nothing depends on the housekeeping timer, except the = cleanup. Many protocols we have today work this way. I posted on unneeded complexity and partial specification. I suggested two options, both could be supported by the protocol: a) use unreliable protocol, with vtime b) use TCP Discussed whole morning with app guys on why there is a need for UDP = congestion control and better capabilities for retransmit. Let's = circumvent and do it right this time. Read BCP 145 for the details. Teco >>=20 >> Teco >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 From boberry@cisco.com Tue Oct 9 05:58:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A7C21F86DA for ; Tue, 9 Oct 2012 05:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckXYMMYGmVCF for ; Tue, 9 Oct 2012 05:58:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BCDDB21F86D9 for ; Tue, 9 Oct 2012 05:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3399; q=dns/txt; s=iport; t=1349787526; x=1350997126; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sPcMQ8Oq4QRS7rILHJBMMDPxhzcLZXjkQfht9jmCHSY=; b=dIQptYhsSdJsoKnIr/+O25sZrYtp99DlP9A7nxLR+E8Uxoe6Gt7+U4sm 7e7DiDaOQ5dK82GJ4ncHgqFCEvVx5LI7SyHVpZdbxDFHh/L5Aj0zi62zN OX3WPbHswE9cOM78rfXXMt97ZEwn6i+f4vucaeKbh6Zld+caRgT2wN1hS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPMedFCtJV2Z/2dsb2JhbABFvy6BCIIgAQEBAwEBAQEPAVsLBQsLGC4nMAYTIoddBgubHY9WkDgEizmFM2ADlWqFYohjgWuDCYE+IQ X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129689737" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 09 Oct 2012 12:58:45 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-74.cisco.com [10.81.230.74]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q99CwijM024258; Tue, 9 Oct 2012 12:58:44 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Bo Berry In-Reply-To: Date: Tue, 9 Oct 2012 08:58:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:58:46 -0000 Teco in-line -Bo On Oct 9, 2012, at 8:32 AM, Teco Boot wrote: >=20 > Op 9 okt. 2012, om 14:11 heeft Bo Berry het volgende geschreven: >=20 >> Teco, Henning >> in-line >>=20 >> On Oct 9, 2012, at 7:48 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 9 okt. 2012, om 13:23 heeft Henning Rogge het volgende = geschreven: >>>=20 >>>> On 10/08/2012 04:49 PM, Stan Ratliff (sratliff) wrote: >>>>> 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is >>>>> currently routing protocol agnostic; I think it's best to keep it >>>>> that way. If we add an "OLSRv2 metric", then why not an "OSPFv2 >>>>> metric", and/or an "OSPFv3 metric", and/or a "BGP metric", = and/or=85. >>>>=20 >>>> One question about the "relative link quality". >>>>=20 >>>> Why is the range 0-100? If we decide to use a single byte, wouldn't = it be better to use 0-255? >>>>=20 >>>> I know PPPoE use 0-100, but just because PPPoE does strange things = we don't need to follow their example. >>> +1 >>> (it is PPPoE Extensions for Credit Flow and Link Metrics, RFC 5578) >>=20 >> The RLQ is defined as a percentage value to facilitate consistent >> definition across different radio types. When processing the RLQ, >> the router can apply the same heuristics to the RLQ. Otherwise >> there is risk of that the router would have to aware of these >> differences. We've been through this discussion many times. So=20 >> from our experiences, my vote is to leave the RLQ as defined. =20 >=20 > Having a minimum and a maximum is OK. I don't see much difference in = semantics, just improved efficiency of bits used, or even better, use = more bits. Thanks, I read as agreement. As we know, there are many diff types of radios and they 'all' do things differently, even SDRs.=20 >>>>> 8. "=85remove reliable protocol function and use validity time": = Again, >>>>> I disagree. That IMO increases the complexity dramatically. >>>>=20 >>>> It can simplify the protocol but add the need for a few more timers = in the implementation. >>> Could be one timer, for housekeeping. The protocols should be = designed in such a way the dat in information databases is explicitly = revoked and nothing depends on the housekeeping timer, except the = cleanup. Many protocols we have today work this way. >=20 > I posted on unneeded complexity and partial specification. > I suggested two options, both could be supported by the protocol: > a) use unreliable protocol, with vtime > b) use TCP >=20 > Discussed whole morning with app guys on why there is a need for UDP = congestion control and better capabilities for retransmit. Let's = circumvent and do it right this time. Read BCP 145 for the details. >=20 OK, I'll look at 145. Suggest we split this topic into its own thread for easy discussions and closure, when people respond. These emails get long and stuff may be missed by anyone of us. > Teco >=20 >=20 >>>=20 >>> Teco >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we = created them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Tue Oct 9 06:24:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AB011E8106 for ; Tue, 9 Oct 2012 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0Zmh7Wu0d0b for ; Tue, 9 Oct 2012 06:24:30 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6973F11E8101 for ; Tue, 9 Oct 2012 06:24:30 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLZnQ-000635-R7; Tue, 09 Oct 2012 15:24:28 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLZnQ-0000nV-OO; Tue, 09 Oct 2012 15:24:28 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Oct 2012 15:24:28 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 15:24:28 +0200 Message-ID: <50742587.6060804@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 15:24:23 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Bo Berry References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> In-Reply-To: <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080905040607000909040606" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 09 Oct 2012 13:24:28.0566 (UTC) FILETIME=[68C7AB60:01CDA621] X-Virus-Scanned: yes (ClamAV 0.97.5/15443/Tue Oct 9 03:08:24 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 3227f0690b92e74c5d151b48a7980dce Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:24:34 -0000 --------------ms080905040607000909040606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/09/2012 02:58 PM, Bo Berry wrote: >>> The RLQ is defined as a percentage value to facilitate consistent >>> definition across different radio types. When processing the RLQ, >>> the router can apply the same heuristics to the RLQ. Otherwise >>> there is risk of that the router would have to aware of these >>> differences. We've been through this discussion many times. So >>> from our experiences, my vote is to leave the RLQ as defined. >> >> Having a minimum and a maximum is OK. I don't see much difference in s= emantics, just improved efficiency of bits used, or even better, use more= bits. > > Thanks, I read as agreement. > As we know, there are many diff types of radios and > they 'all' do things differently, even SDRs. As long as we remove the "if cannot be calculated, insert 100" part I=20 can live with this. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080905040607000909040606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDkxMzI0MjZaMCMGCSqGSIb3DQEJBDEWBBSRhvtPYMRerIirtI4dLIbSTWZFejBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAhf+A3YRVzXsohnsTMNgyt0Z1bAEmXlC1t5OZZmW3iNAW k+EkrQHyJuwYsf49cUHhprnMNMPWKfQMAiiSArq3kw+msJy23UGxMl9luzuhU5PUVnsLMWvm DMZkDgmgBsfucyhGo7Uy9x8Di/+qOHAzCNXsw3llyInDoOPiPaUYF0DdA6290VyZsDinCd/P /6NMEYIDpUjS++Vp1mT4JBtnD+RQMOQr5lga2+EYr2197T9FLSRbEUPz+tLhkTFVIjw+kf3E V+F4WZPuLvthMEyVBOj+IJ9N9u3ZanjayN4FefwYkx6EOgAEFRWkXKfX5vhCQPSF2WVOdkV5 QFi8aj2uZgAAAAAAAA== --------------ms080905040607000909040606-- From internet-drafts@ietf.org Tue Oct 9 06:33:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9621F86C4; Tue, 9 Oct 2012 06:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-zr-OSyDttO; Tue, 9 Oct 2012 06:33:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470A821F8668; Tue, 9 Oct 2012 06:33:44 -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: 4.34 Message-ID: <20121009133344.18466.93221.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 06:33:44 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:33:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routi= ng Protocol OLSRv2 - Rationale Author(s) : Christopher Dearlove Thomas Heide Clausen Philippe Jacquet Filename : draft-ietf-manet-olsrv2-metrics-rationale-01.txt Pages : 29 Date : 2012-10-09 Abstract: This document describes the rationale for and design considerations behind how link metrics are included in OLSRv2, in order to allow routing by other than minimum hop count routes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-metrics-rational= e-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Chris.Dearlove@baesystems.com Tue Oct 9 06:34:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AEB11E8103 for ; Tue, 9 Oct 2012 06:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fautBNKhePDp for ; Tue, 9 Oct 2012 06:34:32 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58611E80D1 for ; Tue, 9 Oct 2012 06:34:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,560,1344207600"; d="scan'208";a="276990162" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Oct 2012 14:34:30 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q99DYTnF006796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 14:34:29 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 14:34:29 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAAaRhgIAAA3MAgAAyETA= Date: Tue, 9 Oct 2012 13:34:28 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> In-Reply-To: <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:34:33 -0000 I would like to slightly modify Thomas's comment as it applies to me. While a part of me says it's nice having people use your stuff, I'm reasona= bly neutral on the question as to whether DLEP should use 5444. I'm not neu= tral on whether I think 5444 does the job it was designed for. (But of course neither am I saying it's perfect, it contains known compromi= ses as well as the possibility someone could point out improvements we miss= ed. However I'm completely non-neutral - as a user rather than an author - = on whether we should update it. No.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= homas Clausen Sent: 09 October 2012 12:31 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I'd like to second what Henning says, but in a different way. I think that the first order of business is to tie down the protocol featur= es -- it seems that there still is divergence on if some features should/sh= ould-not be in there. For example, sessions, timers, periodic signals, and = some of the other things that Teco mentioned (stuff already done by other p= rotocols, or not?) .... The second order of business is to specify the mechanics of those protocol = features, by way of state machines, procedural descriptions, pseudocode or = whatnot. And then, we can fiddle with the frame format used ;) (Like Chris, I am not neutral as to the RFC5444 discussion) Thomas On Oct 9, 2012, at 1:18 PM, Henning Rogge wrote: > On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >> Teco >>> And there is the RFC 5444 discussion. >>=20 >> I think that, the draft being where it is, it's appropriate for >> anyone saying it should be 5444 to propose concretely how (I think we >> are agreed not the previous version) and why that is an improvement. >=20 > I could do this if the list wants to see it. >=20 > I would like to see RFC5444 in DLEP, but I think working on the protocol = mechanisms and tie down the specification so we get a high chance of intero= perability is more important. >=20 > At the moment I think it will be easy to build multiple DLEP implementati= ons that are consistent with the draft and are NOT interoperable with each = other. >=20 > Henning Rogge >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ietf@thomasclausen.org Tue Oct 9 06:36:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847DC1F0C70 for ; Tue, 9 Oct 2012 06:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnowgIgI2cVN for ; Tue, 9 Oct 2012 06:36:01 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E8C1A1F0C51 for ; Tue, 9 Oct 2012 06:36:01 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C93C1A31CA for ; Tue, 9 Oct 2012 06:36:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 622DA1BD3B33; Tue, 9 Oct 2012 06:36:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 496D71BD3B30; Tue, 9 Oct 2012 06:35:59 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Clausen In-Reply-To: Date: Tue, 9 Oct 2012 15:35:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1498) Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:36:02 -0000 Yeah, what Chris said - much more eloquently - also represents my = position on this matter. On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" = wrote: > I would like to slightly modify Thomas's comment as it applies to me. >=20 > While a part of me says it's nice having people use your stuff, I'm = reasonably neutral on the question as to whether DLEP should use 5444. = I'm not neutral on whether I think 5444 does the job it was designed = for. >=20 > (But of course neither am I saying it's perfect, it contains known = compromises as well as the possibility someone could point out = improvements we missed. However I'm completely non-neutral - as a user = rather than an author - on whether we should update it. No.) >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Thomas Clausen > Sent: 09 October 2012 12:31 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I'd like to second what Henning says, but in a different way. >=20 > I think that the first order of business is to tie down the protocol = features -- it seems that there still is divergence on if some features = should/should-not be in there. For example, sessions, timers, periodic = signals, and some of the other things that Teco mentioned (stuff already = done by other protocols, or not?) .... >=20 > The second order of business is to specify the mechanics of those = protocol features, by way of state machines, procedural descriptions, = pseudocode or whatnot. >=20 > And then, we can fiddle with the frame format used ;) >=20 > (Like Chris, I am not neutral as to the RFC5444 discussion) >=20 > Thomas >=20 > On Oct 9, 2012, at 1:18 PM, Henning Rogge = wrote: >=20 >> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>> Teco >>>> And there is the RFC 5444 discussion. >>>=20 >>> I think that, the draft being where it is, it's appropriate for >>> anyone saying it should be 5444 to propose concretely how (I think = we >>> are agreed not the previous version) and why that is an improvement. >>=20 >> I could do this if the list wants to see it. >>=20 >> I would like to see RFC5444 in DLEP, but I think working on the = protocol mechanisms and tie down the specification so we get a high = chance of interoperability is more important. >>=20 >> At the moment I think it will be easy to build multiple DLEP = implementations that are consistent with the draft and are NOT = interoperable with each other. >>=20 >> Henning Rogge >>=20 >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From boberry@cisco.com Tue Oct 9 06:55:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3944211E8109 for ; Tue, 9 Oct 2012 06:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIYlbmSjahLj for ; Tue, 9 Oct 2012 06:55:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 003D811E8106 for ; Tue, 9 Oct 2012 06:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5618; q=dns/txt; s=iport; t=1349790928; x=1351000528; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=3ki8ezG9L/tfZBO7YYmabBo62cJU0dCxsaxKhLP5p+o=; b=N/oePbK0p+O2PLQ5JI+kCTHXTRD8xh+5c2yAV5zfJYuU+mkJT8wnhvoZ h2VJ2NI5obtNWE1BHkYFIfkQlSFO0JL/YbhUcKRAAyYURk4/Zopt45vrE cedYOVxHkZRBCKo59h8MTOa8wH/TKb7rrc3AE7YkhGumbHIEX7a1XxvFj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKwsdFCtJXHB/2dsb2JhbABFvy6BCIIgAQEBAwEBAQEPAUIZAwgFBwQLDgMEAQEBJwcnHwkIBhMih10GC5syj1aQPIs5FA6FEWADkjmDMY5FgWuDCYE+CQ X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129769139" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2012 13:55:06 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q99Dt5FY001102; Tue, 9 Oct 2012 13:55:05 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> Date: Tue, 9 Oct 2012 09:55:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> To: Thomas Clausen X-Mailer: Apple Mail (2.1085) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:55:29 -0000 Thomas, Christopher I understand your perspectives towards using 5444.=20 DLEP is not a manet routing protocol and is thus not required to use 5444. We have tried to resolve the issues on this list which lead us to using standard TLVs. This is simplier, more efficient than the 5444 encoding. =20 So I do not agree that we need to re-open this discussion. =20 Thanks -Bo On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: > Yeah, what Chris said - much more eloquently - also represents my = position on this matter. >=20 >=20 > On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" = wrote: >=20 >> I would like to slightly modify Thomas's comment as it applies to me. >>=20 >> While a part of me says it's nice having people use your stuff, I'm = reasonably neutral on the question as to whether DLEP should use 5444. = I'm not neutral on whether I think 5444 does the job it was designed = for. >>=20 >> (But of course neither am I saying it's perfect, it contains known = compromises as well as the possibility someone could point out = improvements we missed. However I'm completely non-neutral - as a user = rather than an author - on whether we should update it. No.) >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Thomas Clausen >> Sent: 09 October 2012 12:31 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> I'd like to second what Henning says, but in a different way. >>=20 >> I think that the first order of business is to tie down the protocol = features -- it seems that there still is divergence on if some features = should/should-not be in there. For example, sessions, timers, periodic = signals, and some of the other things that Teco mentioned (stuff already = done by other protocols, or not?) .... >>=20 >> The second order of business is to specify the mechanics of those = protocol features, by way of state machines, procedural descriptions, = pseudocode or whatnot. >>=20 >> And then, we can fiddle with the frame format used ;) >>=20 >> (Like Chris, I am not neutral as to the RFC5444 discussion) >>=20 >> Thomas >>=20 >> On Oct 9, 2012, at 1:18 PM, Henning Rogge = wrote: >>=20 >>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>> Teco >>>>> And there is the RFC 5444 discussion. >>>>=20 >>>> I think that, the draft being where it is, it's appropriate for >>>> anyone saying it should be 5444 to propose concretely how (I think = we >>>> are agreed not the previous version) and why that is an = improvement. >>>=20 >>> I could do this if the list wants to see it. >>>=20 >>> I would like to see RFC5444 in DLEP, but I think working on the = protocol mechanisms and tie down the specification so we get a high = chance of interoperability is more important. >>>=20 >>> At the moment I think it will be easy to build multiple DLEP = implementations that are consistent with the draft and are NOT = interoperable with each other. >>>=20 >>> Henning Rogge >>>=20 >>>=20 >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From ietf@thomasclausen.org Tue Oct 9 06:57:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756971F0C5F for ; Tue, 9 Oct 2012 06:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA8Uj6v+ahzh for ; Tue, 9 Oct 2012 06:56:59 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0E1F0C42 for ; Tue, 9 Oct 2012 06:56:59 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 9FE9E557FF6 for ; Tue, 9 Oct 2012 06:56:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 646071BD3EFA; Tue, 9 Oct 2012 06:56:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4FAE01BD3EEF; Tue, 9 Oct 2012 06:56:56 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Clausen In-Reply-To: <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> Date: Tue, 9 Oct 2012 15:56:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1498) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:57:00 -0000 Bo, I think that neither of Chris nor I suggested that it should (or should = not) be opened. I think that we, generally, agreed that there were other, more = important, thing to get right before considering if it should (or should = not) be opened. Thomas On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: > Thomas, Christopher > I understand your perspectives towards using 5444.=20 >=20 > DLEP is not a manet routing protocol and is thus not required to use > 5444. We have tried to resolve the issues on this list which lead > us to using standard TLVs. This is simplier, more efficient than > the 5444 encoding. =20 >=20 > So I do not agree that we need to re-open this discussion. =20 >=20 > Thanks > -Bo >=20 >=20 > On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: >=20 >> Yeah, what Chris said - much more eloquently - also represents my = position on this matter. >>=20 >>=20 >> On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" = wrote: >>=20 >>> I would like to slightly modify Thomas's comment as it applies to = me. >>>=20 >>> While a part of me says it's nice having people use your stuff, I'm = reasonably neutral on the question as to whether DLEP should use 5444. = I'm not neutral on whether I think 5444 does the job it was designed = for. >>>=20 >>> (But of course neither am I saying it's perfect, it contains known = compromises as well as the possibility someone could point out = improvements we missed. However I'm completely non-neutral - as a user = rather than an author - on whether we should update it. No.) >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Thomas Clausen >>> Sent: 09 October 2012 12:31 >>> To: Henning Rogge >>> Cc: manet@ietf.org >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> I'd like to second what Henning says, but in a different way. >>>=20 >>> I think that the first order of business is to tie down the protocol = features -- it seems that there still is divergence on if some features = should/should-not be in there. For example, sessions, timers, periodic = signals, and some of the other things that Teco mentioned (stuff already = done by other protocols, or not?) .... >>>=20 >>> The second order of business is to specify the mechanics of those = protocol features, by way of state machines, procedural descriptions, = pseudocode or whatnot. >>>=20 >>> And then, we can fiddle with the frame format used ;) >>>=20 >>> (Like Chris, I am not neutral as to the RFC5444 discussion) >>>=20 >>> Thomas >>>=20 >>> On Oct 9, 2012, at 1:18 PM, Henning Rogge = wrote: >>>=20 >>>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>>> Teco >>>>>> And there is the RFC 5444 discussion. >>>>>=20 >>>>> I think that, the draft being where it is, it's appropriate for >>>>> anyone saying it should be 5444 to propose concretely how (I think = we >>>>> are agreed not the previous version) and why that is an = improvement. >>>>=20 >>>> I could do this if the list wants to see it. >>>>=20 >>>> I would like to see RFC5444 in DLEP, but I think working on the = protocol mechanisms and tie down the specification so we get a high = chance of interoperability is more important. >>>>=20 >>>> At the moment I think it will be easy to build multiple DLEP = implementations that are consistent with the draft and are NOT = interoperable with each other. >>>>=20 >>>> Henning Rogge >>>>=20 >>>>=20 >>>> --=20 >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) >>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 From Chris.Dearlove@baesystems.com Tue Oct 9 07:02:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EB111E8113 for ; Tue, 9 Oct 2012 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGoSBDUhx-m8 for ; Tue, 9 Oct 2012 07:02:19 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id C6A8C11E8109 for ; Tue, 9 Oct 2012 07:02:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,560,1344207600"; d="scan'208";a="277002023" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Oct 2012 15:02:18 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q99E2HnQ027591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 15:02:17 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 15:02:17 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry , Thomas Clausen Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAAaRhgIAAA3MAgAAyETD///DkgIAABVmAgAAR4/A= Date: Tue, 9 Oct 2012 14:02:16 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> In-Reply-To: <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:02:20 -0000 You comment implies you think I do think the issue should be re-opened. Spe= aking only for myself, I've explicitly said I neither am saying we should o= r we should not. I'm saying anyone who thinks we should re-open it, should = supply a candidate alternative solution. If I see one then I'll make a judg= ement. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Bo Berry [mailto:boberry@cisco.com]=20 Sent: 09 October 2012 14:55 To: Thomas Clausen Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Thomas, Christopher I understand your perspectives towards using 5444.=20 DLEP is not a manet routing protocol and is thus not required to use 5444. We have tried to resolve the issues on this list which lead us to using standard TLVs. This is simplier, more efficient than the 5444 encoding. =20 So I do not agree that we need to re-open this discussion. =20 Thanks -Bo On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: > Yeah, what Chris said - much more eloquently - also represents my positio= n on this matter. >=20 >=20 > On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" wrote: >=20 >> I would like to slightly modify Thomas's comment as it applies to me. >>=20 >> While a part of me says it's nice having people use your stuff, I'm reas= onably neutral on the question as to whether DLEP should use 5444. I'm not = neutral on whether I think 5444 does the job it was designed for. >>=20 >> (But of course neither am I saying it's perfect, it contains known compr= omises as well as the possibility someone could point out improvements we m= issed. However I'm completely non-neutral - as a user rather than an author= - on whether we should update it. No.) >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Thomas Clausen >> Sent: 09 October 2012 12:31 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> I'd like to second what Henning says, but in a different way. >>=20 >> I think that the first order of business is to tie down the protocol fea= tures -- it seems that there still is divergence on if some features should= /should-not be in there. For example, sessions, timers, periodic signals, a= nd some of the other things that Teco mentioned (stuff already done by othe= r protocols, or not?) .... >>=20 >> The second order of business is to specify the mechanics of those protoc= ol features, by way of state machines, procedural descriptions, pseudocode = or whatnot. >>=20 >> And then, we can fiddle with the frame format used ;) >>=20 >> (Like Chris, I am not neutral as to the RFC5444 discussion) >>=20 >> Thomas >>=20 >> On Oct 9, 2012, at 1:18 PM, Henning Rogge wrote: >>=20 >>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>> Teco >>>>> And there is the RFC 5444 discussion. >>>>=20 >>>> I think that, the draft being where it is, it's appropriate for >>>> anyone saying it should be 5444 to propose concretely how (I think we >>>> are agreed not the previous version) and why that is an improvement. >>>=20 >>> I could do this if the list wants to see it. >>>=20 >>> I would like to see RFC5444 in DLEP, but I think working on the protoco= l mechanisms and tie down the specification so we get a high chance of inte= roperability is more important. >>>=20 >>> At the moment I think it will be easy to build multiple DLEP implementa= tions that are consistent with the draft and are NOT interoperable with eac= h other. >>>=20 >>> Henning Rogge >>>=20 >>>=20 >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them.=20 Albert Einstein From Chris.Dearlove@baesystems.com Tue Oct 9 07:05:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCDE11E80D1 for ; Tue, 9 Oct 2012 07:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5J4Mj-etkci for ; Tue, 9 Oct 2012 07:04:56 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 11AC321F8588 for ; Tue, 9 Oct 2012 07:04:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,560,1344207600"; d="scan'208";a="277002793" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Oct 2012 15:04:54 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q99E4r2k029293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 15:04:54 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 15:04:53 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , Bo Berry Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAAaRhgIAAA3MAgAAyETD///DkgIAABVmAgAAAggCAABJr0A== Date: Tue, 9 Oct 2012 14:04:52 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> In-Reply-To: <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:05:02 -0000 Actually, I haven't caught up properly yet, so I can't judge if the things = being discussed are converging successfully or still have major issues. (I = can make guesses, but they aren't well-enough informed.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Thomas Clausen [mailto:ietf@thomasclausen.org]=20 Sent: 09 October 2012 14:57 To: Bo Berry Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Bo, I think that neither of Chris nor I suggested that it should (or should not= ) be opened. I think that we, generally, agreed that there were other, more important, t= hing to get right before considering if it should (or should not) be opened= . Thomas On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: > Thomas, Christopher > I understand your perspectives towards using 5444.=20 >=20 > DLEP is not a manet routing protocol and is thus not required to use > 5444. We have tried to resolve the issues on this list which lead > us to using standard TLVs. This is simplier, more efficient than > the 5444 encoding. =20 >=20 > So I do not agree that we need to re-open this discussion. =20 >=20 > Thanks > -Bo >=20 >=20 > On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: >=20 >> Yeah, what Chris said - much more eloquently - also represents my positi= on on this matter. >>=20 >>=20 >> On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" wrote: >>=20 >>> I would like to slightly modify Thomas's comment as it applies to me. >>>=20 >>> While a part of me says it's nice having people use your stuff, I'm rea= sonably neutral on the question as to whether DLEP should use 5444. I'm not= neutral on whether I think 5444 does the job it was designed for. >>>=20 >>> (But of course neither am I saying it's perfect, it contains known comp= romises as well as the possibility someone could point out improvements we = missed. However I'm completely non-neutral - as a user rather than an autho= r - on whether we should update it. No.) >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Thomas Clausen >>> Sent: 09 October 2012 12:31 >>> To: Henning Rogge >>> Cc: manet@ietf.org >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> I'd like to second what Henning says, but in a different way. >>>=20 >>> I think that the first order of business is to tie down the protocol fe= atures -- it seems that there still is divergence on if some features shoul= d/should-not be in there. For example, sessions, timers, periodic signals, = and some of the other things that Teco mentioned (stuff already done by oth= er protocols, or not?) .... >>>=20 >>> The second order of business is to specify the mechanics of those proto= col features, by way of state machines, procedural descriptions, pseudocode= or whatnot. >>>=20 >>> And then, we can fiddle with the frame format used ;) >>>=20 >>> (Like Chris, I am not neutral as to the RFC5444 discussion) >>>=20 >>> Thomas >>>=20 >>> On Oct 9, 2012, at 1:18 PM, Henning Rogge wrote: >>>=20 >>>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>>> Teco >>>>>> And there is the RFC 5444 discussion. >>>>>=20 >>>>> I think that, the draft being where it is, it's appropriate for >>>>> anyone saying it should be 5444 to propose concretely how (I think we >>>>> are agreed not the previous version) and why that is an improvement. >>>>=20 >>>> I could do this if the list wants to see it. >>>>=20 >>>> I would like to see RFC5444 in DLEP, but I think working on the protoc= ol mechanisms and tie down the specification so we get a high chance of int= eroperability is more important. >>>>=20 >>>> At the moment I think it will be easy to build multiple DLEP implement= ations that are consistent with the draft and are NOT interoperable with ea= ch other. >>>>=20 >>>> Henning Rogge >>>>=20 >>>>=20 >>>> --=20 >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) >>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > --- > We cannot solve our problems with the same thinking we used when we creat= ed them.=20 > Albert Einstein >=20 >=20 >=20 From boberry@cisco.com Tue Oct 9 07:16:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CC021F882B for ; Tue, 9 Oct 2012 07:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M-xjNz0bnfc for ; Tue, 9 Oct 2012 07:16:16 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4321F875C for ; Tue, 9 Oct 2012 07:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8096; q=dns/txt; s=iport; t=1349792176; x=1351001776; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=g1I9GukCGCot9Z6L3h5yXyMr3nV92fh7VlpG3c1h5hk=; b=KIuXB1lFdQ0mGqb7gaD2BzkJKgyThi0ymrlMw19lwTSnVzhhtA2tZh/b aT8OcHt86NdlV1YlvurLU6U5Yuj94hKQHkwsFw66onm/muqIUngbfR8ZG MmhnJOIT8Eduj2xf061Y5Go05MlKhtdkh11M2ittMkeFJTWD8CP99w8ex Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD4xdFCtJXG//2dsb2JhbABFvy6BCIIgAQEBAwEBAQEPAUIZAwgFBwQLEQQBAQEnBycfCQgGEyKHXQYLm0KPVpA9izkUDoURYAOSOYMxjkWBa4MJgT4J X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129743532" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 09 Oct 2012 14:16:15 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q99EGF51026577; Tue, 9 Oct 2012 14:16:15 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: Date: Tue, 9 Oct 2012 10:16:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1085) Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:16:17 -0000 Christopher I'm getting the impression that we're at rough consensus, if not very = close. Any other comments, perspectives from the WG? -Bo On Oct 9, 2012, at 10:04 AM, Dearlove, Christopher (UK) wrote: > Actually, I haven't caught up properly yet, so I can't judge if the = things being discussed are converging successfully or still have major = issues. (I can make guesses, but they aren't well-enough informed.) >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Thomas Clausen [mailto:ietf@thomasclausen.org]=20 > Sent: 09 October 2012 14:57 > To: Bo Berry > Cc: Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Bo, >=20 > I think that neither of Chris nor I suggested that it should (or = should not) be opened. >=20 > I think that we, generally, agreed that there were other, more = important, thing to get right before considering if it should (or should = not) be opened. >=20 > Thomas >=20 >=20 > On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: >=20 >> Thomas, Christopher >> I understand your perspectives towards using 5444.=20 >>=20 >> DLEP is not a manet routing protocol and is thus not required to use >> 5444. We have tried to resolve the issues on this list which lead >> us to using standard TLVs. This is simplier, more efficient than >> the 5444 encoding. =20 >>=20 >> So I do not agree that we need to re-open this discussion. =20 >>=20 >> Thanks >> -Bo >>=20 >>=20 >> On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: >>=20 >>> Yeah, what Chris said - much more eloquently - also represents my = position on this matter. >>>=20 >>>=20 >>> On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" = wrote: >>>=20 >>>> I would like to slightly modify Thomas's comment as it applies to = me. >>>>=20 >>>> While a part of me says it's nice having people use your stuff, I'm = reasonably neutral on the question as to whether DLEP should use 5444. = I'm not neutral on whether I think 5444 does the job it was designed = for. >>>>=20 >>>> (But of course neither am I saying it's perfect, it contains known = compromises as well as the possibility someone could point out = improvements we missed. However I'm completely non-neutral - as a user = rather than an author - on whether we should update it. No.) >>>>=20 >>>> --=20 >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Thomas Clausen >>>> Sent: 09 October 2012 12:31 >>>> To: Henning Rogge >>>> Cc: manet@ietf.org >>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> I'd like to second what Henning says, but in a different way. >>>>=20 >>>> I think that the first order of business is to tie down the = protocol features -- it seems that there still is divergence on if some = features should/should-not be in there. For example, sessions, timers, = periodic signals, and some of the other things that Teco mentioned = (stuff already done by other protocols, or not?) .... >>>>=20 >>>> The second order of business is to specify the mechanics of those = protocol features, by way of state machines, procedural descriptions, = pseudocode or whatnot. >>>>=20 >>>> And then, we can fiddle with the frame format used ;) >>>>=20 >>>> (Like Chris, I am not neutral as to the RFC5444 discussion) >>>>=20 >>>> Thomas >>>>=20 >>>> On Oct 9, 2012, at 1:18 PM, Henning Rogge = wrote: >>>>=20 >>>>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>>>> Teco >>>>>>> And there is the RFC 5444 discussion. >>>>>>=20 >>>>>> I think that, the draft being where it is, it's appropriate for >>>>>> anyone saying it should be 5444 to propose concretely how (I = think we >>>>>> are agreed not the previous version) and why that is an = improvement. >>>>>=20 >>>>> I could do this if the list wants to see it. >>>>>=20 >>>>> I would like to see RFC5444 in DLEP, but I think working on the = protocol mechanisms and tie down the specification so we get a high = chance of interoperability is more important. >>>>>=20 >>>>> At the moment I think it will be easy to build multiple DLEP = implementations that are consistent with the draft and are NOT = interoperable with each other. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>> Kommunikationssysteme (KOM) >>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> = ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> = ******************************************************************** >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we = created them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >=20 >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From Chris.Dearlove@baesystems.com Tue Oct 9 07:24:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7040721F856D for ; Tue, 9 Oct 2012 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiLjRhdNWK66 for ; Tue, 9 Oct 2012 07:24:52 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7E21F8588 for ; Tue, 9 Oct 2012 07:24:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,560,1344207600"; d="scan'208";a="277011411" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Oct 2012 15:24:51 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q99EOnIh011262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 15:24:49 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 15:24:49 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAAaRhgIAAA3MAgAAyETD///DkgIAABVmAgAAAggCAABJr0P//8v2AgAAQ6MA= Date: Tue, 9 Oct 2012 14:24:48 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:24:53 -0000 Just looking at the postings, I'm seeing some disagreements even today on t= he precision of the specification, in postings from Thomas and Henning, the= latter saying: > At the moment I think it will be easy to build multiple DLEP=20 > implementations that are consistent with the draft and are NOT=20 > interoperable with each other. That looks a bit short of rough consensus to me. (Note that I'm not either = agreeing or disagreeing with the quote.) I also see Henning still saying today " I would like to see RFC5444 in DLEP= ". --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Bo Berry [mailto:boberry@cisco.com]=20 Sent: 09 October 2012 15:16 To: Dearlove, Christopher (UK) Cc: Thomas Clausen; manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Christopher I'm getting the impression that we're at rough consensus, if not very close= . Any other comments, perspectives from the WG? -Bo On Oct 9, 2012, at 10:04 AM, Dearlove, Christopher (UK) wrote: > Actually, I haven't caught up properly yet, so I can't judge if the thing= s being discussed are converging successfully or still have major issues. (= I can make guesses, but they aren't well-enough informed.) >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Thomas Clausen [mailto:ietf@thomasclausen.org]=20 > Sent: 09 October 2012 14:57 > To: Bo Berry > Cc: Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Bo, >=20 > I think that neither of Chris nor I suggested that it should (or should n= ot) be opened. >=20 > I think that we, generally, agreed that there were other, more important,= thing to get right before considering if it should (or should not) be open= ed. >=20 > Thomas >=20 >=20 > On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: >=20 >> Thomas, Christopher >> I understand your perspectives towards using 5444.=20 >>=20 >> DLEP is not a manet routing protocol and is thus not required to use >> 5444. We have tried to resolve the issues on this list which lead >> us to using standard TLVs. This is simplier, more efficient than >> the 5444 encoding. =20 >>=20 >> So I do not agree that we need to re-open this discussion. =20 >>=20 >> Thanks >> -Bo >>=20 >>=20 >> On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: >>=20 >>> Yeah, what Chris said - much more eloquently - also represents my posit= ion on this matter. >>>=20 >>>=20 >>> On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" wrote: >>>=20 >>>> I would like to slightly modify Thomas's comment as it applies to me. >>>>=20 >>>> While a part of me says it's nice having people use your stuff, I'm re= asonably neutral on the question as to whether DLEP should use 5444. I'm no= t neutral on whether I think 5444 does the job it was designed for. >>>>=20 >>>> (But of course neither am I saying it's perfect, it contains known com= promises as well as the possibility someone could point out improvements we= missed. However I'm completely non-neutral - as a user rather than an auth= or - on whether we should update it. No.) >>>>=20 >>>> --=20 >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf= Of Thomas Clausen >>>> Sent: 09 October 2012 12:31 >>>> To: Henning Rogge >>>> Cc: manet@ietf.org >>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> I'd like to second what Henning says, but in a different way. >>>>=20 >>>> I think that the first order of business is to tie down the protocol f= eatures -- it seems that there still is divergence on if some features shou= ld/should-not be in there. For example, sessions, timers, periodic signals,= and some of the other things that Teco mentioned (stuff already done by ot= her protocols, or not?) .... >>>>=20 >>>> The second order of business is to specify the mechanics of those prot= ocol features, by way of state machines, procedural descriptions, pseudocod= e or whatnot. >>>>=20 >>>> And then, we can fiddle with the frame format used ;) >>>>=20 >>>> (Like Chris, I am not neutral as to the RFC5444 discussion) >>>>=20 >>>> Thomas >>>>=20 >>>> On Oct 9, 2012, at 1:18 PM, Henning Rogge wrote: >>>>=20 >>>>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>>>> Teco >>>>>>> And there is the RFC 5444 discussion. >>>>>>=20 >>>>>> I think that, the draft being where it is, it's appropriate for >>>>>> anyone saying it should be 5444 to propose concretely how (I think w= e >>>>>> are agreed not the previous version) and why that is an improvement. >>>>>=20 >>>>> I could do this if the list wants to see it. >>>>>=20 >>>>> I would like to see RFC5444 in DLEP, but I think working on the proto= col mechanisms and tie down the specification so we get a high chance of in= teroperability is more important. >>>>>=20 >>>>> At the moment I think it will be easy to build multiple DLEP implemen= tations that are consistent with the draft and are NOT interoperable with e= ach other. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>> Kommunikationssysteme (KOM) >>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> ******************************************************************** >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we crea= ted them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >=20 >=20 --- We cannot solve our problems with the same thinking we used when we created= them.=20 Albert Einstein From hrogge@googlemail.com Tue Oct 9 07:30:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB511E80A5 for ; Tue, 9 Oct 2012 07:30:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tazi2BCCXrWt for ; Tue, 9 Oct 2012 07:30:23 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8FFD21F875C for ; Tue, 9 Oct 2012 07:30:23 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so5300159pad.31 for ; Tue, 09 Oct 2012 07:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=oHizDbRaN8Po3jmGn7Ir+Hn5QFkBoGEuCMLZMgWDgyA=; b=ezJl2rMPfnXm8AfIJ6/mV6xb8kW/UmfYnFvaNOmTi1kNHPYUDkC9E5FXey8OkJNQQc 5Opx8M61QJpc4H+yVVT/SYNipVYqELAeCzTAfOaGDcKDxwJYgh8vCd8ZgU/XvNuVNuBw Qq+uekNQBk51gr563NcArtFhFQy5WYjnG+x7aiUXK5fEaLr8gn2YAg5KptcmkBBmqaPs IAHdTLfYl928oR//Tk0QKPStUSntUK0UDhmbcwVsFqM+nGQfurzLjI6QB1hWiOTM9J1y rGnATcJn/FMiVOheTUz1re8ZAMhlEpzyux+FlQVh47SZXk9rMmlHL2ahYOj2+YGQGfDt 7bMQ== Received: by 10.66.89.98 with SMTP id bn2mr2182691pab.34.1349793023166; Tue, 09 Oct 2012 07:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Tue, 9 Oct 2012 07:30:02 -0700 (PDT) In-Reply-To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> From: Henning Rogge Date: Tue, 9 Oct 2012 16:30:02 +0200 Message-ID: To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:30:25 -0000 I think we have a rough consensus that the discovery mechanism should be "radio active, router passive" (still waiting for an "agreed" from Stan on this) and that the existing metric TLVs can be put into the standard, if we keep out this "lie about the value if you do not know". I think there might be also a VERY rough consensus that the packet format is not the most important thing we should work on right now. If we get the basic building blocks right and the specification of the protocol mechanisms, the packet format will be not that difficult to do. Both Teco and me still think that using RFC5444 would be the better solution for DLEP, but I could live with the current one IF we get the protocol and specification issues fixed. Please call for a packet format consensus after we did it, its meaningless at the moment. Henning Rogge On Tue, Oct 9, 2012 at 4:16 PM, Bo Berry wrote: > Christopher > I'm getting the impression that we're at rough consensus, if not very clo= se. > > Any other comments, perspectives from the WG? > > -Bo > > On Oct 9, 2012, at 10:04 AM, Dearlove, Christopher (UK) wrote: > >> Actually, I haven't caught up properly yet, so I can't judge if the thin= gs being discussed are converging successfully or still have major issues. = (I can make guesses, but they aren't well-enough informed.) >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Thomas Clausen [mailto:ietf@thomasclausen.org] >> Sent: 09 October 2012 14:57 >> To: Bo Berry >> Cc: Dearlove, Christopher (UK); manet@ietf.org >> Subject: Re: [manet] Some comments on manet-dlep-03 >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Bo, >> >> I think that neither of Chris nor I suggested that it should (or should = not) be opened. >> >> I think that we, generally, agreed that there were other, more important= , thing to get right before considering if it should (or should not) be ope= ned. >> >> Thomas >> >> >> On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: >> >>> Thomas, Christopher >>> I understand your perspectives towards using 5444. >>> >>> DLEP is not a manet routing protocol and is thus not required to use >>> 5444. We have tried to resolve the issues on this list which lead >>> us to using standard TLVs. This is simplier, more efficient than >>> the 5444 encoding. >>> >>> So I do not agree that we need to re-open this discussion. >>> >>> Thanks >>> -Bo >>> >>> >>> On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: >>> >>>> Yeah, what Chris said - much more eloquently - also represents my posi= tion on this matter. >>>> >>>> >>>> On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" wrote: >>>> >>>>> I would like to slightly modify Thomas's comment as it applies to me. >>>>> >>>>> While a part of me says it's nice having people use your stuff, I'm r= easonably neutral on the question as to whether DLEP should use 5444. I'm n= ot neutral on whether I think 5444 does the job it was designed for. >>>>> >>>>> (But of course neither am I saying it's perfect, it contains known co= mpromises as well as the possibility someone could point out improvements w= e missed. However I'm completely non-neutral - as a user rather than an aut= hor - on whether we should update it. No.) >>>>> >>>>> -- >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>> >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Ce= ntre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f Of Thomas Clausen >>>>> Sent: 09 October 2012 12:31 >>>>> To: Henning Rogge >>>>> Cc: manet@ietf.org >>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>> >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>> >>>>> I'd like to second what Henning says, but in a different way. >>>>> >>>>> I think that the first order of business is to tie down the protocol = features -- it seems that there still is divergence on if some features sho= uld/should-not be in there. For example, sessions, timers, periodic signals= , and some of the other things that Teco mentioned (stuff already done by o= ther protocols, or not?) .... >>>>> >>>>> The second order of business is to specify the mechanics of those pro= tocol features, by way of state machines, procedural descriptions, pseudoco= de or whatnot. >>>>> >>>>> And then, we can fiddle with the frame format used ;) >>>>> >>>>> (Like Chris, I am not neutral as to the RFC5444 discussion) >>>>> >>>>> Thomas >>>>> >>>>> On Oct 9, 2012, at 1:18 PM, Henning Rogge wrote: >>>>> >>>>>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>>>>> Teco >>>>>>>> And there is the RFC 5444 discussion. >>>>>>> >>>>>>> I think that, the draft being where it is, it's appropriate for >>>>>>> anyone saying it should be 5444 to propose concretely how (I think = we >>>>>>> are agreed not the previous version) and why that is an improvement= . >>>>>> >>>>>> I could do this if the list wants to see it. >>>>>> >>>>>> I would like to see RFC5444 in DLEP, but I think working on the prot= ocol mechanisms and tie down the specification so we get a high chance of i= nteroperability is more important. >>>>>> >>>>>> At the moment I think it will be easy to build multiple DLEP impleme= ntations that are consistent with the draft and are NOT interoperable with = each other. >>>>>> >>>>>> Henning Rogge >>>>>> >>>>>> >>>>>> -- >>>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>>> Kommunikationssysteme (KOM) >>>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.d= e >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> >>>>> ******************************************************************** >>>>> This email and any attachments are confidential to the intended >>>>> recipient and may also be privileged. If you are not the intended >>>>> recipient please delete it from your system and notify the sender. >>>>> You should not copy it or use it for any purpose nor disclose or >>>>> distribute its contents to any other person. >>>>> ******************************************************************** >>>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> --- >>> We cannot solve our problems with the same thinking we used when we cre= ated them. >>> Albert Einstein >>> >>> >>> >> >> > > --- > We cannot solve our problems with the same thinking we used when we creat= ed them. > Albert Einstein > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Tue Oct 9 07:36:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF7B21F877D for ; Tue, 9 Oct 2012 07:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94rYcHf2dZKn for ; Tue, 9 Oct 2012 07:36:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BA2DA21F8775 for ; Tue, 9 Oct 2012 07:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10427; q=dns/txt; s=iport; t=1349793383; x=1351002983; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Vgav/PNOyONmmWodknDUyn6pAJ/Y8rTrhKhXcD1Sxew=; b=RbthmbdSXyP+UeVnuu/DO/vgd1DI0bcV29w8HZ3LxVnWNVYIGL8QrDHK SFgGTJ5j79CbSX2B0HDf/2ewd1lB3Yp8RFM3ZemFofa45mcrriA4Dgdlk KaibJdVbGJr35IScM5jqk5Nth52wkvcN6CJaI6KddJbM0Bw7Avk/Y+WHx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADk1dFCtJV2b/2dsb2JhbABFvy6BCIIgAQEBAwEBAQEPAQo4GQMIBQcEAgEIDgMEAQEBCh0HJwsUCQgCBA4FCBMHh10GC5s0j1aQP4s5FA6FEWADiCOKFpF2gWuCbYFaCTQ X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129787089" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2012 14:36:23 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q99EaMUE003422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 14:36:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 09:36:22 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgA== Date: Tue, 9 Oct 2012 14:36:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--62.570200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:36:25 -0000 On Oct 9, 2012, at 10:30 AM, Henning Rogge wrote: > I think we have a rough consensus that the discovery mechanism should > be "radio active, router passive" (still waiting for an "agreed" from > Stan on this) agreed. > and that the existing metric TLVs can be put into the > standard, if we keep out this "lie about the value if you do not > know". I plan on making Latency, Resources, and RLQ optional TLVs in DLEP-04. Sinc= e they are optional, I plan on leaving the additional text on "default sett= ings" intact - e.g., if an implementation decides to utilize this OPTIONAL = TLV, AND said implementation (for whatever reason) either can't calculate a= t the given moment (or wants to default it), then as you put it - "Lie abou= t the value". Stan >=20 > I think there might be also a VERY rough consensus that the packet > format is not the most important thing we should work on right now. If > we get the basic building blocks right and the specification of the > protocol mechanisms, the packet format will be not that difficult to > do. >=20 > Both Teco and me still think that using RFC5444 would be the better > solution for DLEP, but I could live with the current one IF we get the > protocol and specification issues fixed. Please call for a packet > format consensus after we did it, its meaningless at the moment. >=20 > Henning Rogge >=20 > On Tue, Oct 9, 2012 at 4:16 PM, Bo Berry wrote: >> Christopher >> I'm getting the impression that we're at rough consensus, if not very cl= ose. >>=20 >> Any other comments, perspectives from the WG? >>=20 >> -Bo >>=20 >> On Oct 9, 2012, at 10:04 AM, Dearlove, Christopher (UK) wrote: >>=20 >>> Actually, I haven't caught up properly yet, so I can't judge if the thi= ngs being discussed are converging successfully or still have major issues.= (I can make guesses, but they aren't well-enough informed.) >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Thomas Clausen [mailto:ietf@thomasclausen.org] >>> Sent: 09 October 2012 14:57 >>> To: Bo Berry >>> Cc: Dearlove, Christopher (UK); manet@ietf.org >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Bo, >>>=20 >>> I think that neither of Chris nor I suggested that it should (or should= not) be opened. >>>=20 >>> I think that we, generally, agreed that there were other, more importan= t, thing to get right before considering if it should (or should not) be op= ened. >>>=20 >>> Thomas >>>=20 >>>=20 >>> On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: >>>=20 >>>> Thomas, Christopher >>>> I understand your perspectives towards using 5444. >>>>=20 >>>> DLEP is not a manet routing protocol and is thus not required to use >>>> 5444. We have tried to resolve the issues on this list which lead >>>> us to using standard TLVs. This is simplier, more efficient than >>>> the 5444 encoding. >>>>=20 >>>> So I do not agree that we need to re-open this discussion. >>>>=20 >>>> Thanks >>>> -Bo >>>>=20 >>>>=20 >>>> On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: >>>>=20 >>>>> Yeah, what Chris said - much more eloquently - also represents my pos= ition on this matter. >>>>>=20 >>>>>=20 >>>>> On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" wrote: >>>>>=20 >>>>>> I would like to slightly modify Thomas's comment as it applies to me= . >>>>>>=20 >>>>>> While a part of me says it's nice having people use your stuff, I'm = reasonably neutral on the question as to whether DLEP should use 5444. I'm = not neutral on whether I think 5444 does the job it was designed for. >>>>>>=20 >>>>>> (But of course neither am I saying it's perfect, it contains known c= ompromises as well as the possibility someone could point out improvements = we missed. However I'm completely non-neutral - as a user rather than an au= thor - on whether we should update it. No.) >>>>>>=20 >>>>>> -- >>>>>> Christopher Dearlove >>>>>> Senior Principal Engineer, Communications Group >>>>>> Communications, Networks and Image Analysis Capability >>>>>> BAE Systems Advanced Technology Centre >>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>=20 >>>>>> BAE Systems (Operations) Limited >>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace C= entre, Farnborough, Hants, GU14 6YU, UK >>>>>> Registered in England & Wales No: 1996687 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Beha= lf Of Thomas Clausen >>>>>> Sent: 09 October 2012 12:31 >>>>>> To: Henning Rogge >>>>>> Cc: manet@ietf.org >>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>=20 >>>>>> ----------------------! WARNING ! ---------------------- >>>>>> This message originates from outside our organisation, >>>>>> either from an external partner or from the internet. >>>>>> Keep this in mind if you answer this message. >>>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>>> for instructions on reporting suspicious email messages. >>>>>> -------------------------------------------------------- >>>>>>=20 >>>>>> I'd like to second what Henning says, but in a different way. >>>>>>=20 >>>>>> I think that the first order of business is to tie down the protocol= features -- it seems that there still is divergence on if some features sh= ould/should-not be in there. For example, sessions, timers, periodic signal= s, and some of the other things that Teco mentioned (stuff already done by = other protocols, or not?) .... >>>>>>=20 >>>>>> The second order of business is to specify the mechanics of those pr= otocol features, by way of state machines, procedural descriptions, pseudoc= ode or whatnot. >>>>>>=20 >>>>>> And then, we can fiddle with the frame format used ;) >>>>>>=20 >>>>>> (Like Chris, I am not neutral as to the RFC5444 discussion) >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>> On Oct 9, 2012, at 1:18 PM, Henning Rogge wrote: >>>>>>=20 >>>>>>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>>>>>> Teco >>>>>>>>> And there is the RFC 5444 discussion. >>>>>>>>=20 >>>>>>>> I think that, the draft being where it is, it's appropriate for >>>>>>>> anyone saying it should be 5444 to propose concretely how (I think= we >>>>>>>> are agreed not the previous version) and why that is an improvemen= t. >>>>>>>=20 >>>>>>> I could do this if the list wants to see it. >>>>>>>=20 >>>>>>> I would like to see RFC5444 in DLEP, but I think working on the pro= tocol mechanisms and tie down the specification so we get a high chance of = interoperability is more important. >>>>>>>=20 >>>>>>> At the moment I think it will be easy to build multiple DLEP implem= entations that are consistent with the draft and are NOT interoperable with= each other. >>>>>>>=20 >>>>>>> Henning Rogge >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>>>> Kommunikationssysteme (KOM) >>>>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.= de >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>> ******************************************************************** >>>>>> This email and any attachments are confidential to the intended >>>>>> recipient and may also be privileged. If you are not the intended >>>>>> recipient please delete it from your system and notify the sender. >>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>> distribute its contents to any other person. >>>>>> ******************************************************************** >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --- >>>> We cannot solve our problems with the same thinking we used when we cr= eated them. >>>> Albert Einstein >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we crea= ted them. >> Albert Einstein >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Tue Oct 9 07:40:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D326921F8800 for ; Tue, 9 Oct 2012 07:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ-JWalzaylr for ; Tue, 9 Oct 2012 07:40:36 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 026A421F87CB for ; Tue, 9 Oct 2012 07:40:35 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2645552bkc.31 for ; Tue, 09 Oct 2012 07:40:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=XqHEeIF0kg739G3JROryZuFTFI9bsXT9ptz5C+4I7Z0=; b=Uv6wAt2olOILOisXq8STBFgXX1hP1sz7NhAnncf1uI3/IC/EkBDoaso3NmMjCjdvkB qbN/7+vtl5TsAS6NFCaxMoJ8aOfPPryz9VkPgFcRP9YqTXwzkAZLhkgsxynX6BT5rual t+HURYTJAs0vuDnuJjB3EJC49z0sh+LVThyWHrwPqyUclHz9fe2xnnKV1a2j2T2duQIs meG7Gy1WlfvJ2PWezpGZXAFadgivpRojx0flUGa298AtC3g29N5HhMs+iMDLuLpsYbDf TXMomaXz1SHmQEKYrtoPRDFQ77+RkiSEn/+VFkfcspwZ/WAwhPr3odBSIANV9mdy8u1Z cK0Q== Received: by 10.204.148.146 with SMTP id p18mr6856319bkv.51.1349793634907; Tue, 09 Oct 2012 07:40:34 -0700 (PDT) Received: from [10.87.54.145] ([80.187.201.33]) by mx.google.com with ESMTPS id s20sm14330417bkw.15.2012.10.09.07.40.33 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:40:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <50742587.6060804@fkie.fraunhofer.de> Date: Tue, 9 Oct 2012 16:40:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A8F3337-537B-4F33-AF3E-4373B10B3565@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <50742587.6060804@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlUbOyXBAsjygmkKmxuZB18+9eUYQs74/vIHH96HSaj1O92Ik1NFGm4KTh/6Lm4Exh4liM8 Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:40:37 -0000 Op 9 okt. 2012, om 15:24 heeft Henning Rogge het volgende geschreven: > On 10/09/2012 02:58 PM, Bo Berry wrote: >>>> The RLQ is defined as a percentage value to facilitate consistent >>>> definition across different radio types. When processing the RLQ, >>>> the router can apply the same heuristics to the RLQ. Otherwise >>>> there is risk of that the router would have to aware of these >>>> differences. We've been through this discussion many times. So >>>> from our experiences, my vote is to leave the RLQ as defined. >>>=20 >>> Having a minimum and a maximum is OK. I don't see much difference in = semantics, just improved efficiency of bits used, or even better, use = more bits. >>=20 >> Thanks, I read as agreement. >> As we know, there are many diff types of radios and >> they 'all' do things differently, even SDRs. >=20 > As long as we remove the "if cannot be calculated, insert 100" part I = can live with this. Lets first find out min_value and max_value, and precision. I read your = posting as: "if cannot be calculated, insert max_value, which is 100%, = or 1". I agree. Teco= From Chris.Dearlove@baesystems.com Tue Oct 9 07:41:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017EB21F882C for ; Tue, 9 Oct 2012 07:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1cRxa3tDA3f for ; Tue, 9 Oct 2012 07:41:44 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEDA21F880F for ; Tue, 9 Oct 2012 07:41:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,560,1344207600"; d="scan'208";a="277018035" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Oct 2012 15:41:43 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q99Efgx7023395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 15:41:43 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 15:41:43 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAAaRhgIAAA3MAgAAyETD///DkgIAABVmAgAAAggCAABJr0P//8v2AgAAD2gCAAAHFAIAAESfA Date: Tue, 9 Oct 2012 14:41:42 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:41:46 -0000 There has been some discussion about 0-100 or 0-255. Why not reserve 255 fo= r unknown (treat as X for X not necessarily equal to 255) and use 0-100 or = 0-254, or even use 0-127 (or 0-100) and MSB set says "actually unknown". (Apologies if I have mixed up two things incorrectly here.) If you do use anything not full range, what do you do if you get another va= lue? If discard, discard what? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 09 October 2012 15:36 To: Henning Rogge Cc: Bo Berry (boberry); Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 9, 2012, at 10:30 AM, Henning Rogge wrote: > I think we have a rough consensus that the discovery mechanism should > be "radio active, router passive" (still waiting for an "agreed" from > Stan on this) agreed. > and that the existing metric TLVs can be put into the > standard, if we keep out this "lie about the value if you do not > know". I plan on making Latency, Resources, and RLQ optional TLVs in DLEP-04. Sinc= e they are optional, I plan on leaving the additional text on "default sett= ings" intact - e.g., if an implementation decides to utilize this OPTIONAL = TLV, AND said implementation (for whatever reason) either can't calculate a= t the given moment (or wants to default it), then as you put it - "Lie abou= t the value". Stan >=20 > I think there might be also a VERY rough consensus that the packet > format is not the most important thing we should work on right now. If > we get the basic building blocks right and the specification of the > protocol mechanisms, the packet format will be not that difficult to > do. >=20 > Both Teco and me still think that using RFC5444 would be the better > solution for DLEP, but I could live with the current one IF we get the > protocol and specification issues fixed. Please call for a packet > format consensus after we did it, its meaningless at the moment. >=20 > Henning Rogge >=20 > On Tue, Oct 9, 2012 at 4:16 PM, Bo Berry wrote: >> Christopher >> I'm getting the impression that we're at rough consensus, if not very cl= ose. >>=20 >> Any other comments, perspectives from the WG? >>=20 >> -Bo >>=20 >> On Oct 9, 2012, at 10:04 AM, Dearlove, Christopher (UK) wrote: >>=20 >>> Actually, I haven't caught up properly yet, so I can't judge if the thi= ngs being discussed are converging successfully or still have major issues.= (I can make guesses, but they aren't well-enough informed.) >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Thomas Clausen [mailto:ietf@thomasclausen.org] >>> Sent: 09 October 2012 14:57 >>> To: Bo Berry >>> Cc: Dearlove, Christopher (UK); manet@ietf.org >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Bo, >>>=20 >>> I think that neither of Chris nor I suggested that it should (or should= not) be opened. >>>=20 >>> I think that we, generally, agreed that there were other, more importan= t, thing to get right before considering if it should (or should not) be op= ened. >>>=20 >>> Thomas >>>=20 >>>=20 >>> On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: >>>=20 >>>> Thomas, Christopher >>>> I understand your perspectives towards using 5444. >>>>=20 >>>> DLEP is not a manet routing protocol and is thus not required to use >>>> 5444. We have tried to resolve the issues on this list which lead >>>> us to using standard TLVs. This is simplier, more efficient than >>>> the 5444 encoding. >>>>=20 >>>> So I do not agree that we need to re-open this discussion. >>>>=20 >>>> Thanks >>>> -Bo >>>>=20 >>>>=20 >>>> On Oct 9, 2012, at 9:35 AM, Thomas Clausen wrote: >>>>=20 >>>>> Yeah, what Chris said - much more eloquently - also represents my pos= ition on this matter. >>>>>=20 >>>>>=20 >>>>> On Oct 9, 2012, at 3:34 PM, "Dearlove, Christopher (UK)" wrote: >>>>>=20 >>>>>> I would like to slightly modify Thomas's comment as it applies to me= . >>>>>>=20 >>>>>> While a part of me says it's nice having people use your stuff, I'm = reasonably neutral on the question as to whether DLEP should use 5444. I'm = not neutral on whether I think 5444 does the job it was designed for. >>>>>>=20 >>>>>> (But of course neither am I saying it's perfect, it contains known c= ompromises as well as the possibility someone could point out improvements = we missed. However I'm completely non-neutral - as a user rather than an au= thor - on whether we should update it. No.) >>>>>>=20 >>>>>> -- >>>>>> Christopher Dearlove >>>>>> Senior Principal Engineer, Communications Group >>>>>> Communications, Networks and Image Analysis Capability >>>>>> BAE Systems Advanced Technology Centre >>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>=20 >>>>>> BAE Systems (Operations) Limited >>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace C= entre, Farnborough, Hants, GU14 6YU, UK >>>>>> Registered in England & Wales No: 1996687 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Beha= lf Of Thomas Clausen >>>>>> Sent: 09 October 2012 12:31 >>>>>> To: Henning Rogge >>>>>> Cc: manet@ietf.org >>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>=20 >>>>>> ----------------------! WARNING ! ---------------------- >>>>>> This message originates from outside our organisation, >>>>>> either from an external partner or from the internet. >>>>>> Keep this in mind if you answer this message. >>>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>>> for instructions on reporting suspicious email messages. >>>>>> -------------------------------------------------------- >>>>>>=20 >>>>>> I'd like to second what Henning says, but in a different way. >>>>>>=20 >>>>>> I think that the first order of business is to tie down the protocol= features -- it seems that there still is divergence on if some features sh= ould/should-not be in there. For example, sessions, timers, periodic signal= s, and some of the other things that Teco mentioned (stuff already done by = other protocols, or not?) .... >>>>>>=20 >>>>>> The second order of business is to specify the mechanics of those pr= otocol features, by way of state machines, procedural descriptions, pseudoc= ode or whatnot. >>>>>>=20 >>>>>> And then, we can fiddle with the frame format used ;) >>>>>>=20 >>>>>> (Like Chris, I am not neutral as to the RFC5444 discussion) >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>> On Oct 9, 2012, at 1:18 PM, Henning Rogge wrote: >>>>>>=20 >>>>>>> On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote: >>>>>>>> Teco >>>>>>>>> And there is the RFC 5444 discussion. >>>>>>>>=20 >>>>>>>> I think that, the draft being where it is, it's appropriate for >>>>>>>> anyone saying it should be 5444 to propose concretely how (I think= we >>>>>>>> are agreed not the previous version) and why that is an improvemen= t. >>>>>>>=20 >>>>>>> I could do this if the list wants to see it. >>>>>>>=20 >>>>>>> I would like to see RFC5444 in DLEP, but I think working on the pro= tocol mechanisms and tie down the specification so we get a high chance of = interoperability is more important. >>>>>>>=20 >>>>>>> At the moment I think it will be easy to build multiple DLEP implem= entations that are consistent with the draft and are NOT interoperable with= each other. >>>>>>>=20 >>>>>>> Henning Rogge >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>>>> Kommunikationssysteme (KOM) >>>>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.= de >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>> ******************************************************************** >>>>>> This email and any attachments are confidential to the intended >>>>>> recipient and may also be privileged. If you are not the intended >>>>>> recipient please delete it from your system and notify the sender. >>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>> distribute its contents to any other person. >>>>>> ******************************************************************** >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --- >>>> We cannot solve our problems with the same thinking we used when we cr= eated them. >>>> Albert Einstein >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we crea= ted them. >> Albert Einstein >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Oct 9 07:42:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0D21F8861 for ; Tue, 9 Oct 2012 07:42:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P7-1X-B52R5 for ; Tue, 9 Oct 2012 07:42:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9508F21F885E for ; Tue, 9 Oct 2012 07:42:12 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so5370445pbb.31 for ; Tue, 09 Oct 2012 07:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9hhxA7HujUHlzYEnSQDmH/7cNtaJizz9mwX4rWRcJHk=; b=iQu9BRMNmURAT8358KDsKR+BqwFuv92EpODTkjtvp3+r/MJhD3ksPXR1cwJQNLFtCa SRp/uuQOlcobq3MFb055WLryaFv/W4XhmoyyqXWROLe+eOTIWrADPRAYvwQj7Sa0B4Tx 4ZB6BgRnSXVWalhQqDyTleni1PJB/xuE92u6mCLKMB96biJQMzVhR364s+Nj/kbYIZrA WE5Z5kC+3uTAIpYf07dXScwUsLNv4eznfoQUMTDzvw/OBxes2nsvTTFEk72dZIjqx1DD toaJhoHmeBnLGudo0Dsn3sfqy9DydgrynFk6PDk9nheM4sDq1TGT9eIIBLelJ3fRmXIo b8kw== Received: by 10.68.233.196 with SMTP id ty4mr8883017pbc.23.1349793732158; Tue, 09 Oct 2012 07:42:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Tue, 9 Oct 2012 07:41:49 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Tue, 9 Oct 2012 16:41:49 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:42:13 -0000 On Tue, Oct 9, 2012 at 4:36 PM, Stan Ratliff (sratliff) wrote: > > On Oct 9, 2012, at 10:30 AM, Henning Rogge wrote: > >> I think we have a rough consensus that the discovery mechanism should >> be "radio active, router passive" (still waiting for an "agreed" from >> Stan on this) > > agreed. > >> and that the existing metric TLVs can be put into the >> standard, if we keep out this "lie about the value if you do not >> know". > > I plan on making Latency, Resources, and RLQ optional TLVs in DLEP-04. Si= nce they are optional, I plan on leaving the additional text on "default se= ttings" intact - e.g., if an implementation decides to utilize this OPTIONA= L TLV, AND said implementation (for whatever reason) either can't calculate= at the given moment (or wants to default it), then as you put it - "Lie ab= out the value". The suggested defaults are a good advise for the DLEP-Router implementation, so I agree we should keep them. Maybe we should even put them into a "default section" for protocol parameters and suggested default TLV values. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Tue Oct 9 07:43:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC6A1F0C42 for ; Tue, 9 Oct 2012 07:43:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkr3UzZa2DAx for ; Tue, 9 Oct 2012 07:43:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 853BE21F885E for ; Tue, 9 Oct 2012 07:43:18 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so5371628pbb.31 for ; Tue, 09 Oct 2012 07:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a2zlfLp0Ok6FWlGO4AhiylLolV1ir4jX34CwuCqPu4A=; b=y6p8vVx36LMcPXn0xEc6YQcBZKZkS5Yv349zcHuuko7HN6SXDPvQv0zneIaBRy6JnA GlljUsJ9uSAx5nVSrPKeroyJLOBHnWg/s/r7l3AQ8sJ5Cu7bBFe+lBEwLJdhqRWvg+HI pFU3uQxYfmqQBgQEXdTCuWp+oqTB8xxPr5HXpWiJrRMTgNfuT0Cc1XnryAqZx1+rsiNf AuBb+L91IYMvMYJtN4H8wAB/FngltmiiRhhasacjcNdT8tTKaUySiAFOexuJ6dsOrq6q /ThE/ISJFTYD6YTWiSdBoqpWZTvz4EWChHP8i1V3cy+0SWGvq9/bFoTKDRSJet+MeAb8 QMSQ== Received: by 10.68.221.166 with SMTP id qf6mr63863908pbc.54.1349793798345; Tue, 09 Oct 2012 07:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Tue, 9 Oct 2012 07:42:58 -0700 (PDT) In-Reply-To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Tue, 9 Oct 2012 16:42:58 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:43:19 -0000 On Tue, Oct 9, 2012 at 4:41 PM, Dearlove, Christopher (UK) wrote: > There has been some discussion about 0-100 or 0-255. Why not reserve 255 for unknown (treat as X for X not necessarily equal to 255) and use 0-100 or 0-254, or even use 0-127 (or 0-100) and MSB set says "actually unknown". > > (Apologies if I have mixed up two things incorrectly here.) > > If you do use anything not full range, what do you do if you get another value? If discard, discard what? Everyone agrees we want to have a TLV value. Why put an "unknown" value into it if we can just skip the whole TLV? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Tue Oct 9 07:52:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA26721F873E for ; Tue, 9 Oct 2012 07:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ0nvmVq31-K for ; Tue, 9 Oct 2012 07:52:58 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09CEE21F8742 for ; Tue, 9 Oct 2012 07:52:51 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2654375bkc.31 for ; Tue, 09 Oct 2012 07:52:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CnTVi/mZTRXd034ySA5FQMKZJ/j5++YG0kocm7r/TUk=; b=izPsQ+Y93yv3zOMI2wW8C5YJiAuU8a+HSYEpnCpK6s1nFfaRM93A3Z3RpLmJOEm4an gpeX2ilhWnc0D/B6hbUnfXJZE9xKFdNt/+WFmoHyeYs7SeUFGNoFpjjoLr8YoCehkFkM hyi0QpF6Z/GXH028UD6njGNAf1x69eBPDLRz1Oh5Q1GmU0WOClhS5kYDWZgg9Qnhv7jT EGALvJ04SC49p1lYjqxKROwm+E459tLppDUzViX64miJ12xK1sHFDQ5aoJ+yA4g7RkmO yJvyVgdAK+05ps9CZQ18+0SrIQjgOtJrY/rLZvkDKvZINbQNjpcrqBPUXy8FGqxkSstg s1Rw== Received: by 10.204.4.129 with SMTP id 1mr6821775bkr.58.1349794370262; Tue, 09 Oct 2012 07:52:50 -0700 (PDT) Received: from [10.87.54.145] ([80.187.201.33]) by mx.google.com with ESMTPS id x13sm15135496bkv.16.2012.10.09.07.52.37 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:52:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 9 Oct 2012 16:52:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm6/Kw+dOGjX7QOAI/Dx/vxZtsqDegjpkNJLRF3q7fNs1IXjHXbq0aeriBCqRi2Qfq8oVyB Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:52:58 -0000 Op 9 okt. 2012, om 16:42 heeft Henning Rogge het volgende geschreven: > On Tue, Oct 9, 2012 at 4:41 PM, Dearlove, Christopher (UK) > wrote: >> There has been some discussion about 0-100 or 0-255. Why not reserve = 255 for unknown (treat as X for X not necessarily equal to 255) and use = 0-100 or 0-254, or even use 0-127 (or 0-100) and MSB set says "actually = unknown". >>=20 >> (Apologies if I have mixed up two things incorrectly here.) >>=20 >> If you do use anything not full range, what do you do if you get = another value? If discard, discard what? >=20 > Everyone agrees we want to have a TLV value. Why put an "unknown" > value into it if we can just skip the whole TLV? Just to fill up the pipe :-) Or a beter argument: if we discuss addressblock TLVs, the "unknown" = value could be used for increased efficiency, if only few nodes miss the = value, and other values in addressblock are available. Then, a single = address block can be used, instead of splitting up the set. So IMHO it is a nice to have option to send "unknown" value or suppress = sending, with the same effect. I agree with options that this a bit of a dirty hack. Teco From teco@inf-net.nl Tue Oct 9 07:57:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E992521F87DB for ; Tue, 9 Oct 2012 07:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLJtfOlklu3Q for ; Tue, 9 Oct 2012 07:57:23 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3528021F87E0 for ; Tue, 9 Oct 2012 07:57:23 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2657695bkc.31 for ; Tue, 09 Oct 2012 07:57:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zBRPdulnksLZfm4PKRcVEXOIIMfb1fUGEoSE1b6BnY4=; b=WmcVhzqADJYQS4cHWjQ7HMKN0uYnN74FV203WXc/HY0dFGGYCBqwMRyRwQsTbxJjgQ xqYua58TQa0mUHnGwipc3H/QgP2XVTwoqMWVhSJ3zbGjoe3yv5PWX5jvA6Po5iPYjWu8 HGkFLJHqhRHvRqGHjInoCZG9RdO9N10twXmYInungP+5QYWATsmqa/1aJ1D+09PPtDFq gQWAJ/IHjP4s93Raa2bfqubxnJgNjSj40DNchHhyE5sgtKAN40aRGHMU7f3KLYY1eSBn vmM7ghrAQ5M6kBzufeGyYUjA1Si35yMSxZ1QUhv3ItG4BYx+y2Iop3QHyskJKMufeAeM 6hgA== Received: by 10.204.155.133 with SMTP id s5mr6922451bkw.112.1349794642164; Tue, 09 Oct 2012 07:57:22 -0700 (PDT) Received: from [10.87.54.145] ([80.187.201.33]) by mx.google.com with ESMTPS id j24sm15014658bkv.0.2012.10.09.07.57.17 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:57:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Tue, 9 Oct 2012 16:57:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlBF8QGscff8gHXKv9f2dMax2eoNJImXN3JFVyQuHoGiJDqI6qjqVTcKqhFJAKJB/hllhLe Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:57:24 -0000 Op 9 okt. 2012, om 16:30 heeft Henning Rogge het volgende geschreven: > I think we have a rough consensus that the discovery mechanism should > be "radio active, router passive" (still waiting for an "agreed" from > Stan on this) and that the existing metric TLVs can be put into the > standard, if we keep out this "lie about the value if you do not > know". >=20 > I think there might be also a VERY rough consensus that the packet > format is not the most important thing we should work on right now. If > we get the basic building blocks right and the specification of the > protocol mechanisms, the packet format will be not that difficult to > do. >=20 > Both Teco and me still think that using RFC5444 would be the better > solution for DLEP, but I could live with the current one IF we get the > protocol and specification issues fixed. Please call for a packet > format consensus after we did it, its meaningless at the moment. If we keep the reliable transfer, and use our TCP for it, RFC 5444 = doesn't make sense. If we go for refresh with vtime, RFC 5444 makes the protocol rather = efficient. I agree on postponing this topic and do not make premature conclusions = on consensus, or not. Teco=20= From Martin.Duke@boeing.com Tue Oct 9 07:58:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5414B21F87DC for ; Tue, 9 Oct 2012 07:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68s+TV8Jx9Aw for ; Tue, 9 Oct 2012 07:58:09 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id C9E1D21F87DB for ; Tue, 9 Oct 2012 07:58:09 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q99Ew8iu021551 for ; Tue, 9 Oct 2012 07:58:09 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q99Ew83j021539 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Oct 2012 07:58:08 -0700 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 9 Oct 2012 07:58:07 -0700 From: "Duke, Martin" To: Henning Rogge , "Dearlove, Christopher (UK)" Date: Tue, 9 Oct 2012 07:58:06 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: Ac2mLHg9KDRj8JrtQa6l96zm8jpmZAAAa3Jg Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:58:10 -0000 The only concern with reporting an unknown value by simply not including th= e TLV is if the link state transitions from a known value to an unknown val= ue. I'm not sure how often this would happen, but it seems easy enough to r= eserve 255 (or whatever) as an 'unknown' code point. ********* To change the subject radically, I think the text in sections 9.9 and 9.10 = fail to make the case for distinct expressions of "expected forwarding time= " and "latency."=20 In the text, EFT is carefully defined. I understand that latency will be im= plementation-dependent, but if I were to implement a router or radio with t= his feature, I have no idea how what I'm expected to calculate/interpret di= ffers from EFT. After poking around a bit in the list archives, it seems li= ke EFT is just a really good way to compute latency, in which case it's not= a separate metric but just a really good vendor implementation of Latency. Moreover, on a purely editorial note, 9.9 defines the metric in the main bo= dy in the text, while 9.10 defines latency in the field definition. Martin -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: Tuesday, October 09, 2012 7:43 AM To: Dearlove, Christopher (UK) Cc: manet@ietf.org; Bo Berry (boberry); Stan Ratliff (sratliff) Subject: Re: [manet] Some comments on manet-dlep-03 On Tue, Oct 9, 2012 at 4:41 PM, Dearlove, Christopher (UK) wrote: > There has been some discussion about 0-100 or 0-255. Why not reserve 255 = for unknown (treat as X for X not necessarily equal to 255) and use 0-100 o= r 0-254, or even use 0-127 (or 0-100) and MSB set says "actually unknown". > > (Apologies if I have mixed up two things incorrectly here.) > > If you do use anything not full range, what do you do if you get another = value? If discard, discard what? Everyone agrees we want to have a TLV value. Why put an "unknown" value into it if we can just skip the whole TLV? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billion= s of percent in a tiny fraction of a second. Of course, that was before the= present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Oct 9 08:03:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9A121F847C for ; Tue, 9 Oct 2012 08:03:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNQr+qTb-ZL8 for ; Tue, 9 Oct 2012 08:03:28 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C921F842A for ; Tue, 9 Oct 2012 08:03:28 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so13492467iec.31 for ; Tue, 09 Oct 2012 08:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CeH4oP6gVVEax9qBxH9a6NkYv3L+bH5i/Txv3hMcFr4=; b=Lrm2qHqde7qxXFgiQ8V3irMJo14Xxlkcj+dOs6kvhzh4Fi0v4wgA9Wp/JrhVc+caQ7 AnaGzPYFrPOX0X/JAm7ve+MfLKWJYi4yes1svvTBQUWJTnDNxa8VH5wF/f60aBSfJlr0 2olgV/7IyEZjDLMWpV+3a7c8cvVeNHlH4D+wAWb5DR/rvjvqUcnyoqxhVt+KqmoWELXn zorBXgP+OcxngauCsvoAy7rAQgsDNypJ1wHb2+VKwk0OE0/bJFRP6o8pUqdNpR5fN5ph 7msW+0DuHKjfxbwhzzj9xiLsdADvSOl9e5YNPPYituqdx42YN8R0gMGXHOtgGD9Byeug BuFw== Received: by 10.42.95.10 with SMTP id d10mr15757016icn.30.1349795007247; Tue, 09 Oct 2012 08:03:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.14.41 with HTTP; Tue, 9 Oct 2012 08:03:06 -0700 (PDT) In-Reply-To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Tue, 9 Oct 2012 17:03:06 +0200 Message-ID: To: "Duke, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:03:31 -0000 On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wrote= : > The only concern with reporting an unknown value by simply not including = the TLV is if the link state transitions from a known value to an unknown v= alue. I'm not sure how often this would happen, but it seems easy enough to= reserve 255 (or whatever) as an 'unknown' code point. If a radio supports RLQ it should ALWAYS include the TLV... if it does not, it should NEVER include it. (maybe this should be a MUST in the final RFC) So the transition should not happen at all. > To change the subject radically, I think the text in sections 9.9 and 9.1= 0 fail to make the case for distinct expressions of "expected forwarding ti= me" and "latency." > > In the text, EFT is carefully defined. I understand that latency will be = implementation-dependent, but if I were to implement a router or radio with= this feature, I have no idea how what I'm expected to calculate/interpret = differs from EFT. After poking around a bit in the list archives, it seems = like EFT is just a really good way to compute latency, in which case it's n= ot a separate metric but just a really good vendor implementation of Latenc= y. Yes, that was my feeling about this too. We need a good specification what a TLV is about and how it should be generated/interpreted. Otherwise we will get non-interoperable implementations. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Martin.Duke@boeing.com Tue Oct 9 08:08:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707CF21F8575 for ; Tue, 9 Oct 2012 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKKqLObgUKv0 for ; Tue, 9 Oct 2012 08:08:17 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id E0E4D21F8554 for ; Tue, 9 Oct 2012 08:08:16 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q99F8FZv007447 for ; Tue, 9 Oct 2012 10:08:16 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q99F8EBN007429 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Oct 2012 10:08:15 -0500 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 9 Oct 2012 08:08:15 -0700 From: "Duke, Martin" To: Henning Rogge Date: Tue, 9 Oct 2012 08:08:13 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: Ac2mLz7oX4nom+zvReK5cFhPJ3UtxgAADFqw Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:08:17 -0000 RLQ calculation is so loosely defined that it's hard to precisely describe = how this kind of thing might happen. Latency is a bit easier. But in either= case, I can imagine a situation where a radio is RLQ/Latency capable, but = it hasn't heard from a neighbor in a while, at least in a way where it can = make any sort of reasonable estimate of either quantity. In this case, it s= hould report to the router a transition from an RLQ of "foo" to an RLQ of "= unknown". Therefore, we need an unknown code point. -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: Tuesday, October 09, 2012 8:03 AM To: Duke, Martin Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Stan Ra= tliff (sratliff) Subject: Re: [manet] Some comments on manet-dlep-03 On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wrote= : > The only concern with reporting an unknown value by simply not including = the TLV is if the link state transitions from a known value to an unknown v= alue. I'm not sure how often this would happen, but it seems easy enough to= reserve 255 (or whatever) as an 'unknown' code point. If a radio supports RLQ it should ALWAYS include the TLV... if it does not,= it should NEVER include it. (maybe this should be a MUST in the final RFC) So the transition should not happen at all. From sratliff@cisco.com Tue Oct 9 08:10:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2DE21F854E for ; Tue, 9 Oct 2012 08:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-ASDvFL2+Mh for ; Tue, 9 Oct 2012 08:10:04 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8AE21F8546 for ; Tue, 9 Oct 2012 08:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2160; q=dns/txt; s=iport; t=1349795404; x=1351005004; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+Jba3Ymu4iZ9lsNBZsGyPu1QtAhJYz/XPSTeTFMcQJE=; b=C4NnPXdk8a7rlca/vMSsL+x+5ieMoFm7KxWPUsMTHKGpX7BTZmyat7C2 bbWOa8KQeFFv2sXz7xf6aHPMsEErwJarQewQF4N1HV6BbN2UMNwY+7dLN WbQQHX6qEZVByH9sey3RKtGYmP15Tcp+5jlV0jpGQC47OARKTFnJlpkRs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOY9dFCtJV2a/2dsb2JhbABFvy+BCIIgAQEBAwESAWYFCwIBCA4KCiQyJQIEDgUIGoddBpttj1aQQIs5hTNgA4gjnAyBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129548826" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 09 Oct 2012 15:10:04 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q99FA4pa020929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 15:10:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:10:03 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAAB8AA= Date: Tue, 9 Oct 2012 15:10:02 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005B5@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--40.876000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3AF2417E733B1E43BC9744831FBC24D5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:10:05 -0000 On Oct 9, 2012, at 11:03 AM, Henning Rogge wrote: > On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wro= te: >> The only concern with reporting an unknown value by simply not including= the TLV is if the link state transitions from a known value to an unknown = value. I'm not sure how often this would happen, but it seems easy enough t= o reserve 255 (or whatever) as an 'unknown' code point. >=20 > If a radio supports RLQ it should ALWAYS include the TLV... if it does > not, it should NEVER include it. > (maybe this should be a MUST in the final RFC) >=20 > So the transition should not happen at all. >=20 >> To change the subject radically, I think the text in sections 9.9 and 9.= 10 fail to make the case for distinct expressions of "expected forwarding t= ime" and "latency." >>=20 >> In the text, EFT is carefully defined. I understand that latency will be= implementation-dependent, but if I were to implement a router or radio wit= h this feature, I have no idea how what I'm expected to calculate/interpret= differs from EFT. After poking around a bit in the list archives, it seems= like EFT is just a really good way to compute latency, in which case it's = not a separate metric but just a really good vendor implementation of Laten= cy. >=20 > Yes, that was my feeling about this too. We need a good specification > what a TLV is about and how it should be generated/interpreted. > Otherwise we will get non-interoperable implementations. Then, I would say "suggest some text". I have a desire to keep the "Latency= " TLV for interoperability with RFC 5578 (the PPPoE extensions). We do have= potential deployments that would use both a PPPoE-based radio, as well as = a DLEP radio. I think that making Latency optional pretty much resolved the= situation - e.g., and implementation is free to use EFT if that is deemed = to be "better".=20 Stan >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From sratliff@cisco.com Tue Oct 9 08:11:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0C521F8550 for ; Tue, 9 Oct 2012 08:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8DsaluRBlqg for ; Tue, 9 Oct 2012 08:11:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 744E421F8480 for ; Tue, 9 Oct 2012 08:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1666; q=dns/txt; s=iport; t=1349795480; x=1351005080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BBSefaG9dYsgSF/tbi8aSBGcZhu/IPp+zChpraRVbXY=; b=ZauIkYrFncb5BlWGg4KLdoHDy7M5dYIVD6C2obMJ6JM9NnYr3pbTbA1h N3ulm7uKxlbSQPRxtXUr5nNLzYDWMlx9jVgZJxoGBUSTh9cHGi5BW92LE 0q+ucCceZwk+1+6nk037sMI4uzCcC1rbe8V86O1uShf/CwKCn/62sRm8l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADw9dFCtJXG+/2dsb2JhbABFvy+BCIIgAQEBAwESASc/BQcEAgEIEQQBAQEKFAkHMhQJCAIEDgUIGodRAwkGm2iPVoZfDYlUilNmhTNgA6QvgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129768691" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 09 Oct 2012 15:11:20 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q99FBKOb019019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 15:11:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:11:19 -0500 From: "Stan Ratliff (sratliff)" To: "Duke, Martin" Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAA== Date: Tue, 9 Oct 2012 15:11:18 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--39.376400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <27EEAA2A5A4B1748A0115DD440762AC2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:11:22 -0000 On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: > RLQ calculation is so loosely defined that it's hard to precisely describ= e how this kind of thing might happen. Latency is a bit easier. But in eith= er case, I can imagine a situation where a radio is RLQ/Latency capable, bu= t it hasn't heard from a neighbor in a while, at least in a way where it ca= n make any sort of reasonable estimate of either quantity. In this case, it= should report to the router a transition from an RLQ of "foo" to an RLQ of= "unknown". Therefore, we need an unknown code point. I'm having a hard time with the notion of a Link Quality that is "unknown".= Seems like a radio would report a quality of "0" (worst case) in that even= t.=20 Stan >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com]=20 > Sent: Tuesday, October 09, 2012 8:03 AM > To: Duke, Martin > Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Stan = Ratliff (sratliff) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wro= te: >> The only concern with reporting an unknown value by simply not including= the TLV is if the link state transitions from a known value to an unknown = value. I'm not sure how often this would happen, but it seems easy enough t= o reserve 255 (or whatever) as an 'unknown' code point. >=20 > If a radio supports RLQ it should ALWAYS include the TLV... if it does no= t, it should NEVER include it. > (maybe this should be a MUST in the final RFC) >=20 > So the transition should not happen at all. >=20 From Martin.Duke@boeing.com Tue Oct 9 08:12:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E394111E810B for ; Tue, 9 Oct 2012 08:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9knVGHk13Shl for ; Tue, 9 Oct 2012 08:12:40 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 54DAF11E80A2 for ; Tue, 9 Oct 2012 08:12:40 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q99FCdIp006393 for ; Tue, 9 Oct 2012 08:12:39 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q99FCdXt006390 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Oct 2012 08:12:39 -0700 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 9 Oct 2012 08:12:39 -0700 From: "Duke, Martin" To: "Stan Ratliff (sratliff)" , Henning Rogge Date: Tue, 9 Oct 2012 08:12:37 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAAB8AD//6xuMA== Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005B5@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005B5@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:12:41 -0000 I would be happy to suggest text if I understood the difference between EFT= and Latency. What is the former trying to capture that isn't a commonly un= derstood part of latency? What would a router do with an EFT report that it= couldn't do with a latency report? If no one can articulate the difference= , then let's just have a latency TLV and be done with it. Martin -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: Tuesday, October 09, 2012 8:10 AM To: Henning Rogge Cc: Duke, Martin; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (bob= erry) Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 9, 2012, at 11:03 AM, Henning Rogge wrote: > On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wro= te: >> The only concern with reporting an unknown value by simply not including= the TLV is if the link state transitions from a known value to an unknown = value. I'm not sure how often this would happen, but it seems easy enough t= o reserve 255 (or whatever) as an 'unknown' code point. >=20 > If a radio supports RLQ it should ALWAYS include the TLV... if it does=20 > not, it should NEVER include it. > (maybe this should be a MUST in the final RFC) >=20 > So the transition should not happen at all. >=20 >> To change the subject radically, I think the text in sections 9.9 and 9.= 10 fail to make the case for distinct expressions of "expected forwarding t= ime" and "latency." >>=20 >> In the text, EFT is carefully defined. I understand that latency will be= implementation-dependent, but if I were to implement a router or radio wit= h this feature, I have no idea how what I'm expected to calculate/interpret= differs from EFT. After poking around a bit in the list archives, it seems= like EFT is just a really good way to compute latency, in which case it's = not a separate metric but just a really good vendor implementation of Laten= cy. >=20 > Yes, that was my feeling about this too. We need a good specification=20 > what a TLV is about and how it should be generated/interpreted. > Otherwise we will get non-interoperable implementations. Then, I would say "suggest some text". I have a desire to keep the "Latency= " TLV for interoperability with RFC 5578 (the PPPoE extensions). We do have= potential deployments that would use both a PPPoE-based radio, as well as = a DLEP radio. I think that making Latency optional pretty much resolved the= situation - e.g., and implementation is free to use EFT if that is deemed = to be "better".=20 Stan >=20 > Henning Rogge >=20 > -- > Steven Hawkings about cosmic inflation: "An increase of billions of=20 > billions of percent in a tiny fraction of a second. Of course, that=20 > was before the present government." From hrogge@googlemail.com Tue Oct 9 08:13:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C949421F865D for ; Tue, 9 Oct 2012 08:13:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf+jLEiinMP2 for ; Tue, 9 Oct 2012 08:13:45 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC28E21F863B for ; Tue, 9 Oct 2012 08:13:45 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so13519715iec.31 for ; Tue, 09 Oct 2012 08:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ol18aA8o0vAjhwxLV/3QZMhSHhU1UseACMItaaLe1sI=; b=Rh2x+97Uaqq0wZnMJZHtAq9QHcKITIE3gl+ZRPWtRm6978KOZu5BC8Ih2VA4UXd6ZO ANKRo0Lw46/uCFaF17ixiMfaDehP71CJIRbgElP+Www0W9Qh3GV1Fe8809TrAm+DBSGp 4/jz25sM9KaNcLD3CV1Z+u2b+UHAtgyF+WVw958ghTrl5LTHCGdkHjvMH9z8qakuioHR nh/hUu9v+yD48/M58g2oS4I0yGz/FKN+spBxY7odAHBJGwm/0wjyOBxzUxGA+mmMf+7G gjw4ezuqmSecWiBLeon2ecty8eMOjsnI/BL9hP0tPumn6q1cQ4ZwGrC1RozVOnjXfNA5 cqow== Received: by 10.50.219.229 with SMTP id pr5mr2019780igc.59.1349795625355; Tue, 09 Oct 2012 08:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.14.41 with HTTP; Tue, 9 Oct 2012 08:13:24 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Tue, 9 Oct 2012 17:13:24 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:13:46 -0000 On Tue, Oct 9, 2012 at 5:10 PM, Stan Ratliff (sratliff) wrote: > Then, I would say "suggest some text". I have a desire to keep the "Laten= cy" TLV for interoperability with RFC 5578 (the PPPoE extensions). We do ha= ve potential deployments that would use both a PPPoE-based radio, as well a= s a DLEP radio. I think that making Latency optional pretty much resolved t= he situation - e.g., and implementation is free to use EFT if that is deeme= d to be "better". I do not even get whats the difference between the two. Can EFT be used to describe the Latency? If yes, maybe dropping the EFT as a TLV of its own and mentioning it as one way of calculation in the Latency TLV might be a good idea. On Tue, Oct 9, 2012 at 5:11 PM, Stan Ratliff (sratliff) wrote: > > On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: > >> RLQ calculation is so loosely defined that it's hard to precisely descri= be how this kind of thing might happen. Latency is a bit easier. But in eit= her case, I can imagine a situation where a radio is RLQ/Latency capable, b= ut it hasn't heard from a neighbor in a while, at least in a way where it c= an make any sort of reasonable estimate of either quantity. In this case, i= t should report to the router a transition from an RLQ of "foo" to an RLQ o= f "unknown". Therefore, we need an unknown code point. > > I'm having a hard time with the notion of a Link Quality that is "unknown= ". Seems like a radio would report a quality of "0" (worst case) in that ev= ent. Or drop the neighbor from the current list if the situation doesn't improve... *nod* Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Martin.Duke@boeing.com Tue Oct 9 08:15:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD421F8668 for ; Tue, 9 Oct 2012 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIYrftRBbG2L for ; Tue, 9 Oct 2012 08:15:55 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCBB21F8646 for ; Tue, 9 Oct 2012 08:15:55 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q99FFsNs012116 for ; Tue, 9 Oct 2012 08:15:54 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q99FFsGn012113 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Oct 2012 08:15:54 -0700 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 9 Oct 2012 08:15:54 -0700 From: "Duke, Martin" To: "Stan Ratliff (sratliff)" Date: Tue, 9 Oct 2012 08:15:52 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQ Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:15:55 -0000 Although I have never implemented a router that uses these metrics, I suspe= ct that I would want to treat RLQ=3D100 links as best for forwarding, RLQ= =3D0 links worst, and RLQ=3Dunknown as somewhere in between. Martin -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: Tuesday, October 09, 2012 8:11 AM To: Duke, Martin Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (bo= berry) Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: > RLQ calculation is so loosely defined that it's hard to precisely describ= e how this kind of thing might happen. Latency is a bit easier. But in eith= er case, I can imagine a situation where a radio is RLQ/Latency capable, bu= t it hasn't heard from a neighbor in a while, at least in a way where it ca= n make any sort of reasonable estimate of either quantity. In this case, it= should report to the router a transition from an RLQ of "foo" to an RLQ of= "unknown". Therefore, we need an unknown code point. I'm having a hard time with the notion of a Link Quality that is "unknown".= Seems like a radio would report a quality of "0" (worst case) in that even= t.=20 Stan >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com]=20 > Sent: Tuesday, October 09, 2012 8:03 AM > To: Duke, Martin > Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Stan = Ratliff (sratliff) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wro= te: >> The only concern with reporting an unknown value by simply not including= the TLV is if the link state transitions from a known value to an unknown = value. I'm not sure how often this would happen, but it seems easy enough t= o reserve 255 (or whatever) as an 'unknown' code point. >=20 > If a radio supports RLQ it should ALWAYS include the TLV... if it does no= t, it should NEVER include it. > (maybe this should be a MUST in the final RFC) >=20 > So the transition should not happen at all. >=20 From teco@inf-net.nl Tue Oct 9 08:23:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE51A21F870E for ; Tue, 9 Oct 2012 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOYlFD0ipCjt for ; Tue, 9 Oct 2012 08:23:22 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05B6821F842A for ; Tue, 9 Oct 2012 08:23:21 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2677359bkc.31 for ; Tue, 09 Oct 2012 08:23:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=KMpGAC62x5VzL0k2UnYMajWfpSEQYCsqCEDh9YCrISs=; b=bGMM0O4LsySRMqNT3VVD+Xg9o3+N1YAgrE0LH7z1MqjOIrbUYy5ITRV/8gxb4rFfdG 9w1QzEMAjD8+lMMYe9q39BGvV8bECetl9rmyjx44jM1DDnPgVMRrRdwZXCR5ywJ7KSDL jTUXFAPsqy+zBDWN9L2wdJ14ByWMLYI3Akxqlz6mq5Dn1rY235tNJo2lfye935At+B99 vpzGzhpZNC6zM6a+enK0JRDDC3AlilpWgObli9bzPb6zWx8kBhSGDVV2Y+rFX6BvRPXa TyL2nkiYbkxqx75+ASHa9UdRpIGtAoKI1ejyUou0K/JoPbsxU6a8HmVc6L3LpXlom58w 4Dtw== Received: by 10.204.9.3 with SMTP id j3mr6962484bkj.15.1349796200927; Tue, 09 Oct 2012 08:23:20 -0700 (PDT) Received: from [10.87.54.145] ([80.187.201.33]) by mx.google.com with ESMTPS id 1sm12417228bks.3.2012.10.09.08.23.18 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 08:23:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 9 Oct 2012 17:23:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8048F5D4-4A95-4BE0-ADAA-0724C8796A91@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005B5@xmb-aln-x03.cisco.com> To: "Duke, Martin" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQn56zhiIdpyCF7CQEOTzL4T6PNBh09X+nbQpfejxZkcDUa66BrZzpfyF6Wl2tBlAS1yjvvF Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:23:22 -0000 Op 9 okt. 2012, om 17:12 heeft Duke, Martin het volgende geschreven: > I would be happy to suggest text if I understood the difference = between EFT and Latency. What is the former trying to capture that isn't = a commonly understood part of latency? What would a router do with an = EFT report that it couldn't do with a latency report? If no one can = articulate the difference, then let's just have a latency TLV and be = done with it. We need normative text or pointer to such. Diff could be counting = queueing delay, or not. Another: retransmit time, or not.=20 An old suggestion, that didn't make it in dlep yet: airtime, as clearly = specified in 802.11_2012. Teco From hrogge@googlemail.com Tue Oct 9 08:32:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AFE21F874F for ; Tue, 9 Oct 2012 08:32:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpW0oevNKxgn for ; Tue, 9 Oct 2012 08:32:14 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6B7D21F873C for ; Tue, 9 Oct 2012 08:32:14 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so1056297iad.31 for ; Tue, 09 Oct 2012 08:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=TN6yxTmrOdu9KcR4YNDkJP9tiTXMA+qypPttddCINVY=; b=U893adVl1KP5cjn9gOSzNPdF3QbmakdpZL8QmK2pKDEwXWkDqCsNmvC3P50IBOrwNs REcUR4nlr0EYmgcnQnOEhNha81EMniBFN82rGnRdjuSSjGebpeExVNETyzI+n5BRRgFt BfU6YEQeCMRwro16LSwUpntusoea9SOK10bbukJiWv3KDLVHwENDTpxgL+z7TngHfgWP 1ODEyOtvct0ZygVWaHTTr0y6FvIAtMxcpmSxcvV7YbjhihOMH3cbaOXaMNO7+BET/hgv K9H6UG5qoX8rpIOfCJ44g3OOi6R1sn+0B+bQPM+vP9MBV8flb5dTaReLjo89S8E9Tzre jtqg== Received: by 10.50.151.238 with SMTP id ut14mr2052999igb.58.1349796734253; Tue, 09 Oct 2012 08:32:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.14.41 with HTTP; Tue, 9 Oct 2012 08:31:54 -0700 (PDT) In-Reply-To: <8048F5D4-4A95-4BE0-ADAA-0724C8796A91@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005B5@xmb-aln-x03.cisco.com> <8048F5D4-4A95-4BE0-ADAA-0724C8796A91@inf-net.nl> From: Henning Rogge Date: Tue, 9 Oct 2012 17:31:54 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "Dearlove, Christopher \(UK\)" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:32:15 -0000 On Tue, Oct 9, 2012 at 5:23 PM, Teco Boot wrote: > > Op 9 okt. 2012, om 17:12 heeft Duke, Martin het volgende geschreven: > >> I would be happy to suggest text if I understood the difference between = EFT and Latency. What is the former trying to capture that isn't a commonly= understood part of latency? What would a router do with an EFT report that= it couldn't do with a latency report? If no one can articulate the differe= nce, then let's just have a latency TLV and be done with it. > > We need normative text or pointer to such. Diff could be counting queuein= g delay, or not. Another: retransmit time, or not. > > An old suggestion, that didn't make it in dlep yet: airtime, as clearly s= pecified in 802.11_2012. There are quite a few useful values even a primitive Linux wificard will supply that cannot be expressed at the moment. Having a standardized way to express them (as optional TLVs) would further improve interoperability. Its a scary idea that several companies will create TLVs with the same "concept" (airtime for example) but use different encodings and different "private metric types". Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Tue Oct 9 08:34:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEC511E8122 for ; Tue, 9 Oct 2012 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+pOH9Uh9uYH for ; Tue, 9 Oct 2012 08:34:55 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 780DC11E80DF for ; Tue, 9 Oct 2012 08:34:55 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 38124557FC4 for ; Tue, 9 Oct 2012 08:34:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D7B141C0688; Tue, 9 Oct 2012 08:34:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 06DD11C0136; Tue, 9 Oct 2012 08:34:52 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7B1A2B4A-4C52-43CE-9135-2F39E6F2A321@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 17:34:50 +0200 To: Henning Rogge Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:34:56 -0000 On 9 oct. 2012, at 17:13, Henning Rogge wrote: > On Tue, Oct 9, 2012 at 5:10 PM, Stan Ratliff (sratliff) > wrote: >> Then, I would say "suggest some text". I have a desire to keep the "Laten= cy" TLV for interoperability with RFC 5578 (the PPPoE extensions). We do hav= e potential deployments that would use both a PPPoE-based radio, as well as a= DLEP radio. I think that making Latency optional pretty much resolved the s= ituation - e.g., and implementation is free to use EFT if that is deemed to b= e "better". >=20 > I do not even get whats the difference between the two. >=20 > Can EFT be used to describe the Latency? If yes, maybe dropping the > EFT as a TLV of its own and mentioning it as one way of calculation in > the Latency TLV might be a good idea. >=20 I will articulate this ever so slightly differently. What would a device do *differently* when receiving a LatencyTLV, depending o= n if the value was calculated using EFT or something else? If the answer is "nothing", then we should probably have just the LatencyTLV= . If the answer is "something", then we should want to have that "something" d= etailed.=20 If the answer is "mostly nothing, but it is good to know how it is calculate= d for XXX other reason(s)", then perhaps a LatencyTLV with a field (LatencyT= ype) and an associated IANA registry for that field would be a good idea? I admit, I do not know enough about this myself, to have the answer immediat= ely available, but those would be questions I'd like to see answered on this= point. Best, Thomas > On Tue, Oct 9, 2012 at 5:11 PM, Stan Ratliff (sratliff) > wrote: >>=20 >> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>=20 >>> RLQ calculation is so loosely defined that it's hard to precisely descri= be how this kind of thing might happen. Latency is a bit easier. But in eith= er case, I can imagine a situation where a radio is RLQ/Latency capable, but= it hasn't heard from a neighbor in a while, at least in a way where it can m= ake any sort of reasonable estimate of either quantity. In this case, it sho= uld report to the router a transition from an RLQ of "foo" to an RLQ of "unk= nown". Therefore, we need an unknown code point. >>=20 >> I'm having a hard time with the notion of a Link Quality that is "unknown= ". Seems like a radio would report a quality of "0" (worst case) in that eve= nt. >=20 > Or drop the neighbor from the current list if the situation doesn't > improve... *nod* >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Tue Oct 9 08:36:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386BA11E812A for ; Tue, 9 Oct 2012 08:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D-Aa4fle47T for ; Tue, 9 Oct 2012 08:36:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A125211E811A for ; Tue, 9 Oct 2012 08:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=199; q=dns/txt; s=iport; t=1349796965; x=1351006565; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0qDm3Zp4uWtgu79oUBqCwrj3KuMHSFes+Nu5+n1Tlqw=; b=ItT69EsIxqD1uxLBL1Dl9s+Cai6kEBZcQPsURSs4yGL+WM/a+W3ybElF 6ckl2k9hqs9NPpDcC6d6Gmd62FnP67NxXFmoUckJZfPM1eXuEn2wKslWB v5FM+Hul3FccUS+CpQbuHapVP+m31U2wyhdaY7SKXH4dZxUBRUY1lCNCh w=; X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129763761" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 09 Oct 2012 15:36:05 +0000 Received: from dhcp-10-150-22-110.cisco.com (dhcp-10-150-22-110.cisco.com [10.150.22.110]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q99Fa4SS016578; Tue, 9 Oct 2012 15:36:05 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Tue, 9 Oct 2012 11:36:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005B5@xmb-aln-x03.cisco.com> <8048F5D4-4A95-4BE0-ADAA-0724C8796A91@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:36:08 -0000 All, just a happy note to acknowledge the diversity of discussion from the WG. -Bo --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From hrogge@googlemail.com Tue Oct 9 08:36:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0594711E8126 for ; Tue, 9 Oct 2012 08:36: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4hAPHaad5Ec for ; Tue, 9 Oct 2012 08:36:47 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2411E80DF for ; Tue, 9 Oct 2012 08:36:47 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so13574307iec.31 for ; Tue, 09 Oct 2012 08:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZZLKNMWDwzKJrC2qtY0XN1ugRcQGiEm8R6KHdvfC3oo=; b=TAnmMBxrMIXWCQPHmct46DcPa7rs8ds0V8OoR10/sKlO1FM3UMTkGfdb2fcpywmBPj W0rezjQfck4V3TNr83voZou+GRf7t0vkgyM/8CKBBls3z6eHA/bHNrLqd1l3A2VfbpMv +fALZEGMTeYmrlCpPnvT5Eym1yhLa7QDuAfxUDsuMnv05ZYQccXj6ZMDo+Xs3mA6nCeq cZENzJRgmcVI7+JOjP7O7bpnP5KcHHadGugChKX4kM8hbKrJdLeUPBrLw58b6FFF/l8H zrUa2lCoA0JZQ+/dffWL+/gYc7JW6oJ6ebHNWY24gs0kVZhHjWvTVQ9LjlzyD7AS4ehj 3smg== Received: by 10.50.151.238 with SMTP id ut14mr2070229igb.58.1349797006790; Tue, 09 Oct 2012 08:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.14.41 with HTTP; Tue, 9 Oct 2012 08:36:26 -0700 (PDT) In-Reply-To: <7B1A2B4A-4C52-43CE-9135-2F39E6F2A321@thomasclausen.org> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <7B1A2B4A-4C52-43CE-9135-2F39E6F2A321@thomasclausen.org> From: Henning Rogge Date: Tue, 9 Oct 2012 17:36:26 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:36:48 -0000 On Tue, Oct 9, 2012 at 5:34 PM, Thomas Heide Clausen wrote: > > On 9 oct. 2012, at 17:13, Henning Rogge wrote: > > If the answer is "mostly nothing, but it is good to know how it is calculated for XXX other reason(s)", then perhaps a LatencyTLV with a field (LatencyType) and an associated IANA registry for that field would be a good idea? That sounds like a TLV extension type... ;) Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Tue Oct 9 08:38:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D6A11E8126 for ; Tue, 9 Oct 2012 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W98B6r76tklj for ; Tue, 9 Oct 2012 08:38:15 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4252111E8122 for ; Tue, 9 Oct 2012 08:38:15 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 361F1557FBA for ; Tue, 9 Oct 2012 08:38:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C88561BD5E28; Tue, 9 Oct 2012 08:38:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 00A3D1BD5DE0; Tue, 9 Oct 2012 08:38:13 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 17:38:12 +0200 To: "Duke, Martin" Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:38:15 -0000 On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: > Although I have never implemented a router that uses these metrics, I susp= ect that I would want to treat RLQ=3D100 links as best for forwarding, RLQ=3D= 0 links worst, and RLQ=3Dunknown as somewhere in between. >=20 I'm in somewhat of the same boat as you, experience-wise but my conclusions w= ould be somewhat different: RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "use a l= ink with known characteristics, even if not with RLQ=3DMAXVALUE" over using a= link with entirely unknown characteristics. At least, using a link with known characteristics could allow (for example) p= arametrizing the traffic to something guaranteed to "fit" over the link.....= I do not know if that is a realistic usecase or not (I know that I've deploy= ed something where it made sense like that for L3 routing) Thomas > Martin >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: Tuesday, October 09, 2012 8:11 AM > To: Duke, Martin > Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (b= oberry) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 >=20 > On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >=20 >> RLQ calculation is so loosely defined that it's hard to precisely describ= e how this kind of thing might happen. Latency is a bit easier. But in eithe= r case, I can imagine a situation where a radio is RLQ/Latency capable, but i= t hasn't heard from a neighbor in a while, at least in a way where it can ma= ke any sort of reasonable estimate of either quantity. In this case, it shou= ld report to the router a transition from an RLQ of "foo" to an RLQ of "unkn= own". Therefore, we need an unknown code point. >=20 > I'm having a hard time with the notion of a Link Quality that is "unknown"= . Seems like a radio would report a quality of "0" (worst case) in that even= t.=20 >=20 > Stan >=20 >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >> Sent: Tuesday, October 09, 2012 8:03 AM >> To: Duke, Martin >> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Stan R= atliff (sratliff) >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wro= te: >>> The only concern with reporting an unknown value by simply not including= the TLV is if the link state transitions from a known value to an unknown v= alue. I'm not sure how often this would happen, but it seems easy enough to r= eserve 255 (or whatever) as an 'unknown' code point. >>=20 >> If a radio supports RLQ it should ALWAYS include the TLV... if it does no= t, it should NEVER include it. >> (maybe this should be a MUST in the final RFC) >>=20 >> So the transition should not happen at all. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Tue Oct 9 08:41:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F2621F85AE for ; Tue, 9 Oct 2012 08:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGi1mdhTZ0ce for ; Tue, 9 Oct 2012 08:41:05 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68121F85A8 for ; Tue, 9 Oct 2012 08:41:05 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 060F0557F8B for ; Tue, 9 Oct 2012 08:41:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8746D1BD5EB5; Tue, 9 Oct 2012 08:41:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 004EC1BD5EB3; Tue, 9 Oct 2012 08:41:02 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005B5@xmb-aln-x03.cisco.com> <8048F5D4-4A95-4BE0-ADAA-0724C8796A91@inf-net.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <40E63F58-1E7E-43BD-B1BE-70FF6630E071@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 17:41:02 +0200 To: Henning Rogge Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:41:05 -0000 On 9 oct. 2012, at 17:31, Henning Rogge wrote: > On Tue, Oct 9, 2012 at 5:23 PM, Teco Boot wrote: >>=20 >> Op 9 okt. 2012, om 17:12 heeft Duke, Martin het volgende geschreven: >>=20 >>> I would be happy to suggest text if I understood the difference between E= FT and Latency. What is the former trying to capture that isn't a commonly u= nderstood part of latency? What would a router do with an EFT report that it= couldn't do with a latency report? If no one can articulate the difference,= then let's just have a latency TLV and be done with it. >>=20 >> We need normative text or pointer to such. Diff could be counting queuein= g delay, or not. Another: retransmit time, or not. >>=20 >> An old suggestion, that didn't make it in dlep yet: airtime, as clearly s= pecified in 802.11_2012. >=20 > There are quite a few useful values even a primitive Linux wificard > will supply that cannot be expressed at the moment. Having a > standardized way to express them (as optional TLVs) would further > improve interoperability. >=20 > Its a scary idea that several companies will create TLVs with the same > "concept" (airtime for example) but use different encodings and > different "private metric types". >=20 Stating the obvious here, but that - to me - indicates: o An IANA registry o A sufficiently large field (code-point space - is 1 octet g= oing to be enough?) o A requirement for getting a code-point from that registry b= eing the existence of an RFC, stipulating how the values are calculated, encod= ed and interpreted Best, Thomas > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Tue Oct 9 08:45:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FA311E8114 for ; Tue, 9 Oct 2012 08:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMuJTwZBdiDM for ; Tue, 9 Oct 2012 08:45:13 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D08B411E80D1 for ; Tue, 9 Oct 2012 08:45:12 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id A96AD558032 for ; Tue, 9 Oct 2012 08:45:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 489D11BD5FD8; Tue, 9 Oct 2012 08:45:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B15F11BD5FD7; Tue, 9 Oct 2012 08:45:11 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 17:45:11 +0200 To: Henning Rogge Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:45:14 -0000 Sent from my iPad On 9 oct. 2012, at 16:42, Henning Rogge wrote: > On Tue, Oct 9, 2012 at 4:41 PM, Dearlove, Christopher (UK) > wrote: >> There has been some discussion about 0-100 or 0-255. Why not reserve 255 f= or unknown (treat as X for X not necessarily equal to 255) and use 0-100 or 0= -254, or even use 0-127 (or 0-100) and MSB set says "actually unknown". >>=20 >> (Apologies if I have mixed up two things incorrectly here.) >>=20 >> If you do use anything not full range, what do you do if you get another v= alue? If discard, discard what? >=20 > Everyone agrees we want to have a TLV value. Why put an "unknown" > value into it if we can just skip the whole TLV? >=20 Might the presence of a TLV with an unknown value serve to say "I do not kno= w yet, but will soon" to the other end have some semantic value? I will take an example that I know, but which is not in itself relevant (So t= ake it as just an illustrative point): security. There's a difference betwee= n saying "I do not have the ability to establish a security association" (no= TLV) and "I have not yet been able to establish a security association" (TL= V with unknown). In the former case, on might a priori discard the link, in t= he latter try to set it up? Again, this is just an illustrative point, I do not know if there's somethin= g of that kind in this precise scenario? Thomas > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Oct 9 08:47:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B344F11E8140 for ; Tue, 9 Oct 2012 08:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAvxmoxvXz12 for ; Tue, 9 Oct 2012 08:47:48 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2A0F11E8137 for ; Tue, 9 Oct 2012 08:47:45 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so13600545iec.31 for ; Tue, 09 Oct 2012 08:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9lBYjcPA0qQ4yraDjGbDTNKzDClnlU+obGWFJEOo7+s=; b=VKfOKA063mgm6529dOfX2xzKMQy7CQfunQ/mxKK6zUsVEz6tdFshG6x0xUGN0KAmZu iQfYcUZGz8jfg/yCX47rAisuuOo+auuJoxGg6oCvzIDftszz5043R7R9neD5VQQKvynd Ol+/1OPGCKuAuxWHE/liQjfQr+wQi30QZbU4Y4gVlUn3yTb92qcu9ECibKC0NxafdPCL R1NAl+vIQdMeRs7i4LwiD637SBsWn5MFzF2I+bOO1TtKEUeBSr3scxshQAA+7kXxtoQ6 /pNjYIP60yUE5rpbG1WvvGTCMCHaqHnQUO/KTcbCvUQfc1SC8SZMC5kardQiJNEDsoO3 m8/g== Received: by 10.50.153.137 with SMTP id vg9mr984769igb.40.1349797662060; Tue, 09 Oct 2012 08:47:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.14.41 with HTTP; Tue, 9 Oct 2012 08:47:21 -0700 (PDT) In-Reply-To: <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> From: Henning Rogge Date: Tue, 9 Oct 2012 17:47:21 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: "Stan Ratliff \(sratliff\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:47:50 -0000 On Tue, Oct 9, 2012 at 5:38 PM, Thomas Heide Clausen wrote: > > On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: > >> Although I have never implemented a router that uses these metrics, I suspect that I would want to treat RLQ=100 links as best for forwarding, RLQ=0 links worst, and RLQ=unknown as somewhere in between. >> > > I'm in somewhat of the same boat as you, experience-wise but my conclusions would be somewhat different: > > RLQ=MAXVALUE would be best, RLQ=0 worst. > > RLQ=UNKNOWN, I might imagine that one could envision to prefer to "use a link with known characteristics, even if not with RLQ=MAXVALUE" over using a link with entirely unknown characteristics. > > At least, using a link with known characteristics could allow (for example) parametrizing the traffic to something guaranteed to "fit" over the link..... > > I do not know if that is a realistic usecase or not (I know that I've deployed something where it made sense like that for L3 routing) I wonder if adding a complete "LINK_STATUS" similar to the one in NHDP would make sense... "HEARD", "SYMMETRIC", "LOST" or even "PENDING" might make sense for some Linklayers. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Tue Oct 9 08:49:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8EA11E813A for ; Tue, 9 Oct 2012 08:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9LUhblduUu7 for ; Tue, 9 Oct 2012 08:49:29 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A670011E8134 for ; Tue, 9 Oct 2012 08:49:26 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 6B7E7558033 for ; Tue, 9 Oct 2012 08:49:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F044E1BD610C; Tue, 9 Oct 2012 08:49:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 517F41BD610A; Tue, 9 Oct 2012 08:49:24 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB4 59FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <7B1A2B4A-4C52-43CE-9135-2F39E6F2A321@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 17:49:25 +0200 To: Henning Rogge Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:49:31 -0000 On 9 oct. 2012, at 17:36, Henning Rogge wrote: > On Tue, Oct 9, 2012 at 5:34 PM, Thomas Heide Clausen > wrote: >>=20 >> On 9 oct. 2012, at 17:13, Henning Rogge wrote: >>=20 >> If the answer is "mostly nothing, but it is good to know how it is calcul= ated for XXX other reason(s)", then perhaps a LatencyTLV with a field (Laten= cyType) and an associated IANA registry for that field would be a good idea?= >=20 > That sounds like a TLV extension type... ;) >=20 Yes, it does. I wonder where that idea came from ;) > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From sratliff@cisco.com Tue Oct 9 09:23:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6221F85C2 for ; Tue, 9 Oct 2012 09:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.943 X-Spam-Level: X-Spam-Status: No, score=-9.943 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CER-MGulE17 for ; Tue, 9 Oct 2012 09:23:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9621F85B1 for ; Tue, 9 Oct 2012 09:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4163; q=dns/txt; s=iport; t=1349799832; x=1351009432; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pbj+hTUXyILIO7HIAanzPNn3WT0yyZWLO1BjRxx96Yg=; b=dyqoaJTD6rQC6UuRRKVyRrJSjSRmZq4mxgvnN98YOiCaF6Tx3bC37Kol sl+IkZcge02TnrJEGsxUkf6SXJX6Z3TZLFoj4HUAdX5jvpbFQ7kiwhVqZ MfXS1QwG0PHgYkIB2zcBBuiYoO/a4h7fVGDC5WQr+n/8P4LJ3Fd1dE0Cm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIBOdFCtJXG9/2dsb2JhbABFvy+BCIIgAQEBAwEBAQEPAVsLBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIGodRAwkGC5t5j1aGWg2JUASKU2aFM2ADpC+Ba4Jtghc X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129817743" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 09 Oct 2012 16:23:51 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q99GNpGh027379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 16:23:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 11:23:51 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAA== Date: Tue, 9 Oct 2012 16:23:51 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> In-Reply-To: <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--45.132900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <15E60C34A56F7E408B9BFE8BEFA6BCFF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:23:52 -0000 On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >=20 > On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: >=20 >> Although I have never implemented a router that uses these metrics, I su= spect that I would want to treat RLQ=3D100 links as best for forwarding, RL= Q=3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>=20 >=20 > I'm in somewhat of the same boat as you, experience-wise but my conclusio= ns would be somewhat different: >=20 > RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >=20 > RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "use= a link with known characteristics, even if not with RLQ=3DMAXVALUE" over u= sing a link with entirely unknown characteristics. >=20 > At least, using a link with known characteristics could allow (for exampl= e) parametrizing the traffic to something guaranteed to "fit" over the link= ..... >=20 > I do not know if that is a realistic usecase or not (I know that I've dep= loyed something where it made sense like that for L3 routing) >=20 Well, having implemented a DLEP router that uses the metrics, I don't under= stand what I'd do with an "Unknown" value=85 Just on a purely esoteric leve= l, Thomas has a point in that there's a difference between "I can't calcula= te RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet." = To extend that definition slightly, from the router's perspective, leads me= to trying to deal (in general) with the notion of the radio telling the ro= uter: "I have a new neighbor! However, I don't have the foggiest notion as = to what the link characteristics are to said neighbor. Have a nice day!" A= gain, just from the perspective of the router, I'm tempted to want to respo= nd to that by effectively saying "Call me when you figure it out=85" Maybe = I'm not seeing the forest for all of these trees=85=20 Regards, Stan > Thomas >=20 >> Martin >>=20 >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >> Sent: Tuesday, October 09, 2012 8:11 AM >> To: Duke, Martin >> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry = (boberry) >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >>=20 >> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>=20 >>> RLQ calculation is so loosely defined that it's hard to precisely descr= ibe how this kind of thing might happen. Latency is a bit easier. But in ei= ther case, I can imagine a situation where a radio is RLQ/Latency capable, = but it hasn't heard from a neighbor in a while, at least in a way where it = can make any sort of reasonable estimate of either quantity. In this case, = it should report to the router a transition from an RLQ of "foo" to an RLQ = of "unknown". Therefore, we need an unknown code point. >>=20 >> I'm having a hard time with the notion of a Link Quality that is "unknow= n". Seems like a radio would report a quality of "0" (worst case) in that e= vent.=20 >>=20 >> Stan >>=20 >>>=20 >>> -----Original Message----- >>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>> Sent: Tuesday, October 09, 2012 8:03 AM >>> To: Duke, Martin >>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Sta= n Ratliff (sratliff) >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin w= rote: >>>> The only concern with reporting an unknown value by simply not includi= ng the TLV is if the link state transitions from a known value to an unknow= n value. I'm not sure how often this would happen, but it seems easy enough= to reserve 255 (or whatever) as an 'unknown' code point. >>>=20 >>> If a radio supports RLQ it should ALWAYS include the TLV... if it does = not, it should NEVER include it. >>> (maybe this should be a MUST in the final RFC) >>>=20 >>> So the transition should not happen at all. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From Martin.Duke@boeing.com Tue Oct 9 09:30:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6111F0C8C for ; Tue, 9 Oct 2012 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gKeE6Mo2ZZC for ; Tue, 9 Oct 2012 09:30:11 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 46CC221F8554 for ; Tue, 9 Oct 2012 09:30:11 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q99GUAoK004036 for ; Tue, 9 Oct 2012 09:30:10 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q99GU9x1004021 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Oct 2012 09:30:09 -0700 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 9 Oct 2012 09:30:09 -0700 From: "Duke, Martin" To: "Stan Ratliff (sratliff)" , Thomas Heide Clausen Date: Tue, 9 Oct 2012 09:30:08 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAP//rH4A Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:30:12 -0000 Perhaps I've missed an email, but I think the choices we're debating are (1) Radios that don't have an RLQ estimate MUST NOT send an RLQ TLV; or (2) Those radios MAY send an RLQ TLV with code UNKNOWN. I think the case where a radio is taking time to acquire an estimate is han= dled well using either design; it just starts adding the TLV whenever it ha= s an estimate. The case that isn't handled is if the radio loses that abili= ty for one reason or another. In (1) I don't see any obvious syntax to expl= ain that there is no longer a good estimate. You could say that this is a corner case, and you'd be right. But the cost = of this is RLQ field code points that we're not using anyway and a couple o= f lines of text in the spec. So why not support it? Martin -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: Tuesday, October 09, 2012 9:24 AM To: Thomas Heide Clausen Cc: Duke, Martin; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (bob= erry) Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >=20 > On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: >=20 >> Although I have never implemented a router that uses these metrics, I su= spect that I would want to treat RLQ=3D100 links as best for forwarding, RL= Q=3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>=20 >=20 > I'm in somewhat of the same boat as you, experience-wise but my conclusio= ns would be somewhat different: >=20 > RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >=20 > RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "use= a link with known characteristics, even if not with RLQ=3DMAXVALUE" over u= sing a link with entirely unknown characteristics. >=20 > At least, using a link with known characteristics could allow (for exampl= e) parametrizing the traffic to something guaranteed to "fit" over the link= ..... >=20 > I do not know if that is a realistic usecase or not (I know that I've dep= loyed something where it made sense like that for L3 routing) >=20 Well, having implemented a DLEP router that uses the metrics, I don't under= stand what I'd do with an "Unknown" value... Just on a purely esoteric leve= l, Thomas has a point in that there's a difference between "I can't calcula= te RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet." = To extend that definition slightly, from the router's perspective, leads me= to trying to deal (in general) with the notion of the radio telling the ro= uter: "I have a new neighbor! However, I don't have the foggiest notion as = to what the link characteristics are to said neighbor. Have a nice day!" A= gain, just from the perspective of the router, I'm tempted to want to respo= nd to that by effectively saying "Call me when you figure it out..." Maybe = I'm not seeing the forest for all of these trees...=20 Regards, Stan > Thomas >=20 >> Martin >>=20 >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >> Sent: Tuesday, October 09, 2012 8:11 AM >> To: Duke, Martin >> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry = (boberry) >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >>=20 >> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>=20 >>> RLQ calculation is so loosely defined that it's hard to precisely descr= ibe how this kind of thing might happen. Latency is a bit easier. But in ei= ther case, I can imagine a situation where a radio is RLQ/Latency capable, = but it hasn't heard from a neighbor in a while, at least in a way where it = can make any sort of reasonable estimate of either quantity. In this case, = it should report to the router a transition from an RLQ of "foo" to an RLQ = of "unknown". Therefore, we need an unknown code point. >>=20 >> I'm having a hard time with the notion of a Link Quality that is "unknow= n". Seems like a radio would report a quality of "0" (worst case) in that e= vent.=20 >>=20 >> Stan >>=20 >>>=20 >>> -----Original Message----- >>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>> Sent: Tuesday, October 09, 2012 8:03 AM >>> To: Duke, Martin >>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Sta= n Ratliff (sratliff) >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin w= rote: >>>> The only concern with reporting an unknown value by simply not includi= ng the TLV is if the link state transitions from a known value to an unknow= n value. I'm not sure how often this would happen, but it seems easy enough= to reserve 255 (or whatever) as an 'unknown' code point. >>>=20 >>> If a radio supports RLQ it should ALWAYS include the TLV... if it does = not, it should NEVER include it. >>> (maybe this should be a MUST in the final RFC) >>>=20 >>> So the transition should not happen at all. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From Martin.Duke@boeing.com Tue Oct 9 09:33:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C7F11E8137 for ; Tue, 9 Oct 2012 09:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZQahBSJVwym for ; Tue, 9 Oct 2012 09:33:06 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 572E011E8097 for ; Tue, 9 Oct 2012 09:33:06 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q99GX5Xf006456 for ; Tue, 9 Oct 2012 09:33:06 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q99GX5sS006433 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Oct 2012 09:33:05 -0700 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 9 Oct 2012 09:33:05 -0700 From: "Duke, Martin" To: "Stan Ratliff (sratliff)" , Thomas Heide Clausen Date: Tue, 9 Oct 2012 09:33:04 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAP//rmnQ Message-ID: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:33:07 -0000 And as for "not knowing" how we would handle code UNKNOWN: I don't really k= now either, though I have my biases. But why not allow router vendors to in= novate here? Maybe I know what the radio type is, and have a heuristic for = RLQ in the absence of radio data. Martin -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: Tuesday, October 09, 2012 9:24 AM To: Thomas Heide Clausen Cc: Duke, Martin; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (bob= erry) Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >=20 > On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: >=20 >> Although I have never implemented a router that uses these metrics, I su= spect that I would want to treat RLQ=3D100 links as best for forwarding, RL= Q=3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>=20 >=20 > I'm in somewhat of the same boat as you, experience-wise but my conclusio= ns would be somewhat different: >=20 > RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >=20 > RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "use= a link with known characteristics, even if not with RLQ=3DMAXVALUE" over u= sing a link with entirely unknown characteristics. >=20 > At least, using a link with known characteristics could allow (for exampl= e) parametrizing the traffic to something guaranteed to "fit" over the link= ..... >=20 > I do not know if that is a realistic usecase or not (I know that I've dep= loyed something where it made sense like that for L3 routing) >=20 Well, having implemented a DLEP router that uses the metrics, I don't under= stand what I'd do with an "Unknown" value... Just on a purely esoteric leve= l, Thomas has a point in that there's a difference between "I can't calcula= te RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet." = To extend that definition slightly, from the router's perspective, leads me= to trying to deal (in general) with the notion of the radio telling the ro= uter: "I have a new neighbor! However, I don't have the foggiest notion as = to what the link characteristics are to said neighbor. Have a nice day!" A= gain, just from the perspective of the router, I'm tempted to want to respo= nd to that by effectively saying "Call me when you figure it out..." Maybe = I'm not seeing the forest for all of these trees...=20 Regards, Stan > Thomas >=20 >> Martin >>=20 >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >> Sent: Tuesday, October 09, 2012 8:11 AM >> To: Duke, Martin >> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry = (boberry) >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >>=20 >> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>=20 >>> RLQ calculation is so loosely defined that it's hard to precisely descr= ibe how this kind of thing might happen. Latency is a bit easier. But in ei= ther case, I can imagine a situation where a radio is RLQ/Latency capable, = but it hasn't heard from a neighbor in a while, at least in a way where it = can make any sort of reasonable estimate of either quantity. In this case, = it should report to the router a transition from an RLQ of "foo" to an RLQ = of "unknown". Therefore, we need an unknown code point. >>=20 >> I'm having a hard time with the notion of a Link Quality that is "unknow= n". Seems like a radio would report a quality of "0" (worst case) in that e= vent.=20 >>=20 >> Stan >>=20 >>>=20 >>> -----Original Message----- >>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>> Sent: Tuesday, October 09, 2012 8:03 AM >>> To: Duke, Martin >>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Sta= n Ratliff (sratliff) >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin w= rote: >>>> The only concern with reporting an unknown value by simply not includi= ng the TLV is if the link state transitions from a known value to an unknow= n value. I'm not sure how often this would happen, but it seems easy enough= to reserve 255 (or whatever) as an 'unknown' code point. >>>=20 >>> If a radio supports RLQ it should ALWAYS include the TLV... if it does = not, it should NEVER include it. >>> (maybe this should be a MUST in the final RFC) >>>=20 >>> So the transition should not happen at all. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Oct 9 09:44:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BB01F0C91 for ; Tue, 9 Oct 2012 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.909 X-Spam-Level: X-Spam-Status: No, score=-9.909 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYPbgBaPSAMH for ; Tue, 9 Oct 2012 09:44:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 344271F0C8C for ; Tue, 9 Oct 2012 09:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6586; q=dns/txt; s=iport; t=1349801077; x=1351010677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HVViAjhwOoCibNgAouipThHCzRiSWjdz849X198knmw=; b=NH/d3UwX4IlIGfWtY/WDUAa0MmE94HcVW8tJtPx/4bzOyvDoPApqrij6 qNdArsuwcudrgIyhEVX2aSnzxYjIA1mYD0nTI6oq8FCtjyQhG2UdJKanv uEopt87/Ytg8LSpjJf84dSxqimYthNo7yqboAfTaJMQ1DMr8NY2PQgwDM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABtTdFCtJXG//2dsb2JhbABFvy+BCIIgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQgah1EDCQYLm3iPVoZcDYlQBIpTZoUzYAOkL4Frgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129856970" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2012 16:44:36 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q99GiaOs004192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 16:44:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 11:44:36 -0500 From: "Stan Ratliff (sratliff)" To: "Duke, Martin" Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAP//rH4AgABZToA= Date: Tue, 9 Oct 2012 16:44:36 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400AE9@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--56.752900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9C2F3FDF6E88AF4591FA834A0434C63F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:44:38 -0000 On Oct 9, 2012, at 12:30 PM, Duke, Martin wrote: > Perhaps I've missed an email, but I think the choices we're debating are > (1) Radios that don't have an RLQ estimate MUST NOT send an RLQ TLV; or > (2) Those radios MAY send an RLQ TLV with code UNKNOWN. >=20 > I think the case where a radio is taking time to acquire an estimate is h= andled well using either design; it just starts adding the TLV whenever it = has an estimate. The case that isn't handled is if the radio loses that abi= lity for one reason or another. In (1) I don't see any obvious syntax to ex= plain that there is no longer a good estimate. >=20 > You could say that this is a corner case, and you'd be right. But the cos= t of this is RLQ field code points that we're not using anyway and a couple= of lines of text in the spec. So why not support it? I haven't specifically said I'm against the idea. I've said I don't underst= and it. I'm trying to avoid future emails, from people that haven't yet en= gaged in the DLEP debate, that say "Unknown? Why did you do something like = that? What would I use this for? This could potentially cause interoperabil= ity problems." Looking at Thomas' case below, specifically:=20 >> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "us= e a link with known characteristics, even if not with RLQ=3DMAXVALUE" over = using a link with entirely unknown characteristics. >=20 It seems to me that a radio could (should?) report this "unknown" value as = RLQ=3DWORST_VALUE, or 0. At least in my implementation, that would make the= link "the link of last resort", which is what I think everyone is looking = for.=20 Having said all of that, I do agree with you that it doesn't take much to s= upport "Unknown", except that I would be looking for text suggestions to cl= early explain the "We just put this in to allow for innovation, and we're n= ot sure what you'd use it for" arguments.=20 Regards, Stan >=20 > Martin >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: Tuesday, October 09, 2012 9:24 AM > To: Thomas Heide Clausen > Cc: Duke, Martin; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (b= oberry) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 >=20 > On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >=20 >>=20 >> On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: >>=20 >>> Although I have never implemented a router that uses these metrics, I s= uspect that I would want to treat RLQ=3D100 links as best for forwarding, R= LQ=3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>>=20 >>=20 >> I'm in somewhat of the same boat as you, experience-wise but my conclusi= ons would be somewhat different: >>=20 >> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>=20 >> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "us= e a link with known characteristics, even if not with RLQ=3DMAXVALUE" over = using a link with entirely unknown characteristics. >>=20 >> At least, using a link with known characteristics could allow (for examp= le) parametrizing the traffic to something guaranteed to "fit" over the lin= k..... >>=20 >> I do not know if that is a realistic usecase or not (I know that I've de= ployed something where it made sense like that for L3 routing) >>=20 >=20 > Well, having implemented a DLEP router that uses the metrics, I don't und= erstand what I'd do with an "Unknown" value... Just on a purely esoteric le= vel, Thomas has a point in that there's a difference between "I can't calcu= late RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet.= " To extend that definition slightly, from the router's perspective, leads = me to trying to deal (in general) with the notion of the radio telling the = router: "I have a new neighbor! However, I don't have the foggiest notion a= s to what the link characteristics are to said neighbor. Have a nice day!" = Again, just from the perspective of the router, I'm tempted to want to res= pond to that by effectively saying "Call me when you figure it out..." Mayb= e I'm not seeing the forest for all of these trees...=20 >=20 > Regards, > Stan >=20 >> Thomas >>=20 >>> Martin >>>=20 >>> -----Original Message----- >>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>> Sent: Tuesday, October 09, 2012 8:11 AM >>> To: Duke, Martin >>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry= (boberry) >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>>=20 >>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>=20 >>>> RLQ calculation is so loosely defined that it's hard to precisely desc= ribe how this kind of thing might happen. Latency is a bit easier. But in e= ither case, I can imagine a situation where a radio is RLQ/Latency capable,= but it hasn't heard from a neighbor in a while, at least in a way where it= can make any sort of reasonable estimate of either quantity. In this case,= it should report to the router a transition from an RLQ of "foo" to an RLQ= of "unknown". Therefore, we need an unknown code point. >>>=20 >>> I'm having a hard time with the notion of a Link Quality that is "unkno= wn". Seems like a radio would report a quality of "0" (worst case) in that = event.=20 >>>=20 >>> Stan >>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>> To: Duke, Martin >>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); St= an Ratliff (sratliff) >>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>=20 >>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin = wrote: >>>>> The only concern with reporting an unknown value by simply not includ= ing the TLV is if the link state transitions from a known value to an unkno= wn value. I'm not sure how often this would happen, but it seems easy enoug= h to reserve 255 (or whatever) as an 'unknown' code point. >>>>=20 >>>> If a radio supports RLQ it should ALWAYS include the TLV... if it does= not, it should NEVER include it. >>>> (maybe this should be a MUST in the final RFC) >>>>=20 >>>> So the transition should not happen at all. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 From ietf@thomasclausen.org Tue Oct 9 09:51:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F4E11E811D for ; Tue, 9 Oct 2012 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVC6xtxjfYG5 for ; Tue, 9 Oct 2012 09:51:49 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 94BB511E8106 for ; Tue, 9 Oct 2012 09:51:49 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 5002CA399E for ; Tue, 9 Oct 2012 09:51:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DB4DE1C0688; Tue, 9 Oct 2012 09:51:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 180751C0136; Tue, 9 Oct 2012 09:51:48 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 18:51:45 +0200 To: "Stan Ratliff (sratliff)" Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:51:50 -0000 Stan, On 9 oct. 2012, at 18:23, "Stan Ratliff (sratliff)" wro= te: >=20 > On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >=20 >>=20 >> On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: >>=20 >>> Although I have never implemented a router that uses these metrics, I su= spect that I would want to treat RLQ=3D100 links as best for forwarding, RLQ= =3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>>=20 >>=20 >> I'm in somewhat of the same boat as you, experience-wise but my conclusio= ns would be somewhat different: >>=20 >> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>=20 >> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "use= a link with known characteristics, even if not with RLQ=3DMAXVALUE" over us= ing a link with entirely unknown characteristics. >>=20 >> At least, using a link with known characteristics could allow (for exampl= e) parametrizing the traffic to something guaranteed to "fit" over the link.= .... >>=20 >> I do not know if that is a realistic usecase or not (I know that I've dep= loyed something where it made sense like that for L3 routing) >>=20 >=20 > Well, having implemented a DLEP router that uses the metrics, I don't unde= rstand what I'd do with an "Unknown" value=E2=80=A6 Just on a purely esoteri= c level, Thomas has a point in that there's a difference between "I can't ca= lculate RLQ. Ever." and "I can calculate RLQ, but I don't know what it is ye= t." To extend that definition slightly, from the router's perspective, leads= me to trying to deal (in general) with the notion of the radio telling the r= outer: "I have a new neighbor! However, I don't have the foggiest notion as t= o what the link characteristics are to said neighbor. Have a nice day!" Aga= in, just from the perspective of the router, I'm tempted to want to respond t= o that by effectively saying "Call me when you figure it out=E2=80=A6" Maybe= I'm not seeing the forest for all of these trees=E2=80=A6=20 Thanks for taking time to answer to this, and for taking it in the inquisiti= ve spirit my mail was meant. I insist, I am no expert in this domain of DLEP= and I do not know if it is realistic. What you are saying is, that proper behavior is "don't say anything about a n= eighbor until you have an useful RQL to report"? If so, then your argument i= s probably right (could, then, that be specified behavior?) Thomas > Regards, > Stan >=20 >> Thomas >>=20 >>> Martin >>>=20 >>> -----Original Message----- >>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>> Sent: Tuesday, October 09, 2012 8:11 AM >>> To: Duke, Martin >>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (= boberry) >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>>=20 >>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>=20 >>>> RLQ calculation is so loosely defined that it's hard to precisely descr= ibe how this kind of thing might happen. Latency is a bit easier. But in eit= her case, I can imagine a situation where a radio is RLQ/Latency capable, bu= t it hasn't heard from a neighbor in a while, at least in a way where it can= make any sort of reasonable estimate of either quantity. In this case, it s= hould report to the router a transition from an RLQ of "foo" to an RLQ of "u= nknown". Therefore, we need an unknown code point. >>>=20 >>> I'm having a hard time with the notion of a Link Quality that is "unknow= n". Seems like a radio would report a quality of "0" (worst case) in that ev= ent.=20 >>>=20 >>> Stan >>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>> To: Duke, Martin >>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Sta= n Ratliff (sratliff) >>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>=20 >>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin w= rote: >>>>> The only concern with reporting an unknown value by simply not includi= ng the TLV is if the link state transitions from a known value to an unknown= value. I'm not sure how often this would happen, but it seems easy enough t= o reserve 255 (or whatever) as an 'unknown' code point. >>>>=20 >>>> If a radio supports RLQ it should ALWAYS include the TLV... if it does n= ot, it should NEVER include it. >>>> (maybe this should be a MUST in the final RFC) >>>>=20 >>>> So the transition should not happen at all. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 From ietf@thomasclausen.org Tue Oct 9 09:54:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFEA21F87B8 for ; Tue, 9 Oct 2012 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6esB9o6ZU-XT for ; Tue, 9 Oct 2012 09:54:37 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AC1AB21F87B6 for ; Tue, 9 Oct 2012 09:54:37 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id A32ACA3A0F for ; Tue, 9 Oct 2012 09:54:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 24F3D1BDF8B6; Tue, 9 Oct 2012 09:54:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 845BB1BDF89D; Tue, 9 Oct 2012 09:54:36 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <38DC99BE-4A2C-4356-9B91-D7A121FE6E78@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 18:54:35 +0200 To: "Duke, Martin" Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:54:38 -0000 I understood from Stan's mail that the situation where a radio would have to= report "UNKNOWN" was not even esoteric, but a deliberate design-decision to= not ever happen? On 9 oct. 2012, at 18:30, "Duke, Martin" wrote: > Perhaps I've missed an email, but I think the choices we're debating are > (1) Radios that don't have an RLQ estimate MUST NOT send an RLQ TLV; or > (2) Those radios MAY send an RLQ TLV with code UNKNOWN. >=20 > I think the case where a radio is taking time to acquire an estimate is ha= ndled well using either design; it just starts adding the TLV whenever it ha= s an estimate. The case that isn't handled is if the radio loses that abilit= y for one reason or another. In (1) I don't see any obvious syntax to explai= n that there is no longer a good estimate. >=20 > You could say that this is a corner case, and you'd be right. But the cost= of this is RLQ field code points that we're not using anyway and a couple o= f lines of text in the spec. So why not support it? >=20 > Martin >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: Tuesday, October 09, 2012 9:24 AM > To: Thomas Heide Clausen > Cc: Duke, Martin; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (bo= berry) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 >=20 > On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >=20 >>=20 >> On 9 oct. 2012, at 17:15, "Duke, Martin" wrote: >>=20 >>> Although I have never implemented a router that uses these metrics, I su= spect that I would want to treat RLQ=3D100 links as best for forwarding, RLQ= =3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>=20 >> I'm in somewhat of the same boat as you, experience-wise but my conclusio= ns would be somewhat different: >>=20 >> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>=20 >> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "use= a link with known characteristics, even if not with RLQ=3DMAXVALUE" over us= ing a link with entirely unknown characteristics. >>=20 >> At least, using a link with known characteristics could allow (for exampl= e) parametrizing the traffic to something guaranteed to "fit" over the link.= .... >>=20 >> I do not know if that is a realistic usecase or not (I know that I've dep= loyed something where it made sense like that for L3 routing) >=20 > Well, having implemented a DLEP router that uses the metrics, I don't unde= rstand what I'd do with an "Unknown" value... Just on a purely esoteric leve= l, Thomas has a point in that there's a difference between "I can't calculat= e RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet." To= extend that definition slightly, from the router's perspective, leads me to= trying to deal (in general) with the notion of the radio telling the router= : "I have a new neighbor! However, I don't have the foggiest notion as to wh= at the link characteristics are to said neighbor. Have a nice day!" Again, j= ust from the perspective of the router, I'm tempted to want to respond to th= at by effectively saying "Call me when you figure it out..." Maybe I'm not s= eeing the forest for all of these trees...=20 >=20 > Regards, > Stan >=20 >> Thomas >>=20 >>> Martin >>>=20 >>> -----Original Message----- >>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>> Sent: Tuesday, October 09, 2012 8:11 AM >>> To: Duke, Martin >>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (= boberry) >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>>=20 >>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>=20 >>>> RLQ calculation is so loosely defined that it's hard to precisely descr= ibe how this kind of thing might happen. Latency is a bit easier. But in eit= her case, I can imagine a situation where a radio is RLQ/Latency capable, bu= t it hasn't heard from a neighbor in a while, at least in a way where it can= make any sort of reasonable estimate of either quantity. In this case, it s= hould report to the router a transition from an RLQ of "foo" to an RLQ of "u= nknown". Therefore, we need an unknown code point. >>>=20 >>> I'm having a hard time with the notion of a Link Quality that is "unknow= n". Seems like a radio would report a quality of "0" (worst case) in that ev= ent.=20 >>>=20 >>> Stan >>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>> To: Duke, Martin >>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); Sta= n Ratliff (sratliff) >>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>=20 >>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin w= rote: >>>>> The only concern with reporting an unknown value by simply not includi= ng the TLV is if the link state transitions from a known value to an unknown= value. I'm not sure how often this would happen, but it seems easy enough t= o reserve 255 (or whatever) as an 'unknown' code point. >>>>=20 >>>> If a radio supports RLQ it should ALWAYS include the TLV... if it does n= ot, it should NEVER include it. >>>> (maybe this should be a MUST in the final RFC) >>>>=20 >>>> So the transition should not happen at all. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Tue Oct 9 10:04:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5111E80C5 for ; Tue, 9 Oct 2012 10:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.879 X-Spam-Level: X-Spam-Status: No, score=-9.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXRqs98ogEsj for ; Tue, 9 Oct 2012 10:04:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 07AED11E809A for ; Tue, 9 Oct 2012 10:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5009; q=dns/txt; s=iport; t=1349802280; x=1351011880; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Ru7MwmoRzo77B6IBMz3XI3p7JYfYO6KTAFCcotnI3Y=; b=L3ZaqDPo1T9Pq8IH4iTjzWjJFZYA0PnB3CzZOYxO7/LgeoXvpkCdPOZZ YPAkCwcoJ7wSk/5G5EFILhvfItkKaO5pEiMiuS9UKoQqrqpMKSB6hEfcG AZqXEjXcsFJIM40Nv3sr9URzdMBrX24qFROPpRcU/qT4tr/x23A94QfXh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMxYdFCtJXHB/2dsb2JhbABFvzGBCIIgAQEBAwEBAQEPAVgDCwUHBAIBCBEEAQEBCh0HJwsUCQgCBA4FCBqHUQMJBgubcI9Whl4NiVAEilNmGoUZYAOkL4Frgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129871317" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2012 17:04:39 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q99H4d5l032245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 17:04:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 12:04:39 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYA= Date: Tue, 9 Oct 2012 17:04:38 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> In-Reply-To: <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--48.391800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <74C83092F37A264BB6307AB589EE80F0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 17:04:41 -0000 On Oct 9, 2012, at 12:51 PM, Thomas Heide Clausen wrote: > Stan, >=20 > On 9 oct. 2012, at 18:23, "Stan Ratliff (sratliff)" = wrote: >=20 >>=20 >> On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>> On 9 oct. 2012, at 17:15, "Duke, Martin" wrote= : >>>=20 >>>> Although I have never implemented a router that uses these metrics, I = suspect that I would want to treat RLQ=3D100 links as best for forwarding, = RLQ=3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>>>=20 >>>=20 >>> I'm in somewhat of the same boat as you, experience-wise but my conclus= ions would be somewhat different: >>>=20 >>> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>>=20 >>> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "u= se a link with known characteristics, even if not with RLQ=3DMAXVALUE" over= using a link with entirely unknown characteristics. >>>=20 >>> At least, using a link with known characteristics could allow (for exam= ple) parametrizing the traffic to something guaranteed to "fit" over the li= nk..... >>>=20 >>> I do not know if that is a realistic usecase or not (I know that I've d= eployed something where it made sense like that for L3 routing) >>>=20 >>=20 >> Well, having implemented a DLEP router that uses the metrics, I don't un= derstand what I'd do with an "Unknown" value=85 Just on a purely esoteric l= evel, Thomas has a point in that there's a difference between "I can't calc= ulate RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet= ." To extend that definition slightly, from the router's perspective, leads= me to trying to deal (in general) with the notion of the radio telling the= router: "I have a new neighbor! However, I don't have the foggiest notion = as to what the link characteristics are to said neighbor. Have a nice day!"= Again, just from the perspective of the router, I'm tempted to want to re= spond to that by effectively saying "Call me when you figure it out=85" May= be I'm not seeing the forest for all of these trees=85=20 >=20 > Thanks for taking time to answer to this, and for taking it in the inquis= itive spirit my mail was meant. I insist, I am no expert in this domain of = DLEP and I do not know if it is realistic. >=20 > What you are saying is, that proper behavior is "don't say anything about= a neighbor until you have an useful RQL to report"? If so, then your argum= ent is probably right (could, then, that be specified behavior?) Yes, that's what I'm advocating for.=20 Regards, Stan >=20 > Thomas >=20 >=20 >> Regards, >> Stan >>=20 >>> Thomas >>>=20 >>>> Martin >>>>=20 >>>> -----Original Message----- >>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>>> Sent: Tuesday, October 09, 2012 8:11 AM >>>> To: Duke, Martin >>>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berr= y (boberry) >>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>=20 >>>>=20 >>>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>>=20 >>>>> RLQ calculation is so loosely defined that it's hard to precisely des= cribe how this kind of thing might happen. Latency is a bit easier. But in = either case, I can imagine a situation where a radio is RLQ/Latency capable= , but it hasn't heard from a neighbor in a while, at least in a way where i= t can make any sort of reasonable estimate of either quantity. In this case= , it should report to the router a transition from an RLQ of "foo" to an RL= Q of "unknown". Therefore, we need an unknown code point. >>>>=20 >>>> I'm having a hard time with the notion of a Link Quality that is "unkn= own". Seems like a radio would report a quality of "0" (worst case) in that= event.=20 >>>>=20 >>>> Stan >>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>>> To: Duke, Martin >>>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); S= tan Ratliff (sratliff) >>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>=20 >>>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin = wrote: >>>>>> The only concern with reporting an unknown value by simply not inclu= ding the TLV is if the link state transitions from a known value to an unkn= own value. I'm not sure how often this would happen, but it seems easy enou= gh to reserve 255 (or whatever) as an 'unknown' code point. >>>>>=20 >>>>> If a radio supports RLQ it should ALWAYS include the TLV... if it doe= s not, it should NEVER include it. >>>>> (maybe this should be a MUST in the final RFC) >>>>>=20 >>>>> So the transition should not happen at all. >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>=20 From ietf@thomasclausen.org Tue Oct 9 10:37:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A277221F8738 for ; Tue, 9 Oct 2012 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNRAb+0m6GFa for ; Tue, 9 Oct 2012 10:37:05 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4A21F8737 for ; Tue, 9 Oct 2012 10:37:05 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 69F6B557F50 for ; Tue, 9 Oct 2012 10:37:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 17A9A1C066B; Tue, 9 Oct 2012 10:37:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4B4E61C0463; Tue, 9 Oct 2012 10:37:01 -0700 (PDT) References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 9 Oct 2012 19:36:59 +0200 To: "Stan Ratliff (sratliff)" Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 17:37:06 -0000 On 9 oct. 2012, at 19:04, "Stan Ratliff (sratliff)" wro= te: >=20 > On Oct 9, 2012, at 12:51 PM, Thomas Heide Clausen wrote: >=20 >> Stan, >>=20 >> On 9 oct. 2012, at 18:23, "Stan Ratliff (sratliff)" w= rote: >>=20 >>>=20 >>> On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >>>=20 >>>>=20 >>>> On 9 oct. 2012, at 17:15, "Duke, Martin" wrote= : >>>>=20 >>>>> Although I have never implemented a router that uses these metrics, I s= uspect that I would want to treat RLQ=3D100 links as best for forwarding, RL= Q=3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>>>>=20 >>>>=20 >>>> I'm in somewhat of the same boat as you, experience-wise but my conclus= ions would be somewhat different: >>>>=20 >>>> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>>>=20 >>>> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to "u= se a link with known characteristics, even if not with RLQ=3DMAXVALUE" over u= sing a link with entirely unknown characteristics. >>>>=20 >>>> At least, using a link with known characteristics could allow (for exam= ple) parametrizing the traffic to something guaranteed to "fit" over the lin= k..... >>>>=20 >>>> I do not know if that is a realistic usecase or not (I know that I've d= eployed something where it made sense like that for L3 routing) >>>>=20 >>>=20 >>> Well, having implemented a DLEP router that uses the metrics, I don't un= derstand what I'd do with an "Unknown" value=E2=80=A6 Just on a purely esote= ric level, Thomas has a point in that there's a difference between "I can't c= alculate RLQ. Ever." and "I can calculate RLQ, but I don't know what it is y= et." To extend that definition slightly, from the router's perspective, lead= s me to trying to deal (in general) with the notion of the radio telling the= router: "I have a new neighbor! However, I don't have the foggiest notion a= s to what the link characteristics are to said neighbor. Have a nice day!" A= gain, just from the perspective of the router, I'm tempted to want to respon= d to that by effectively saying "Call me when you figure it out=E2=80=A6" Ma= ybe I'm not seeing the forest for all of these trees=E2=80=A6=20 >>=20 >> Thanks for taking time to answer to this, and for taking it in the inquis= itive spirit my mail was meant. I insist, I am no expert in this domain of D= LEP and I do not know if it is realistic. >>=20 >> What you are saying is, that proper behavior is "don't say anything about= a neighbor until you have an useful RQL to report"? If so, then your argume= nt is probably right (could, then, that be specified behavior?) >=20 > Yes, that's what I'm advocating for.=20 >=20 Great. If documented thus, I am happy with that outcome. Thomas > Regards, > Stan >=20 >>=20 >> Thomas >>=20 >>=20 >>> Regards, >>> Stan >>>=20 >>>> Thomas >>>>=20 >>>>> Martin >>>>>=20 >>>>> -----Original Message----- >>>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>>>> Sent: Tuesday, October 09, 2012 8:11 AM >>>>> To: Duke, Martin >>>>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Berr= y (boberry) >>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>=20 >>>>>=20 >>>>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>>>=20 >>>>>> RLQ calculation is so loosely defined that it's hard to precisely des= cribe how this kind of thing might happen. Latency is a bit easier. But in e= ither case, I can imagine a situation where a radio is RLQ/Latency capable, b= ut it hasn't heard from a neighbor in a while, at least in a way where it ca= n make any sort of reasonable estimate of either quantity. In this case, it s= hould report to the router a transition from an RLQ of "foo" to an RLQ of "u= nknown". Therefore, we need an unknown code point. >>>>>=20 >>>>> I'm having a hard time with the notion of a Link Quality that is "unkn= own". Seems like a radio would report a quality of "0" (worst case) in that e= vent.=20 >>>>>=20 >>>>> Stan >>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>>>> To: Duke, Martin >>>>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry); S= tan Ratliff (sratliff) >>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>=20 >>>>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin = wrote: >>>>>>> The only concern with reporting an unknown value by simply not inclu= ding the TLV is if the link state transitions from a known value to an unkno= wn value. I'm not sure how often this would happen, but it seems easy enough= to reserve 255 (or whatever) as an 'unknown' code point. >>>>>>=20 >>>>>> If a radio supports RLQ it should ALWAYS include the TLV... if it doe= s not, it should NEVER include it. >>>>>> (maybe this should be a MUST in the final RFC) >>>>>>=20 >>>>>> So the transition should not happen at all. >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >=20 From boberry@cisco.com Tue Oct 9 12:30:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A027611E80EA for ; Tue, 9 Oct 2012 12:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhBvmdcfC8Nw for ; Tue, 9 Oct 2012 12:30:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D8D1711E809C for ; Tue, 9 Oct 2012 12:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2075; q=dns/txt; s=iport; t=1349811048; x=1351020648; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=mTU5d91Qz6yUJsn78JiOtEBa9unysynVcAh2IHTPCOw=; b=OIFAzLVYCeU3ZdjMN5OZe9h8ApZYM+Tp2kmqNn+dcMKGPNQJfO2iH9hs o0qsEqyl+cHoF/vURO/99NV1ECVc+I6znG6OrTNkrzKSGsWjVm4r/SOnd EgwsmRpE2ZjfmdEFlPzlrKZ/oujeEf3cROh5ZJi5izC89BHufK8xWbvmr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPl5dFCtJV2Y/2dsb2JhbABFvzCBCIIhAQEEEgF2C0ZXBgE0h2OaPY9YkD6LQ4UzYAOVa45FgWuDCYE+IQ X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="126884497" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 09 Oct 2012 19:30:48 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q99JUmkm031718; Tue, 9 Oct 2012 19:30:48 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1085) From: Bo Berry In-Reply-To: <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> Date: Tue, 9 Oct 2012 15:30:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> To: Teco Boot , "manet@ietf.org List" X-Mailer: Apple Mail (2.1085) Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:30:49 -0000 Teco I reviewed=20 Request for Comments: 5405 =20 BCP: 145, Unicast UDP Usage Guidelines for Application Designers DLEP is only control plane traffic between the router and its=20 connected radio. The draft should allow for driver implementations=20 (pci SDRs for example) as well as ethernet protocols: UDP, SCTP,=20 TLS. So abstracting DLEP from the transport is good.=20 I'd like to see a flexible DLEP such that it allows for easy=20 adoption by different radios with different requirements. I=20 think we should be careful not to assume all radios can/should implement DLEP the same. Some may enable heart beats, some may not. Some radios may be able to generate RLQ and some not. Some radios may want to use a broadcast/multicast for=20 discovery and some may use unicast.=20 I'm OK with the current direction.=20 -Bo On Oct 9, 2012, at 8:58 AM, Bo Berry wrote: ~~~cut > 8. "=85remove reliable protocol function and use validity time": = Again, >>>>>> I disagree. That IMO increases the complexity dramatically. >>>>>=20 >>>>> It can simplify the protocol but add the need for a few more = timers in the implementation. >>>> Could be one timer, for housekeeping. The protocols should be = designed in such a way the dat in information databases is explicitly = revoked and nothing depends on the housekeeping timer, except the = cleanup. Many protocols we have today work this way. >>=20 >> I posted on unneeded complexity and partial specification. >> I suggested two options, both could be supported by the protocol: >> a) use unreliable protocol, with vtime >> b) use TCP >>=20 >> Discussed whole morning with app guys on why there is a need for UDP = congestion control and better capabilities for retransmit. Let's = circumvent and do it right this time. Read BCP 145 for the details. >>=20 >=20 > OK, I'll look at 145. Suggest we split this topic into its > own thread for easy discussions and closure, when people respond. > These emails get long and stuff may be missed by anyone of us. >=20 From ulrich@herberg.name Tue Oct 9 14:51:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563B01F0C90 for ; Tue, 9 Oct 2012 14:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYBn5x9POXcE for ; Tue, 9 Oct 2012 14:51:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4532421F8532 for ; Tue, 9 Oct 2012 14:51:09 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so8357516vcb.31 for ; Tue, 09 Oct 2012 14:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XBFqwPY+R9torW+QQ+4XnCEEo8uzxfhympDQ45YuoHo=; b=O+VQ2axi24cmELaWRFoOX2BhENx8rtKyhRXVh9V8WAGhBVbXLL98wFVpiGaML40LCn AIkEYiXizL0FSOOWBBVzYB1zQJMX2QOt4lkgK2wuHW12OKkRIbAn+MzZo/v72szs+CKE aL7lGa5WK/rJNG3xSyxkMfMqq2GNNvG/Pewvk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=XBFqwPY+R9torW+QQ+4XnCEEo8uzxfhympDQ45YuoHo=; b=KjOZdOxPRwsTXvUBo/EVzcCwl3YRL5IiQkmGXwBi2QAZczAhIofVph6JhG6n4NW93C P3u+0PmLGdWGXJvFXaAVbEDANDYv2kzzNmptph4NCEWbMA7QY6zJ4o27THbHoWyUBsL1 MOT2hABpsR7PKR0yCvUAZS3ez+ij2s51g570o5IMJtGYS5pl9VueuVrtzapM60FbtlBH iewqX5vuQm17AAfxts1O1HdJuD6D/xnmC7qx83h8wccUqUlJqA5/EmTobiQX5XnhhtJn pInkjL+C1vaT33yWXWQ1f6foWxeU3BFpjP5oMiyAbo6o0JqAd3BfFL3TdvtSY0oAcoWO OTIg== MIME-Version: 1.0 Received: by 10.220.230.133 with SMTP id jm5mr12670685vcb.4.1349819468500; Tue, 09 Oct 2012 14:51:08 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Tue, 9 Oct 2012 14:51:08 -0700 (PDT) Date: Tue, 9 Oct 2012 14:51:08 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=14dae9cdc6c1ee4eb504cba755cc X-Gm-Message-State: ALoCoQk14MX6PrBiBMKK7wImUAp3N3mCQNHx5SpK6noXqUFrd0wa7+5heLtk1Bq/ORg6B5EiH/lO Cc: manet-chairs@tools.ietf.org Subject: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 21:51:10 -0000 --14dae9cdc6c1ee4eb504cba755cc Content-Type: text/plain; charset=ISO-8859-1 Hi, the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. If you intend to present something, please send a request to the chairs. Best regards Ulrich --14dae9cdc6c1ee4eb504cba755cc Content-Type: text/html; charset=ISO-8859-1 Hi,

the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. If you intend to present something, please send a request to the chairs.

Best regards
Ulrich
--14dae9cdc6c1ee4eb504cba755cc-- From boberry@cisco.com Tue Oct 9 15:18:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022C021F861D for ; Tue, 9 Oct 2012 15:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.881 X-Spam-Level: X-Spam-Status: No, score=-9.881 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dlktm8PrDyCK for ; Tue, 9 Oct 2012 15:18:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F3EE321F8618 for ; Tue, 9 Oct 2012 15:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6595; q=dns/txt; s=iport; t=1349821095; x=1351030695; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Lz92aG0ug1HSZVL9KLLbvjWzctebGnqIv6gtS8N6PH0=; b=l5ftKdAxLE1t1GicxEfSVOhMmlrtUZRwGmfE6MuxgP7fhmlyf1JEm9z+ RXpoBgqfGTXPLzDh+V+o+zzR2dn1TV8sXrKeF5BmOk8KTgYDaSg+X4MJ2 2md1xjPQ+Kunzt5PnIER8oskHJEJF14wWRbT9WcG0rKRMNorxPsJvJ9qv 4=; X-IronPort-AV: E=Sophos;i="4.80,562,1344211200"; d="scan'208";a="129975605" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2012 22:18:14 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-9.cisco.com [10.81.230.9]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q99MIDCM020282; Tue, 9 Oct 2012 22:18:14 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Bo Berry In-Reply-To: <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> Date: Tue, 9 Oct 2012 18:18:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1085) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 22:18:16 -0000 On Oct 9, 2012, at 1:36 PM, Thomas Heide Clausen wrote: >=20 > On 9 oct. 2012, at 19:04, "Stan Ratliff (sratliff)" = wrote: >=20 >>=20 >> On Oct 9, 2012, at 12:51 PM, Thomas Heide Clausen wrote: >>=20 >>> Stan, >>>=20 >>> On 9 oct. 2012, at 18:23, "Stan Ratliff (sratliff)" = wrote: >>>=20 >>>>=20 >>>> On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>>=20 >>>>> On 9 oct. 2012, at 17:15, "Duke, Martin" = wrote: >>>>>=20 >>>>>> Although I have never implemented a router that uses these = metrics, I suspect that I would want to treat RLQ=3D100 links as best = for forwarding, RLQ=3D0 links worst, and RLQ=3Dunknown as somewhere in = between. >>>>>>=20 >>>>>=20 >>>>> I'm in somewhat of the same boat as you, experience-wise but my = conclusions would be somewhat different: >>>>>=20 >>>>> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>>>>=20 >>>>> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer = to "use a link with known characteristics, even if not with = RLQ=3DMAXVALUE" over using a link with entirely unknown characteristics. >>>>>=20 >>>>> At least, using a link with known characteristics could allow (for = example) parametrizing the traffic to something guaranteed to "fit" over = the link..... >>>>>=20 >>>>> I do not know if that is a realistic usecase or not (I know that = I've deployed something where it made sense like that for L3 routing) >>>>>=20 >>>>=20 >>>> Well, having implemented a DLEP router that uses the metrics, I = don't understand what I'd do with an "Unknown" value=85 Just on a purely = esoteric level, Thomas has a point in that there's a difference between = "I can't calculate RLQ. Ever." and "I can calculate RLQ, but I don't = know what it is yet." To extend that definition slightly, from the = router's perspective, leads me to trying to deal (in general) with the = notion of the radio telling the router: "I have a new neighbor! However, = I don't have the foggiest notion as to what the link characteristics are = to said neighbor. Have a nice day!" Again, just from the perspective of = the router, I'm tempted to want to respond to that by effectively saying = "Call me when you figure it out=85" Maybe I'm not seeing the forest for = all of these trees=85=20 >>>=20 >>> Thanks for taking time to answer to this, and for taking it in the = inquisitive spirit my mail was meant. I insist, I am no expert in this = domain of DLEP and I do not know if it is realistic. >>>=20 >>> What you are saying is, that proper behavior is "don't say anything = about a neighbor until you have an useful RQL to report"? If so, then = your argument is probably right (could, then, that be specified = behavior?) >>=20 >> Yes, that's what I'm advocating for.=20 This sounds like a radio requirement. I do not think having a RLQ should = be a prerequisite for a neighbor. The radio should be able to report = neighbor status by excluding the TLV. For example, if I build one radio = that constantly sends (hard codes) RLQ=3D100 and another radio that = dynamically computes-reports RLQ and another radio that never sends RLQ = (and the spectrums are compatible), DLEP should handle all. Another metric, resources, is also a percentage (0-100). What if a = radio has no means to compute resources? The radio should be able to = exclude this TLV also, or simply report 100. Again if I build a simple = radio and hard code resources to 100, its compliant.=20 Suggest these tlvs be optional or let the radio send 100. I'm OK with = an unknown value (255).=20 The router obviously will need to handle the diff cases. >>=20 >=20 > Great. If documented thus, I am happy with that outcome. >=20 > Thomas >=20 >> Regards, >> Stan >>=20 >>>=20 >>> Thomas >>>=20 >>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>> Thomas >>>>>=20 >>>>>> Martin >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>>>>> Sent: Tuesday, October 09, 2012 8:11 AM >>>>>> To: Duke, Martin >>>>>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo = Berry (boberry) >>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>=20 >>>>>>=20 >>>>>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>>>>=20 >>>>>>> RLQ calculation is so loosely defined that it's hard to = precisely describe how this kind of thing might happen. Latency is a bit = easier. But in either case, I can imagine a situation where a radio is = RLQ/Latency capable, but it hasn't heard from a neighbor in a while, at = least in a way where it can make any sort of reasonable estimate of = either quantity. In this case, it should report to the router a = transition from an RLQ of "foo" to an RLQ of "unknown". Therefore, we = need an unknown code point. >>>>>>=20 >>>>>> I'm having a hard time with the notion of a Link Quality that is = "unknown". Seems like a radio would report a quality of "0" (worst case) = in that event.=20 >>>>>>=20 >>>>>> Stan >>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>>>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>>>>> To: Duke, Martin >>>>>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry = (boberry); Stan Ratliff (sratliff) >>>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>>=20 >>>>>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin = wrote: >>>>>>>> The only concern with reporting an unknown value by simply not = including the TLV is if the link state transitions from a known value to = an unknown value. I'm not sure how often this would happen, but it seems = easy enough to reserve 255 (or whatever) as an 'unknown' code point. >>>>>>>=20 >>>>>>> If a radio supports RLQ it should ALWAYS include the TLV... if = it does not, it should NEVER include it. >>>>>>> (maybe this should be a MUST in the final RFC) >>>>>>>=20 >>>>>>> So the transition should not happen at all. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Tue Oct 9 23:16:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C3821F859A for ; Tue, 9 Oct 2012 23:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6inMCVHl453 for ; Tue, 9 Oct 2012 23:16:40 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5B04A21F8596 for ; Tue, 9 Oct 2012 23:16:39 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLpav-0000RW-Gw for manet@ietf.org; Wed, 10 Oct 2012 08:16:37 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLpav-00043k-EJ for manet@ietf.org; Wed, 10 Oct 2012 08:16:37 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 08:16:37 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 08:16:36 +0200 Message-ID: <507512BA.2000908@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 08:16:26 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> In-Reply-To: <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090102050908070607050104" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 06:16:37.0306 (UTC) FILETIME=[CDEE01A0:01CDA6AE] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8a842d9e11f1c1d58316de1cda04e013 Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 06:16:41 -0000 --------------ms090102050908070607050104 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/10/2012 12:18 AM, Bo Berry wrote: > This sounds like a radio requirement. I do not think having a RLQ > should be a prerequisite for a neighbor. The radio should be able to > report neighbor status by excluding the TLV. For example, if I build > one radio that constantly sends (hard codes) RLQ=3D100 and another > radio that dynamically computes-reports RLQ and another radio that > never sends RLQ (and the spectrums are compatible), DLEP should > handle all. > > Another metric, resources, is also a percentage (0-100). What if a > radio has no means to compute resources? The radio should be able to > exclude this TLV also, or simply report 100. Again if I build a > simple radio and hard code resources to 100, its compliant. > > Suggest these tlvs be optional or let the radio send 100. I'm OK > with an unknown value (255). > > The router obviously will need to handle the diff cases. As long this is well documented, the 255 value should be easy to handle. If the local router does not want to deal with it, it just can drop the TLV processing internally. I think that is exactly what we have to work on through the whole draft. It contains too many degrees of freedom which have to be interpreted, we = need to specify the one that could create incompatible implementations. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090102050908070607050104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAwNjE2MzRaMCMGCSqGSIb3DQEJBDEWBBRV0dv8atvj0Xnuct1sk7j4/TbsMzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAITTOH0mnAmTeIw2gElCJCopB5WubuzGzr02+eTAO26Yf oAZSLjNbIrT+a76sz6ACmJP8bmJJzklmcZKGVq9vUvxISUB5WXhMl0M1FOgT3jXEvjjc3CIK nN0vIigaEyYhIBklzIqwmRerOi2i9j76uotiiBNc7w5ahrAZhmgypfFYdI8SA7zfmBYKJsm7 4FsAYW9xvbwGajbTbzeWAj/oUQZOHeDSUjGUfF5M03XcZUi0+qOjUeb8uATTcCWQhpmUVDL8 g6xXrzj2UVR13sGxKvpQkaxhNaI53tEZ5OCYMHARMm5bYRrKImw1ZoYoGaTmxxRq7pFfJmOP 2IjBYYkDfAAAAAAAAA== --------------ms090102050908070607050104-- From teco@inf-net.nl Tue Oct 9 23:17:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F0221F872E for ; Tue, 9 Oct 2012 23:17:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mIj6679hGeT for ; Tue, 9 Oct 2012 23:17:56 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2CF21F859A for ; Tue, 9 Oct 2012 23:17:55 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so149161wib.13 for ; Tue, 09 Oct 2012 23:17:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LjnKsNN+pKQNn5YpwRg8WRuWLz+Qf7opr3JZBGzAKuk=; b=Z7kEqO+B/o1ADiOm851gR16iNq6Pd7p/pMgIku204pXVnhWte9xC2pkhQ8mrCIgh4N W9CRg6vU7s1OZ4WPBd9sjPgJzy1+bvFl1ciNgQcdPT0P7gQomFptTbyCm0FmQncg6dAE zvY9PCItdLvI0+Jb+P12YWJsozxFJdWUeX+sqQFAYMPcNFcVfD105Lbe1disJFqe16rS eBAebn0VdFartA4rvBhnA1vTHg3lzAJwysh4OxBF2DfwlMsio4/iEMU2w4mhXYxYFAoE auHjLicEeKrk5l5mO2K5PaFOxCIPvqiVQN5dkFm4r+cgniLiXkg6DhgR672GrkJutwgK NLbA== Received: by 10.216.207.73 with SMTP id m51mr13551018weo.116.1349849874461; Tue, 09 Oct 2012 23:17:54 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:4880:c19f:4766:219b? ([2001:470:7a9b:1:4880:c19f:4766:219b]) by mx.google.com with ESMTPS id k20sm28666389wiv.11.2012.10.09.23.17.52 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 23:17:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Wed, 10 Oct 2012 08:17:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmJBUuN7HG26TwueToHsBuHBZ4y8jLyMUj1sn+RAFPxyvLsZsLNYqRb+E+jaBAxRQhkM1Cb Cc: "manet@ietf.org List" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 06:17:56 -0000 Op 9 okt. 2012, om 21:30 heeft Bo Berry het volgende geschreven: > Teco > I reviewed=20 > Request for Comments: 5405 =20 > BCP: 145, Unicast UDP Usage Guidelines for Application Designers >=20 > DLEP is only control plane traffic between the router and its=20 > connected radio. The draft should allow for driver implementations=20 > (pci SDRs for example) as well as ethernet protocols: UDP, SCTP,=20 > TLS. So abstracting DLEP from the transport is good. Having a ling list of options is bad for a proposed standard protocol.=20= BTW, don't forget PGM/NORM and a random subset out of a long list=20 of distributed databases. No, lets define the standard for it, certainly for the loosely=20 coupled scenario, based on IP (although using L2 link local protocol=20 could be a good alternative). I agree that DLEP could be reused for embedded radios, this=20 needs more thoughts. Using IP inside an enclosure could be an option. Or emulate IP and UDP/xxx. Would such a pluggable=20 interface function as a bridge, i.e. router interface is ethernet?=20 IMHO, this needs a separate document. Lets not solve all problems=20 right now. >=20 > I'd like to see a flexible DLEP such that it allows for easy=20 > adoption by different radios with different requirements. I=20 > think we should be careful not to assume all radios can/should > implement DLEP the same. Some may enable heart beats, some > may not. Transfer of data has to be reliable. We cannot accept half=20 functioning devices. > Some radios may be able to generate RLQ and some > not. Sure. Few TLVs should be mandatory. I suggest only one. > Some radios may want to use a broadcast/multicast for=20 > discovery and some may use unicast. Yes. But it has to be reliable and risks on congestion is always on the corner. I am quite experienced here. Also on limited resources on LANs / HW. >=20 >=20 > I'm OK with the current direction.=20 I'm fine with our discussion.=20 Teco >=20 > -Bo >=20 >=20 >=20 > On Oct 9, 2012, at 8:58 AM, Bo Berry wrote: > ~~~cut >> 8. "=85remove reliable protocol function and use validity time": = Again, >>>>>>> I disagree. That IMO increases the complexity dramatically. >>>>>>=20 >>>>>> It can simplify the protocol but add the need for a few more = timers in the implementation. >>>>> Could be one timer, for housekeeping. The protocols should be = designed in such a way the dat in information databases is explicitly = revoked and nothing depends on the housekeeping timer, except the = cleanup. Many protocols we have today work this way. >>>=20 >>> I posted on unneeded complexity and partial specification. >>> I suggested two options, both could be supported by the protocol: >>> a) use unreliable protocol, with vtime >>> b) use TCP >>>=20 >>> Discussed whole morning with app guys on why there is a need for UDP = congestion control and better capabilities for retransmit. Let's = circumvent and do it right this time. Read BCP 145 for the details. >>>=20 >>=20 >> OK, I'll look at 145. Suggest we split this topic into its >> own thread for easy discussions and closure, when people respond. >> These emails get long and stuff may be missed by anyone of us. >>=20 >=20 From henning.rogge@fkie.fraunhofer.de Tue Oct 9 23:29:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F2D21F84D4 for ; Tue, 9 Oct 2012 23:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXNgWAj5gPO1 for ; Tue, 9 Oct 2012 23:29:13 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABFD21F84D3 for ; Tue, 9 Oct 2012 23:29:13 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLpn1-0003rd-Fe; Wed, 10 Oct 2012 08:29:07 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLpn1-0004MN-D0; Wed, 10 Oct 2012 08:29:07 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 08:29:07 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 08:29:06 +0200 Message-ID: <507515B1.5030809@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 08:29:05 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060306040802060708020700" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 06:29:07.0248 (UTC) FILETIME=[8CEE1300:01CDA6B0] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8a842d9e11f1c1d58316de1cda04e013 Cc: Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 06:29:14 -0000 --------------ms060306040802060708020700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/09/2012 09:30 PM, Bo Berry wrote: > Teco > I reviewed > Request for Comments: 5405 > BCP: 145, Unicast UDP Usage Guidelines for Application Designers > > DLEP is only control plane traffic between the router and its > connected radio. The draft should allow for driver implementations > (pci SDRs for example) as well as ethernet protocols: UDP, SCTP, > TLS. So abstracting DLEP from the transport is good. If we allow this (especially the pci part), we cannot use the IP/port=20 tuple as a router/radio identification. I see the reason for this (and one of the suggestions of the original=20 DLEP proposal was to make it transport independent). Can we maybe handle this with an OPTIONAL identification TLV of (at=20 least) six bytes for both router and radio? The standard could define=20 that in the absence of this tuples and the usage of IP/UDP, the IP/Port=20 combination MUST be used as an id. The problem is that with IPv6 we will have 18-bytes tuples for radio and = for router (for a total of 36 bytes). Either we have to specify that=20 this is a valid ID or we might break some router/radio implementations=20 because they expect only 4 or 6 bytes. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060306040802060708020700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAwNjI5MDVaMCMGCSqGSIb3DQEJBDEWBBQgTBiMm1+iIp1xNBSpUvlQETObVzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEALROSyvIlCYwwbuw3wARGpQLFFptvB7BdtH6MP/uFePUS NyPbmjPtC1A3u33gfFA/fI9pSfuMIj1VNR/PXMmCzwgb3vGzinCTDYa2FA054Tx9xA0Rm/NA Nt+pI1xLc4Q01L6p/en7rgbdVnqEyWTPqN0qbZ+68IrivCC8dXlXM6vyYuESnpu47hJ1z66p 1aUdxlSNGn1z2pK8lK+c9J/mMZtX2Ge0buJjSXvmxSsETT+/Ruha5Wgsn1U+pRfIzrkVCE1k yy4VIx4OfsBv/PABqiYOBJG3PN/SuT2uAQCT4mHpiHst0Cl5lPeEKvl9JajVrYiBpP0xPJTU BIBFXUr2LQAAAAAAAA== --------------ms060306040802060708020700-- From teco@inf-net.nl Wed Oct 10 00:31:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A196D21F8742 for ; Wed, 10 Oct 2012 00:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+plt9KmbS2E for ; Wed, 10 Oct 2012 00:30:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F88B21F86CF for ; Wed, 10 Oct 2012 00:30:58 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so98306bkc.31 for ; Wed, 10 Oct 2012 00:30:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CB9c1riA2vXRg/+6nRg7JiLbJOC1HuobQc6Jc3fOq7o=; b=nitak8nxY+gbPhHSz5+uQSoDM1mg2Tp+MvHTmzb6Q/AS9iNdk1iXVpDGO7AQpw/KEf kb/59dyhkptFYX4aF5fvD0sSLbctnpHN9uM1wXU5Y4/okEc6gBs5StZgoIyu7GYpm18V 56EhdoHppoKPPQgd8/dD5iT+ob1eBnyi7/3OQVbkOlZ5hBV2uLrPPNEXKJeiNG4pHMrp k/1fPnYiOiwGtre2DaAor2teARrttLZB109JTop40nu4PqQWomBMGwRyAaDdy03xkMJb 9vOQCc/WvSSB+mmHY05fDN2h5zzA8S1UDxx5ijJDH5wzKLnDO0CdVn3p15PkkrDbTJxt QReA== Received: by 10.204.150.206 with SMTP id z14mr7822264bkv.105.1349854257718; Wed, 10 Oct 2012 00:30:57 -0700 (PDT) Received: from [10.87.63.252] ([80.187.201.33]) by mx.google.com with ESMTPS id m19sm229645bkm.8.2012.10.10.00.30.50 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 00:30:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <507515B1.5030809@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 09:30:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQn5O1vaudOhY7tpsP2WF1dUMvXmv2aVaQDMAKQHuXNDm7kS/SpbhKiqrOjwex6SyBnW4GBi Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 07:31:00 -0000 Some thoughts on how we may get out of some issues. If we use=20 RFC 2119 SHOULD language for what is needed for a standard,=20 we can accept modified implementations. So we can say: o And DLEP implementations SHOULD use UDP o And DLEP implementations SHOULD use heartbeats o And DLEP implementations SHOULD use ACK etc. If we think TCP is overkill (I can accept that), we can specify each single packet (or message) SHOULD be ACKked. This provides reliability and eliminates any congestion. Bulk transfer is slowed down, but with sending updates only, this should not be a problem. Startup message transfer would take a little bit longer, but might=20 be faster than TCP in many cases. An alternative for congestion avoidance would be rate limiting. This=20 needs a parameter. Not my preference. Teco Op 10 okt. 2012, om 08:29 heeft Henning Rogge het volgende geschreven: > On 10/09/2012 09:30 PM, Bo Berry wrote: >> Teco >> I reviewed >> Request for Comments: 5405 >> BCP: 145, Unicast UDP Usage Guidelines for Application Designers >>=20 >> DLEP is only control plane traffic between the router and its >> connected radio. The draft should allow for driver implementations >> (pci SDRs for example) as well as ethernet protocols: UDP, SCTP, >> TLS. So abstracting DLEP from the transport is good. >=20 > If we allow this (especially the pci part), we cannot use the IP/port = tuple as a router/radio identification. >=20 > I see the reason for this (and one of the suggestions of the original = DLEP proposal was to make it transport independent). >=20 > Can we maybe handle this with an OPTIONAL identification TLV of (at = least) six bytes for both router and radio? The standard could define = that in the absence of this tuples and the usage of IP/UDP, the IP/Port = combination MUST be used as an id. >=20 > The problem is that with IPv6 we will have 18-bytes tuples for radio = and for router (for a total of 36 bytes). Either we have to specify that = this is a valid ID or we might break some router/radio implementations = because they expect only 4 or 6 bytes. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From henning.rogge@fkie.fraunhofer.de Wed Oct 10 01:20:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4521F84EF for ; Wed, 10 Oct 2012 01:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l71M2ExfnQr for ; Wed, 10 Oct 2012 01:20:35 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7E38521F8738 for ; Wed, 10 Oct 2012 01:20:34 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLrWn-00084t-K1; Wed, 10 Oct 2012 10:20:29 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLrWn-0007XC-HL; Wed, 10 Oct 2012 10:20:29 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 10:20:29 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 10:20:29 +0200 Message-ID: <50752FC6.5050901@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 10:20:22 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Teco Boot References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> In-Reply-To: <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030506020608020801000202" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 08:20:29.0369 (UTC) FILETIME=[1BC8D290:01CDA6C0] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e1a2c87e9561ebd0ec644701fc13d4ff Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:20:36 -0000 --------------ms030506020608020801000202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 10.10.2012 09:30, schrieb Teco Boot: > Some thoughts on how we may get out of some issues. If we use > RFC 2119 SHOULD language for what is needed for a standard, > we can accept modified implementations. > > So we can say: > o And DLEP implementations SHOULD use UDP > o And DLEP implementations SHOULD use heartbeats > o And DLEP implementations SHOULD use ACK If ACK stays optional, we have to make sure this will not lead to=20 starvation. What happens if we have a Radio that supports ACKs (and expects them)=20 but the Router does NOT? Wouldn't the Radio wait for ACKs that will never arrive and maybe even=20 terminate the session because of this? > etc. > > If we think TCP is overkill (I can accept that), we can specify > each single packet (or message) SHOULD be ACKked. This provides > reliability and eliminates any congestion. Bulk transfer is slowed > down, but with sending updates only, this should not be a problem. > Startup message transfer would take a little bit longer, but might > be faster than TCP in many cases. Without a sequence number in the messages and ACKs we can only do "Stop=20 and Wait", which means the Radio has to wait for the ACK before it can=20 send a second message. > An alternative for congestion avoidance would be rate limiting. This > needs a parameter. Not my preference. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms030506020608020801000202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAwODIwMjZaMCMGCSqGSIb3DQEJBDEWBBTb4p8LHL6NlIpRigEvjacvQy09szBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAe6Ok+rL2LF6SvXrf0nLK0gYTYXm2+2sWBZD22kl6UfO8 YR/pvJ0BO7kcKZxUdsqq+uGI0oS5hr+fHkbSUXbklClJw5Ncwiy3jHnhYqiX57WTNCD+mbpP mpITrnMIflbAFlJ2ZY7TcUce4t22Vk7jxrXNwQ0AUtv0/KlTVB9CdzW1VEdpAJ3wT96DC7bQ 4ztWfU9DDuecURaHqCYvOKpQ8v3s+iLBTfcrj2wclr+exhxSrJoeZKvJyk3y79FdJ9qeDG6Y X7K88a1DZvQNChBgWWkzFjNprBPIKvBrL5pmVgk8wzWJSjZKRRfzILhbbXq7/AM/FNoNB8wV lRAGkfGCcQAAAAAAAA== --------------ms030506020608020801000202-- From teco@inf-net.nl Wed Oct 10 02:02:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF721F873C for ; Wed, 10 Oct 2012 02:02:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx7KulXrU30W for ; Wed, 10 Oct 2012 02:02:33 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEE421F8731 for ; Wed, 10 Oct 2012 02:02:32 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so193973eek.31 for ; Wed, 10 Oct 2012 02:02:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rKfbyXnlait+lDFIMtq6F2pTH0GVLDHTIBokmaMGjoQ=; b=pQ0ipHZG6vRTo5LXxXt7COqZx/8Am/xARLSw7Gk+xeEq8oR4d0g8jvnOiREoS6RHro t89xyfeBw5s5OdK64Il1Qh2hXU+3bFRQXEjwbLz0VdD3lWcC9LPjsqonRx0FXA/c61I2 TpwuRAD5aRjvFnhvjwf424f6mQ7R90W5JhQtXzfaH7bDlxL5m30AxB5vIOa/V0X7Tr5b d32leSPIzQAhwWGMkFrZLQeQOQxvS5IoMGcEoNvWnYVj9SZiX3Z/kzWQga4kUxPziD41 spExbTZQpIyec2qr3UFKenVQOKNilHpDuyoaAQ4HayLy1modtQKh+8WMxIVajnXHg1Nr 1W1Q== Received: by 10.14.4.198 with SMTP id 46mr31951528eej.11.1349859751984; Wed, 10 Oct 2012 02:02:31 -0700 (PDT) Received: from [172.16.4.172] ([188.205.88.52]) by mx.google.com with ESMTPS id c6sm1175225eep.17.2012.10.10.02.02.30 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 02:02:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <50752FC6.5050901@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 11:02:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19000B20-1B1F-43B3-8EEB-C6C3BBA44DC3@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <50752FC6.5050901@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnViY+7IMORryafayLzGJ4J5xtVj1FISDRdDXucC/sVgSunjsdLquZNQbyyaY1HnyPVeGEj Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 09:02:40 -0000 Op 10 okt. 2012, om 10:20 heeft Henning Rogge het volgende geschreven: > Am 10.10.2012 09:30, schrieb Teco Boot: >> Some thoughts on how we may get out of some issues. If we use >> RFC 2119 SHOULD language for what is needed for a standard, >> we can accept modified implementations. >>=20 >> So we can say: >> o And DLEP implementations SHOULD use UDP >> o And DLEP implementations SHOULD use heartbeats >> o And DLEP implementations SHOULD use ACK >=20 > If ACK stays optional, we have to make sure this will not lead to = starvation. It is not "we have to make sure". The implementer of the protocol that does not implement=20 the SHOULD must take care if this. >=20 > What happens if we have a Radio that supports ACKs (and expects them) = but the Router does NOT? The router vendor MUST solve this problem. We are done. >=20 > Wouldn't the Radio wait for ACKs that will never arrive and maybe even = terminate the session because of this? I don't care. I will not buy such a router. >=20 >> etc. >>=20 >> If we think TCP is overkill (I can accept that), we can specify >> each single packet (or message) SHOULD be ACKked. This provides >> reliability and eliminates any congestion. Bulk transfer is slowed >> down, but with sending updates only, this should not be a problem. >> Startup message transfer would take a little bit longer, but might >> be faster than TCP in many cases. >=20 > Without a sequence number in the messages and ACKs we can only do = "Stop and Wait", which means the Radio has to wait for the ACK before it = can send a second message. Yes. This circumvents congestion. If windowing is required, I suggest TCP. I recommend sequence numbers in any case, this makes=20 the protocol somewhat more robust. Also more easy to troubleshoot. Teco >=20 >> An alternative for congestion avoidance would be rate limiting. This >> needs a parameter. Not my preference. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 From thomas@thomasclausen.org Wed Oct 10 02:04:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A1221F86EA for ; Wed, 10 Oct 2012 02:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s+Lrq7Qb-Zu for ; Wed, 10 Oct 2012 02:04:40 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DF81A21F86E8 for ; Wed, 10 Oct 2012 02:04:40 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 7AC78558B07 for ; Wed, 10 Oct 2012 02:04:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B29C81BC1B3D; Wed, 10 Oct 2012 02:04:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9D2E71BC1B3B; Wed, 10 Oct 2012 02:04:36 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Clausen In-Reply-To: <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> Date: Wed, 10 Oct 2012 11:04:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1498) Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 09:04:41 -0000 On Oct 10, 2012, at 9:30 AM, Teco Boot wrote: > Some thoughts on how we may get out of some issues. If we use=20 > RFC 2119 SHOULD language for what is needed for a standard,=20 > we can accept modified implementations. >=20 > So we can say: > o And DLEP implementations SHOULD use UDP > o And DLEP implementations SHOULD use heartbeats > o And DLEP implementations SHOULD use ACK > etc. >=20 Uhh, I am no great fan of SHOULD - it seems a cop-out, unless it is well = argued under which circumstances and with which consequences one can = deviate from the SHOULD. Generally, most SHOULD SHOULD be MUST - or so I've heard the saying go = ;)=20 > If we think TCP is overkill (I can accept that), we can specify > each single packet (or message) SHOULD be ACKked. This provides > reliability and eliminates any congestion. Not if it is a SHOULD; it may increase congestion (if someone does not = ACK, for example, with an aggressive retransmission schedule). My preference is a much much tighter specification than generous use of = SHOULD. Thomas > Bulk transfer is slowed > down, but with sending updates only, this should not be a problem. > Startup message transfer would take a little bit longer, but might=20 > be faster than TCP in many cases. > An alternative for congestion avoidance would be rate limiting. This=20= > needs a parameter. Not my preference. >=20 > Teco >=20 >=20 > Op 10 okt. 2012, om 08:29 heeft Henning Rogge het volgende geschreven: >=20 >> On 10/09/2012 09:30 PM, Bo Berry wrote: >>> Teco >>> I reviewed >>> Request for Comments: 5405 >>> BCP: 145, Unicast UDP Usage Guidelines for Application Designers >>>=20 >>> DLEP is only control plane traffic between the router and its >>> connected radio. The draft should allow for driver implementations >>> (pci SDRs for example) as well as ethernet protocols: UDP, SCTP, >>> TLS. So abstracting DLEP from the transport is good. >>=20 >> If we allow this (especially the pci part), we cannot use the IP/port = tuple as a router/radio identification. >>=20 >> I see the reason for this (and one of the suggestions of the original = DLEP proposal was to make it transport independent). >>=20 >> Can we maybe handle this with an OPTIONAL identification TLV of (at = least) six bytes for both router and radio? The standard could define = that in the absence of this tuples and the usage of IP/UDP, the IP/Port = combination MUST be used as an id. >>=20 >> The problem is that with IPv6 we will have 18-bytes tuples for radio = and for router (for a total of 36 bytes). Either we have to specify that = this is a valid ID or we might break some router/radio implementations = because they expect only 4 or 6 bytes. >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Wed Oct 10 02:08:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CFC21F8738 for ; Wed, 10 Oct 2012 02:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhIJh-AIEyD3 for ; Wed, 10 Oct 2012 02:08:10 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1C46321F87D5 for ; Wed, 10 Oct 2012 02:08:10 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLsGv-0006u6-8I; Wed, 10 Oct 2012 11:08:09 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLsGv-0000T1-5b; Wed, 10 Oct 2012 11:08:09 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 11:08:08 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 11:08:08 +0200 Message-ID: <50753AF7.10401@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 11:08:07 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Teco Boot References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <50752FC6.5050901@fkie.fraunhofer.de> <19000B20-1B1F-43B3-8EEB-C6C3BBA44DC3@inf-net.nl > In-Reply-To: <19000B20-1B1F-43B3-8EEB-C6C3BBA44DC3@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010809090903000005040503" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 09:08:08.0997 (UTC) FILETIME=[C4416D50:01CDA6C6] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7fbbc3bfe2de368a9522e1ccdb970b4 Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 09:08:12 -0000 --------------ms010809090903000005040503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 10.10.2012 11:02, schrieb Teco Boot: > > Op 10 okt. 2012, om 10:20 heeft Henning Rogge het volgende geschreven: > >> Am 10.10.2012 09:30, schrieb Teco Boot: >>> Some thoughts on how we may get out of some issues. If we use >>> RFC 2119 SHOULD language for what is needed for a standard, >>> we can accept modified implementations. >>> >>> So we can say: >>> o And DLEP implementations SHOULD use UDP >>> o And DLEP implementations SHOULD use heartbeats >>> o And DLEP implementations SHOULD use ACK >> >> If ACK stays optional, we have to make sure this will not lead to star= vation. > It is not "we have to make sure". > The implementer of the protocol that does not implement > the SHOULD must take care if this. This doesn't work if its not well specified how the protocol will handle = this case. > > >> >> What happens if we have a Radio that supports ACKs (and expects them) = but the Router does NOT? > The router vendor MUST solve this problem. We are done. The router vendor CAN NOT solve this problem, because the protocol does=20 not specify how the radio will react. >> Wouldn't the Radio wait for ACKs that will never arrive and maybe even= terminate the session because of this? > I don't care. I will not buy such a router. If the protocol does not describe how interaction will work between an=20 implementation supporting an optional feature and one NOT supporting it, = the feature should not be optional. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010809090903000005040503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAwOTA4MDdaMCMGCSqGSIb3DQEJBDEWBBSnsoNoIjyM+CKkd0tksOm7QbEQiDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAYxkLyyZsgNrpf1EvUEaFNPPMqKcKAAexwnRNjHhWDKjI 1PsM9+ZCNxdFurZUMg5PyLIGTL9npj4Ba92J5CmDjvObjVE8Yk5XhPvQtkSyzJy3C2/+OZoA aBSj/cdO7Sxu9NLRoTaoZFM59hz4vmGd6MRUzVslR88KgaTBEpQFGpT8FD5+AKcESqyknksS XmzeAiqD72e1nKQzj6I6EH9V0GI836tU7DymeLaZVSOAwl38tb0sdzcmPSFlf7CukMOO40ox QJF+OXvgyNhzjVE+yHbgiif1d661R/iD0z1uBdXFM1WFms1DRhC46kh0W32Iiff06sByFxcA Fc/sb/YFJwAAAAAAAA== --------------ms010809090903000005040503-- From teco@inf-net.nl Wed Oct 10 04:11:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86B21F8724 for ; Wed, 10 Oct 2012 04:11:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcNKw3F77JHU for ; Wed, 10 Oct 2012 04:11:04 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA4821F86C9 for ; Wed, 10 Oct 2012 04:11:03 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so288771eek.31 for ; Wed, 10 Oct 2012 04:11:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=kCSCCD1rpkN2xZpGvbhfAV/Rvj4at5Pwcu3s6ckKy3I=; b=QPg467mKGSBqWiVWukEG8kVickhBSiqav/gSLoVGAZIZjzT5QakJaec/0bYYuIpDnq ESwm1aFmNl9vv5Knf+HkTHDO9pWIa411ya6jkGuCfREdo/cPkUdnRVbuMfqk2AlTI8oH kWof5XqvsmN9pZBjBxCExyWlkm9voCBaHsJjvMpLegSvSfVQgfvg4uMEQofqaVba6uTz 3jXItrvoocZ2WbNfT1VPvlZUFsOKiYib3i/inyNt3LfRFfMHeR2COOjoPzDEczTc3+Ve 65OLGVazNlW/DTRHU50wscJCZm027hNjBEjw8J789JD7FjICysAs6R6EmxkbH6UJTRcS ZOJQ== Received: by 10.14.203.70 with SMTP id e46mr32469208eeo.2.1349867462767; Wed, 10 Oct 2012 04:11:02 -0700 (PDT) Received: from [172.16.4.172] ([188.205.88.52]) by mx.google.com with ESMTPS id t1sm1723936eeo.3.2012.10.10.04.11.01 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 04:11:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> Date: Wed, 10 Oct 2012 13:11:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8315B77D-759C-47AD-9494-8CE907669F0F@inf-net.nl> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> To: Thomas Clausen X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlzl6xILEOHFILIEUgTCrM+kwwockdefJzW/LkNj78WyIW8q3yHenWVJ+5J3PjdXl5bcUh7 Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:11:06 -0000 Op 10 okt. 2012, om 11:04 heeft Thomas Clausen het volgende geschreven: >=20 > On Oct 10, 2012, at 9:30 AM, Teco Boot wrote: >=20 >> Some thoughts on how we may get out of some issues. If we use=20 >> RFC 2119 SHOULD language for what is needed for a standard,=20 >> we can accept modified implementations. >>=20 >> So we can say: >> o And DLEP implementations SHOULD use UDP >> o And DLEP implementations SHOULD use heartbeats >> o And DLEP implementations SHOULD use ACK >> etc. >>=20 >=20 > Uhh, I am no great fan of SHOULD - it seems a cop-out, unless it is = well argued under which circumstances and with which consequences one = can deviate from the SHOULD. >=20 > Generally, most SHOULD SHOULD be MUST - or so I've heard the saying go = ;)=20 Yes, RFC 2119 does say something like that. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I read this as that the implementer MUST do something to be compliant = and takes full responsibility of all problems not fulfilling the = requirement. >=20 >> If we think TCP is overkill (I can accept that), we can specify >> each single packet (or message) SHOULD be ACKked. This provides >> reliability and eliminates any congestion. >=20 > Not if it is a SHOULD; it may increase congestion (if someone does not = ACK, for example, with an aggressive retransmission schedule). Again, blame and shame the implementer. And to be honest with you, I try = to keep some distance with implementers that do not implement the SHOULD = and do not take responsibility. >=20 > My preference is a much much tighter specification than generous use = of SHOULD. Me too. Teco >=20 > Thomas >=20 >=20 >> Bulk transfer is slowed >> down, but with sending updates only, this should not be a problem. >> Startup message transfer would take a little bit longer, but might=20 >> be faster than TCP in many cases. >> An alternative for congestion avoidance would be rate limiting. This=20= >> needs a parameter. Not my preference. >>=20 >> Teco >>=20 >>=20 >> Op 10 okt. 2012, om 08:29 heeft Henning Rogge het volgende = geschreven: >>=20 >>> On 10/09/2012 09:30 PM, Bo Berry wrote: >>>> Teco >>>> I reviewed >>>> Request for Comments: 5405 >>>> BCP: 145, Unicast UDP Usage Guidelines for Application Designers >>>>=20 >>>> DLEP is only control plane traffic between the router and its >>>> connected radio. The draft should allow for driver implementations >>>> (pci SDRs for example) as well as ethernet protocols: UDP, SCTP, >>>> TLS. So abstracting DLEP from the transport is good. >>>=20 >>> If we allow this (especially the pci part), we cannot use the = IP/port tuple as a router/radio identification. >>>=20 >>> I see the reason for this (and one of the suggestions of the = original DLEP proposal was to make it transport independent). >>>=20 >>> Can we maybe handle this with an OPTIONAL identification TLV of (at = least) six bytes for both router and radio? The standard could define = that in the absence of this tuples and the usage of IP/UDP, the IP/Port = combination MUST be used as an id. >>>=20 >>> The problem is that with IPv6 we will have 18-bytes tuples for radio = and for router (for a total of 36 bytes). Either we have to specify that = this is a valid ID or we might break some router/radio implementations = because they expect only 4 or 6 bytes. >>>=20 >>> Henning Rogge >>>=20 >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From boberry@cisco.com Wed Oct 10 04:19:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8958821F8611 for ; Wed, 10 Oct 2012 04:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bemWgUugsyBO for ; Wed, 10 Oct 2012 04:19:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E77C721F8587 for ; Wed, 10 Oct 2012 04:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1853; q=dns/txt; s=iport; t=1349867946; x=1351077546; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7KNmH1+CgUnqhuvv47qRjzLpKas5zQyw/PEdHe56wM8=; b=e3l592ZogVKVueaZMheiqtI4FxLhoA1B+6UpTidXiumU9ib7FuEkaVXy EUg4d6wj1QjzOIrrv6biE4eaCCySjyzNhYI8ocaJ2sBZGjLzvNNg49uvH Q66Veyoon/gctgW/M0KjsjVntU1xbOW1VLN69CQBYxyQ6WzcbzpU2nD6Q I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPlYdVCtJV2b/2dsb2JhbABEvyuBCIIgAQEBAwESAWYFCwsYJwdGEQYTIoddBpcooCCLRoVAYAOVa4ViiGOBa4MJ X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="130141069" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 10 Oct 2012 11:19:05 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-73.cisco.com [10.81.230.73]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9ABJ4Wi015719; Wed, 10 Oct 2012 11:19:04 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <507515B1.5030809@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 07:19:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:19:15 -0000 On Oct 10, 2012, at 2:29 AM, Henning Rogge wrote: > On 10/09/2012 09:30 PM, Bo Berry wrote: >> Teco >> I reviewed >> Request for Comments: 5405 >> BCP: 145, Unicast UDP Usage Guidelines for Application Designers >>=20 >> DLEP is only control plane traffic between the router and its >> connected radio. The draft should allow for driver implementations >> (pci SDRs for example) as well as ethernet protocols: UDP, SCTP, >> TLS. So abstracting DLEP from the transport is good. >=20 > If we allow this (especially the pci part), we cannot use the IP/port = tuple as a router/radio identification. >=20 > I see the reason for this (and one of the suggestions of the original = DLEP proposal was to make it transport independent). >=20 > Can we maybe handle this with an OPTIONAL identification TLV of (at = least) six bytes for both router and radio? The standard could define = that in the absence of this tuples and the usage of IP/UDP, the IP/Port = combination MUST be used as an id. >=20 > The problem is that with IPv6 we will have 18-bytes tuples for radio = and for router (for a total of 36 bytes). Either we have to specify that = this is a valid ID or we might break some router/radio implementations = because they expect only 4 or 6 bytes. The driver will know how to discriminate and address the card. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Wed Oct 10 04:23:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AE921F8606 for ; Wed, 10 Oct 2012 04:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tREiNXzEBSBH for ; Wed, 10 Oct 2012 04:23:34 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D661021F855D for ; Wed, 10 Oct 2012 04:23:33 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLuNx-0001Tk-7O; Wed, 10 Oct 2012 13:23:33 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLuNx-00049x-4i; Wed, 10 Oct 2012 13:23:33 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 13:23:32 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 13:23:32 +0200 Message-ID: <50755AA2.7040607@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 13:23:14 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010800030902070900010904" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 11:23:32.0924 (UTC) FILETIME=[AE7E4FC0:01CDA6D9] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8a842d9e11f1c1d58316de1cda04e013 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:23:34 -0000 --------------ms010800030902070900010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/10/2012 01:19 PM, Bo Berry wrote: > On Oct 10, 2012, at 2:29 AM, Henning Rogge wrote: >> If we allow this (especially the pci part), we cannot use the >> IP/port tuple as a router/radio identification. >> >> I see the reason for this (and one of the suggestions of the >> original DLEP proposal was to make it transport independent). >> >> Can we maybe handle this with an OPTIONAL identification TLV of (at >> least) six bytes for both router and radio? The standard could >> define that in the absence of this tuples and the usage of IP/UDP, >> the IP/Port combination MUST be used as an id. >> >> The problem is that with IPv6 we will have 18-bytes tuples for >> radio and for router (for a total of 36 bytes). Either we have to >> specify that this is a valid ID or we might break some router/radio >> implementations because they expect only 4 or 6 bytes. > > The driver will know how to discriminate and address the card. We should at least mention in the DLEP document that the ID that=20 determines the router/radio pair can be up to 36 bytes (when using IPv6).= An optional ID TLV for transports without addresses/ports could be=20 smaller (still would like 6 bytes for radio and 6 bytes for router here).= Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010800030902070900010904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAxMTIzMzBaMCMGCSqGSIb3DQEJBDEWBBSfk0p1lVq4RYC2oEPMA0l5+Z4CuzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAvikl33x7C6rfvkdfN/vOsTb3zCCgzOdwWHdQ5fLyQOAW +SDuG+ZMkbJAkisDl+NJpqiqfhJLQoiJvAdyIm5VC3C4TyF6DGMLGEVmYOIw8mf52lZkTR6c LFJN2ofvKuLfy4DFjGaKc9Jq+ozihbF+0vZzKkUCNbBiPyuTSBDurRGPsPoBR/w+ECW3BFO5 M68yW3+okpTqGxRG1Vp0lNdlIZSzEBotedwc3K/YBtEU//gRtJRyEqnfq7alV1Z2GrVUlgDJ s6cYr+v/ol8MzfLZELckyS9szOqkftY2p+yHCKoRhyFmbSDxybzzi+BMwrsEp24AL3iQF+q+ aPlG/qHhZwAAAAAAAA== --------------ms010800030902070900010904-- From boberry@cisco.com Wed Oct 10 04:25:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5411321F8707 for ; Wed, 10 Oct 2012 04:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIVSh6YleHc3 for ; Wed, 10 Oct 2012 04:25:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ACB7421F8704 for ; Wed, 10 Oct 2012 04:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2587; q=dns/txt; s=iport; t=1349868301; x=1351077901; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=3sjb/08SJvekDz22f07/5cWGN/s+xiE5Kxjn1PwXjmY=; b=Jbq66IRi6j2AgUloeJbkyQ/qJQyauVO0DJfonhFgGZ51S07sRvqL6rc+ eNeXXkVxjkQxazn8efzgqHuR9Zch2ayc+l+PRAX6qZRZjbytYNFpMVSbw 7zycwjcRpf5FhgsGzmL1YkeyeHHj942bIDboCKvEZkCN30wo4LCbzWjNb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANFZdVCtJXG+/2dsb2JhbABEvyuBCIIgAQEBAwEBAQEPAVsLBQsLGCcHJx8RBhMih10GC5ceoCCLRoVAYAOVa4ViiGOBa4MJ X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="129883252" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 10 Oct 2012 11:25:01 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-73.cisco.com [10.81.230.73]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9ABP0f2028116; Wed, 10 Oct 2012 11:25:00 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <507512BA.2000908@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 07:25:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fki e.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:25:02 -0000 On Oct 10, 2012, at 2:16 AM, Henning Rogge wrote: > On 10/10/2012 12:18 AM, Bo Berry wrote: >> This sounds like a radio requirement. I do not think having a RLQ >> should be a prerequisite for a neighbor. The radio should be able to >> report neighbor status by excluding the TLV. For example, if I build >> one radio that constantly sends (hard codes) RLQ=3D100 and another >> radio that dynamically computes-reports RLQ and another radio that >> never sends RLQ (and the spectrums are compatible), DLEP should >> handle all. >>=20 >> Another metric, resources, is also a percentage (0-100). What if a >> radio has no means to compute resources? The radio should be able to >> exclude this TLV also, or simply report 100. Again if I build a >> simple radio and hard code resources to 100, its compliant. >>=20 >> Suggest these tlvs be optional or let the radio send 100. I'm OK >> with an unknown value (255). >>=20 >> The router obviously will need to handle the diff cases. >=20 > As long this is well documented, the 255 value should be easy to = handle. > If the local router does not want to deal with it, it just can drop = the > TLV processing internally. >=20 > I think that is exactly what we have to work on through the whole = draft. > It contains too many degrees of freedom which have to be interpreted, = we need to specify the one that could create incompatible = implementations. The degrees of freedom are important from my perspective/experiences.=20 Radios tend to very tight on resource with specialized processing. If I build a new radio with DLEP in mind perhaps I would choose to=20 implement all the features. If I'm adopting an existing radio by adding DLEP functionality, I may be able to support a minimum set=20 of features.=20 Adding DLEP to an 802.11 radio is much different that adding DLEP to mi smart phone which is diff than adding DLEP to a specialized radio. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Wed Oct 10 04:35:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255DA21F8575 for ; Wed, 10 Oct 2012 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3fRBojRckYT for ; Wed, 10 Oct 2012 04:35:57 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B61B21F8533 for ; Wed, 10 Oct 2012 04:35:56 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLuZv-0005LV-LF; Wed, 10 Oct 2012 13:35:55 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLuZv-0004Z8-IY; Wed, 10 Oct 2012 13:35:55 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 13:35:55 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 13:35:54 +0200 Message-ID: <50755D99.6040208@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 13:35:53 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> In-Reply-To: <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050604070903090605020904" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 11:35:55.0381 (UTC) FILETIME=[69084250:01CDA6DB] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: da8eb4258d586be99f3c918cac8a614c Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:35:58 -0000 --------------ms050604070903090605020904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/10/2012 01:25 PM, Bo Berry wrote: > On Oct 10, 2012, at 2:16 AM, Henning Rogge wrote: >> I think that is exactly what we have to work on through the whole >> draft. It contains too many degrees of freedom which have to be >> interpreted, we need to specify the one that could create >> incompatible implementations. > > The degrees of freedom are important from my > perspective/experiences. Radios tend to very tight on resource with > specialized processing. If I build a new radio with DLEP in mind > perhaps I would choose to implement all the features. If I'm > adopting an existing radio by adding DLEP functionality, I may be > able to support a minimum set of features. I don't want to remove all "degrees of freedom", I am just worried that=20 some of them will break interoperability for DLEP. Restricting the=20 number of working optional features is no problem, but if DLEP doesn't=20 work at all because of a different set of optional features we forgot to = put something important into the draft. I think we are doing good work with the "radio metric" TLVs and the=20 Discovery mechanism at the moment. But I would really like to hear your opinion how the "optional ACK"=20 mechanism will work. Because DLEP Radio and DLEP Router will (most likely) come from=20 different companies, these companies might choose to differently with=20 the options. And they should be able to do so without breaking the basic = protocol. The case I worry about is a Radio company choosing to "support" ACKs=20 (its expecting an ACK as a reply to its neighbor updates) and a Router=20 company choosing not to support ACKs. I think the combination of this two devices will break the basic=20 protocol with the current specification. > Adding DLEP to an 802.11 radio is much different that adding DLEP to > mi smart phone which is diff than adding DLEP to a specialized > radio. I know. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050604070903090605020904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAxMTM1NTNaMCMGCSqGSIb3DQEJBDEWBBRiFtJ88qCycMg/0OL4dSXlWXyO2DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAo6vPbGCvxZzXOKlqdIJWfn37gAR8vsUpmGhLFvDEMTtI dzo9qkHQVk1cd9GH2/XGnR6gp39C6xE4OMVSrqMGQHC4e2tvrtupVrpKxjF65gLqsjDQmg3t vkg/ZNnPLBr6tjJrwDFbjvViOY9Ha7Orfsj7QrLjA9WkZG2oBqEc9hlSFpv/yq/ocZ7BerP3 l/RK8w/2rXbp3E5sNw/IUXzGdG18w1IVGdXIQhFYC4sG7Kldf6pskKL8qEI8lsGX2mVQ/NWt VAhe7l58qpig81LYWZpFQRcEQ8h9I8S8Afrpyls9y4XsS3Fp05FaavQHPw4rB4jUb8eUeOIp 1i/w70HxAgAAAAAAAA== --------------ms050604070903090605020904-- From boberry@cisco.com Wed Oct 10 05:07:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C71F21F876F for ; Wed, 10 Oct 2012 05:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCO0R6oLCQaq for ; Wed, 10 Oct 2012 05:07:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 29D3B21F876C for ; Wed, 10 Oct 2012 05:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3386; q=dns/txt; s=iport; t=1349870827; x=1351080427; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=96WG/+629VLAga7TElgjxVTR0KQshHgXIMqEQfWp04k=; b=U1b3vMNVHszCuyDS/I1yTxT9TYxCy72O3p6CXGa2bABz32stWohTK8YA nwnwiEbbSuTDt1skd89+FuHiVYVBIyjQwHgu/Vf7IRj4ngveH/8fUtGBO OBvU5j75BsqvqmSyKAw2qBxw0IVDXXxUESYsABjCKxnmJ4QgpjZWIw6+k k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOxjdVCtJXHA/2dsb2JhbABEvyuBCIIgAQEBAwESAWYFCwsYJwdGEQYTIoddBpc4oB6LRoVAYAOVa4ViiGOBa4MJ X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="127113689" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 10 Oct 2012 12:07:06 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-73.cisco.com [10.81.230.73]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9AC7699002265; Wed, 10 Oct 2012 12:07:06 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <50755D99.6040208@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 08:07:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:07:08 -0000 On Oct 10, 2012, at 7:35 AM, Henning Rogge wrote: > On 10/10/2012 01:25 PM, Bo Berry wrote: >> On Oct 10, 2012, at 2:16 AM, Henning Rogge wrote: >>> I think that is exactly what we have to work on through the whole >>> draft. It contains too many degrees of freedom which have to be >>> interpreted, we need to specify the one that could create >>> incompatible implementations. >>=20 >> The degrees of freedom are important from my >> perspective/experiences. Radios tend to very tight on resource with >> specialized processing. If I build a new radio with DLEP in mind >> perhaps I would choose to implement all the features. If I'm >> adopting an existing radio by adding DLEP functionality, I may be >> able to support a minimum set of features. >=20 > I don't want to remove all "degrees of freedom", I am just worried = that some of them will break interoperability for DLEP. Restricting the = number of working optional features is no problem, but if DLEP doesn't = work at all because of a different set of optional features we forgot to = put something important into the draft. >=20 > I think we are doing good work with the "radio metric" TLVs and the = Discovery mechanism at the moment. Agree, a lot of good is happening! Thanks for your points. > But I would really like to hear your opinion how the "optional ACK" = mechanism will work. >=20 > Because DLEP Radio and DLEP Router will (most likely) come from = different companies, these companies might choose to differently with = the options. And they should be able to do so without breaking the basic = protocol. exactly. The ability to configure DLEP values (timeouts, retrys, etc) = and enable/disable options will be key, for both the radio and the = router. A router implementation that offers greater degrees of freedom = (to use the term above) would be better positioned to support a wider = spectrum of radios. =20 I'm not a fan of optional ACKs. It makes a messy spec and would be = difficult support/sustain. Through the WG, we've reduced the number of = sessions and associated messages. Agree we need to clarify various = aspects and nail down a few features, but let's do so carefully with = flexibility in mind and careful not to exclude opportunities. I think DLEP is (and should be) a simple protocol, one that can be = extended for new features. =20 >=20 > The case I worry about is a Radio company choosing to "support" ACKs = (its expecting an ACK as a reply to its neighbor updates) and a Router = company choosing not to support ACKs.=20 >=20 > I think the combination of this two devices will break the basic = protocol with the current specification. >=20 >> Adding DLEP to an 802.11 radio is much different that adding DLEP to >> mi smart phone which is diff than adding DLEP to a specialized >> radio. >=20 > I know. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Wed Oct 10 05:14:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C9621F86A5 for ; Wed, 10 Oct 2012 05:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBEDS-o9huei for ; Wed, 10 Oct 2012 05:14:31 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADD321F8679 for ; Wed, 10 Oct 2012 05:14:31 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLvBF-0001MG-Qv; Wed, 10 Oct 2012 14:14:29 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLvBF-0005Vn-OE; Wed, 10 Oct 2012 14:14:29 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 14:14:29 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 14:14:29 +0200 Message-ID: <5075669F.90706@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 14:14:23 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> In-Reply-To: <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070106040609060801040101" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 12:14:29.0552 (UTC) FILETIME=[CC62BB00:01CDA6E0] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 676a75961403c53da43f811dd9e91d0e Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:14:32 -0000 --------------ms070106040609060801040101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/10/2012 02:07 PM, Bo Berry wrote: >> I think we are doing good work with the "radio metric" TLVs and the >> Discovery mechanism at the moment. > > Agree, a lot of good is happening! Thanks for your points. > >> But I would really like to hear your opinion how the "optional ACK" >> mechanism will work. >> >> Because DLEP Radio and DLEP Router will (most likely) come from >> different companies, these companies might choose to differently >> with the options. And they should be able to do so without breaking >> the basic protocol. > > exactly. The ability to configure DLEP values (timeouts, retrys, > etc) and enable/disable options will be key, for both the radio and > the router. A router implementation that offers greater degrees of > freedom (to use the term above) would be better positioned to support > a wider spectrum of radios. > > I'm not a fan of optional ACKs. It makes a messy spec and would be > difficult support/sustain. Through the WG, we've reduced the number > of sessions and associated messages. Agree we need to clarify > various aspects and nail down a few features, but let's do so > carefully with flexibility in mind and careful not to exclude > opportunities. Yes. DLEP should work as well on a 30$ 802.11 access point as on a 10000$+=20 multi-line software defined radio. > I think DLEP is (and should be) a simple protocol, one that can be > extended for new features. I see two "easy" ways out. 1.) the router has to tell the radio if it will reply with ACKs. If the=20 radio supports ACKs too, the radio can adapt its strategy according to=20 the information from the router. 2.) the router MUST produce ACKs, but the radio can choose to ignore them= =2E Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070106040609060801040101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAxMjE0MjdaMCMGCSqGSIb3DQEJBDEWBBRtuJZDAzW4t4FF3zkKolM3VWkINDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAnigi4RrOTAsRIP4wzeWnfSGoHSIZoY+XolwjZZEz7dLs UfLGHulzBEd6aD0CdUOaP10S0+73fjiYkw8qWfFOjCoWP2QYiMnmraHOWaUthczXnch85l8z sM7VqldVqmTN2KjNKnww/WRo6R0Yp//qqHFwKIMSGKAdj5YZ7zuY+MBro3BkweG5yrUDtzBl 2a6CgHn0ZPJsihpybmgSwSfA620Q1O0E7iWQSxq0Ul27TEMVppKNHRfJz4OpD/ZTGaxV6SZ3 wAHGInlHHUlPxjtsxQCK/PeEv6eJCaMF+/ltiV5nmt5vdJoATlbsrbhPzoPOT3iAssX5p099 PJccVoo3tQAAAAAAAA== --------------ms070106040609060801040101-- From teco@inf-net.nl Wed Oct 10 05:24:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C665621F8588 for ; Wed, 10 Oct 2012 05:24:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0Pg4Qkx6AWA for ; Wed, 10 Oct 2012 05:24:16 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C702221F84F2 for ; Wed, 10 Oct 2012 05:24:15 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so343663eek.31 for ; Wed, 10 Oct 2012 05:24:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=M2SKqPNcUioQULZSliiyVNV3NV2J3N2Q3HeqqJZyxhA=; b=pjvWE3wiXBX5nvxn7IRL0vJ8IfSe4mPZ457YF5Fah7Hy3Ft8DVfDebWJ7t4YVOWCAn SF+8P+1VJ8FxsnWyOlRSZHveVnLOpYKaxsacIFK0GmVvadoYHyb7UHtr9vSQa9kFj8BP AC8K/OUw7tgi3/ep64A/Vbfv5deDIfPbNFR2BAdp6VJCWlFL2gufqT6Dtd9J92mKMMNj i7JJAAXO52892LuDRoBxPiRxDHWIyVImiVAvZu9HdkKyQFezl15BDoJs6FzHqDEzfc3f /WaOUlSLV6TdkFeKp/0y9zsXJUgcQv0N7e8oRmU/s7GZhGaJfclC4hCRYTKwUKAqE0aX uSfg== Received: by 10.14.215.69 with SMTP id d45mr32355019eep.16.1349871854124; Wed, 10 Oct 2012 05:24:14 -0700 (PDT) Received: from [172.16.4.172] ([188.205.88.52]) by mx.google.com with ESMTPS id d44sm2008470eeo.10.2012.10.10.05.24.11 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 05:24:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <5075669F.90706@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 14:24:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQla+nSa9Yahuyv9yUW9nGOYXjlTOee5FA8EgqWhuX2UVeBgOl1UMCty2p8YaNCkKromfZ8t Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:24:16 -0000 Op 10 okt. 2012, om 14:14 heeft Henning Rogge het volgende geschreven: > On 10/10/2012 02:07 PM, Bo Berry wrote: >>> I think we are doing good work with the "radio metric" TLVs and the >>> Discovery mechanism at the moment. >>=20 >> Agree, a lot of good is happening! Thanks for your points. >>=20 >>> But I would really like to hear your opinion how the "optional ACK" >>> mechanism will work. >>>=20 >>> Because DLEP Radio and DLEP Router will (most likely) come from >>> different companies, these companies might choose to differently >>> with the options. And they should be able to do so without breaking >>> the basic protocol. >>=20 >> exactly. The ability to configure DLEP values (timeouts, retrys, >> etc) and enable/disable options will be key, for both the radio and >> the router. A router implementation that offers greater degrees of >> freedom (to use the term above) would be better positioned to support >> a wider spectrum of radios. >>=20 >> I'm not a fan of optional ACKs. It makes a messy spec and would be >> difficult support/sustain. Through the WG, we've reduced the number >> of sessions and associated messages. Agree we need to clarify >> various aspects and nail down a few features, but let's do so >> carefully with flexibility in mind and careful not to exclude >> opportunities. >=20 > Yes. >=20 > DLEP should work as well on a 30$ 802.11 access point as on a 10000$+ = multi-line software defined radio. >=20 >> I think DLEP is (and should be) a simple protocol, one that can be >> extended for new features. >=20 > I see two "easy" ways out. >=20 > 1.) the router has to tell the radio if it will reply with ACKs. If = the radio supports ACKs too, the radio can adapt its strategy according = to the information from the router. >=20 > 2.) the router MUST produce ACKs, but the radio can choose to ignore = them. Or just implement the ACKs. That solves lots of problems. (or the vtime mechanism as alternative option, with pros and cons). Teco >=20 >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Wed Oct 10 05:26:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1095F21F86C9 for ; Wed, 10 Oct 2012 05:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSK+9CouEb7c for ; Wed, 10 Oct 2012 05:26:50 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6F521F86C6 for ; Wed, 10 Oct 2012 05:26:50 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLvNA-0006Ip-6y; Wed, 10 Oct 2012 14:26:48 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLvNA-0005uw-4G; Wed, 10 Oct 2012 14:26:48 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 14:26:47 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 14:26:47 +0200 Message-ID: <50756986.3070103@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 14:26:46 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Teco Boot References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> In-Reply-To: <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040304070203010906080708" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 12:26:47.0932 (UTC) FILETIME=[847E93C0:01CDA6E2] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:26:51 -0000 --------------ms040304070203010906080708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/10/2012 02:24 PM, Teco Boot wrote: > Op 10 okt. 2012, om 14:14 heeft Henning Rogge het volgende > geschreven: >> I see two "easy" ways out. >> >> 1.) the router has to tell the radio if it will reply with ACKs. If >> the radio supports ACKs too, the radio can adapt its strategy >> according to the information from the router. >> >> 2.) the router MUST produce ACKs, but the radio can choose to >> ignore them. > > Or just implement the ACKs. That solves lots of problems. This would be similar to option 2). But you are right, make ACK handling (on radio AND router) mandatory=20 would be a 3rd option. > (or the vtime mechanism as alternative option, with pros and cons). Yes. I still would prefer this solution, but it will be more work to=20 modify the draft in this way. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040304070203010906080708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAxMjI2NDZaMCMGCSqGSIb3DQEJBDEWBBTcbncZDzq0pOFqk/6weUp6CNCFlTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAozE/TjhUHPY3KHqvPg9+YwyxhVX+JChqrDLfLbUh2U48 GKFgz5J18xP8Jn5hAIIWmbafFQMat+lQL0tRH4SJ8H8f0dVWEfY9b6+Uf4INEHz7M27ISgeX LwYKi1W4nqGfk+aehE/fo9K7CFab/MCP1XlGv89B3QcYLwKH7HWmscymxD8sNIxmOKCv5oTX Sm+ztSEI46IkNiTwzr2uAC60UcvfE9E8J+xek/ciUjvv7MEJ8nrC9PqA8mbExpWoiqFas/cQ DsTLfabz9h4xh/q8XwnMwY83WHnyXoo9h5G9DmfQSEEqr39yF5ozOvTDOTO7jceEKu+uRD6q 0y9buucLVwAAAAAAAA== --------------ms040304070203010906080708-- From teco@inf-net.nl Wed Oct 10 06:04:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4F621F8587 for ; Wed, 10 Oct 2012 06:04:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBlNBuGF6T5P for ; Wed, 10 Oct 2012 06:04:33 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D048A21F856D for ; Wed, 10 Oct 2012 06:04:32 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so376159eek.31 for ; Wed, 10 Oct 2012 06:04:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=lu3LeFRD/pnX0SCWFG1f7RKl2+u4t1XTHPhhgzufc8Q=; b=YrbGGTIh4hq54+B0kUbLajpPlNhvs1eVwbNMvifympRRPCi23Pt5atAGsSDmev11is p/eZR2NF5G406Q0qUTM+nGiLczAVgbFLtE5Dwx+sGpmV2r5SR1/ox7Y7CKfhlTqQxRHE Ub418KdgE7aCv3ogpaav/7ZOgFzK8lpDy+qfSRvJoEY7fATL4nyWxIXrugBTdNbTeL0H 0pCRLen3gIQze+WiTxoVWbQl0tBIVLmeEFb9FoApvdf/TXKFjUkbEgib2Ob9hiyP6nsl WZFpAMJ712ObEf2bpiyRak46Mzk1d7lcv1BiIZ8EZtr1osk0tnzlhhU9gHiWKnJRgF6l DtFg== Received: by 10.14.209.129 with SMTP id s1mr32790774eeo.24.1349874271777; Wed, 10 Oct 2012 06:04:31 -0700 (PDT) Received: from [172.16.4.172] ([188.205.88.52]) by mx.google.com with ESMTPS id v3sm2186879een.1.2012.10.10.06.04.30 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 06:04:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <50756986.3070103@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 15:04:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> <50756986.3070103@fkie.fraunhofer.de > To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlFJWRGfLqLxL7EqhgNJPnxKkILF4qHFlOmIOPxzCWaaN8gU3IVBs4I/nqgB4azmV0Lgkj6 Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:04:33 -0000 Op 10 okt. 2012, om 14:26 heeft Henning Rogge het volgende geschreven: > On 10/10/2012 02:24 PM, Teco Boot wrote: >> Op 10 okt. 2012, om 14:14 heeft Henning Rogge het volgende >> geschreven: >>> I see two "easy" ways out. >>>=20 >>> 1.) the router has to tell the radio if it will reply with ACKs. If >>> the radio supports ACKs too, the radio can adapt its strategy >>> according to the information from the router. >>>=20 >>> 2.) the router MUST produce ACKs, but the radio can choose to >>> ignore them. >>=20 >> Or just implement the ACKs. That solves lots of problems. >=20 > This would be similar to option 2). Let the radio wait on ACK, or not, is very different. If router wants to send data to radio, the protocol gets more complex. I = lost the status on this, do we want to keep it? >=20 > But you are right, make ACK handling (on radio AND router) mandatory = would be a 3rd option. >=20 >> (or the vtime mechanism as alternative option, with pros and cons). >=20 > Yes. I still would prefer this solution, but it will be more work to = modify the draft in this way. The work is adjusting running and shipped code. The need for updating = the draft cannot be a reason to get it right. I guess we have enough = volunteers to help. Teco >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From henning.rogge@fkie.fraunhofer.de Wed Oct 10 06:07:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6137021F86D6 for ; Wed, 10 Oct 2012 06:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjJYMwIZJnUI for ; Wed, 10 Oct 2012 06:07:52 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25B21F86CA for ; Wed, 10 Oct 2012 06:07:52 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TLw0t-0002qp-PH; Wed, 10 Oct 2012 15:07:51 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TLw0t-0006xg-MZ; Wed, 10 Oct 2012 15:07:51 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Oct 2012 15:07:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Oct 2012 15:07:51 +0200 Message-ID: <50757322.4030306@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 15:07:46 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Teco Boot References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> <50756986.3070103@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060104090303020701070900" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 Oct 2012 13:07:51.0479 (UTC) FILETIME=[40E20470:01CDA6E8] X-Virus-Scanned: yes (ClamAV 0.97.5/15447/Wed Oct 10 03:10:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d11929bbb37d0bf82123645737fe3651 Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:07:53 -0000 --------------ms060104090303020701070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/10/2012 03:04 PM, Teco Boot wrote: > Let the radio wait on ACK, or not, is very different. I was talking about "router sends ACK" and radio process it or ignores it= =2E > If router wants to send data to radio, the protocol gets more complex. = I lost the status on this, do we want to keep it? Ahh sorry, you are right... had only thought about the "neighbor up/down" ACK, not about the Peer=20 Terminate ACK. (I think that are the only messages that have an ACK in the current DLEP = draft) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060104090303020701070900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTAxMzA3NDhaMCMGCSqGSIb3DQEJBDEWBBQS8l/td/yRcDtvCCjE4EA4p2azdjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAbGIoQAV4BzJ0n7LRiaBXChBQ7W5pRxLQR2a0zHWqESEz xD1wBXHQRNrBIMVQTGZe9+pyjk0Re9hZwAEAZmsRhwfONCl5rDsbI93bUEqk3tWmkPJQ/cG3 Uf98AcsiBNNXEWZy2K2UXaQIWR6JxVMNhECLbjvT8YF1+gPP3iBx2Xp7k5xiUI5lCiEOQRHX TYHMLKiCemnGPY9RaZHI3S8HTXlPaHy2pNDh6ZHrATIYItcAcXe7x0lRpFrLBjSjbYgKWuJT DoOVGS4fpAT/5A0oWgpPZoHXZpDKVsRr+Y3dW8PTNiZjJqi0EEhsTUkDifiGV/wuIsI72UxJ cK9sUUFOOgAAAAAAAA== --------------ms060104090303020701070900-- From boberry@cisco.com Wed Oct 10 06:19:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B3521F8581 for ; Wed, 10 Oct 2012 06:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE45mtRUQqJz for ; Wed, 10 Oct 2012 06:19:43 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0AA21F8540 for ; Wed, 10 Oct 2012 06:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1265; q=dns/txt; s=iport; t=1349875183; x=1351084783; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZrU5r0dziiJpi/JaRFcVqpXKudA0w4P4AYU0A7RMaVc=; b=d2v8TUgJuMV8GucYidE2e1eOOtfIVMhHMGstDjiYDnEECZHbC9TsBlZG HBCW9umAj1GtnaxpLp8Nlp1PgpXIIZ4yeRRWPOZcQdul1CLarZjtP/AdT Wq6XnmBoqcNrxjf5sQZ9em7lKXVQEIx0422mcAGWeOQN5q2xCWF8szFIq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHR0dVCtJV2Y/2dsb2JhbABEvyqBCIIgAQEBAwESAWYFCwsYJwdGEQYTIoddBpdboCCLRoVAYAOVa45FgWuDCQ X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="130138532" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 10 Oct 2012 13:19:43 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9ADJgTY019950; Wed, 10 Oct 2012 13:19:42 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <50757322.4030306@fkie.fraunhofer.de> Date: Wed, 10 Oct 2012 09:19:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22CA732E-8915-4A58-879C-3FFF487AADC7@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> <50756986.3070103@fkie.fraunhofer.de> <50757322.4030306 @fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:19:44 -0000 I suggest we define the ACKs. A radio implementation may choose to ignore an ack is a specific case. I'm OK with that. So let's rally around defining the ACKS. On Oct 10, 2012, at 9:07 AM, Henning Rogge wrote: > On 10/10/2012 03:04 PM, Teco Boot wrote: >> Let the radio wait on ACK, or not, is very different. >=20 > I was talking about "router sends ACK" and radio process it or ignores = it. >=20 >> If router wants to send data to radio, the protocol gets more = complex. I lost the status on this, do we want to keep it? >=20 > Ahh sorry, you are right... >=20 > had only thought about the "neighbor up/down" ACK, not about the Peer = Terminate ACK. >=20 > (I think that are the only messages that have an ACK in the current = DLEP draft) >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From Chris.Dearlove@baesystems.com Wed Oct 10 10:13:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E143B21F871C for ; Wed, 10 Oct 2012 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNmayZdOqYbc for ; Wed, 10 Oct 2012 10:13:21 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id DEC4D21F8712 for ; Wed, 10 Oct 2012 10:13:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,565,1344207600"; d="scan'208";a="277389932" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 10 Oct 2012 18:13:20 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9AHDJxg028862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Oct 2012 18:13:19 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Wed, 10 Oct 2012 18:13:19 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry , Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBful1k3LPMn4UWUVm1+BzE6hJendauAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgABLmlCAAaRhgIAAA3MAgAAyETD///DkgIAABVmAgAAAggCAABJr0P//8v2AgAAD2gCAAAHFAIAAESfA///wsQAAAIdVAAAALLQAAAAtv4AAABuRAAAAKNUAAADHrQAAAZgkgAAA+XKAAABzMAAAASE7gAAJ0pIAABCzcQAACsbzgAAAYSiAAAEXGQAAAEEfgAAAV8QAAAAW8wAAAVE2gAAAHVsAAABq/gAACjHYsA== Date: Wed, 10 Oct 2012 17:13:18 +0000 Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> <50756986.3070103@fkie.fraunhofer.de> <50757322.4030306 @fkie.fraunhofer.de> <22CA732E-8915-4A58-879C-3FFF487AADC7@cisco.com> In-Reply-To: <22CA732E-8915-4A58-879C-3FFF487AADC7@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 17:13:22 -0000 In the grandmother egg-sucking department, also what to do when ACKS don't = come - retries, number, any backoff, etc. Are there any state issues? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry Sent: 10 October 2012 14:20 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I suggest we define the ACKs. A radio implementation may choose to ignore an ack is a specific case. I'm OK with that. So let's rally around defining the ACKS. On Oct 10, 2012, at 9:07 AM, Henning Rogge wrote: > On 10/10/2012 03:04 PM, Teco Boot wrote: >> Let the radio wait on ACK, or not, is very different. >=20 > I was talking about "router sends ACK" and radio process it or ignores it= . >=20 >> If router wants to send data to radio, the protocol gets more complex. I= lost the status on this, do we want to keep it? >=20 > Ahh sorry, you are right... >=20 > had only thought about the "neighbor up/down" ACK, not about the Peer Ter= minate ACK. >=20 > (I think that are the only messages that have an ACK in the current DLEP = draft) >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we created= them.=20 Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From boberry@cisco.com Wed Oct 10 10:26:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9321F87CF for ; Wed, 10 Oct 2012 10:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2hix9gzTwaj for ; Wed, 10 Oct 2012 10:26:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DA4CB21F87A8 for ; Wed, 10 Oct 2012 10:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3585; q=dns/txt; s=iport; t=1349889988; x=1351099588; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sWCHHmxpCmwqvMUKmioQswZQrQvIyX/7mGF00SUUZ+s=; b=LTV/i7u2tlcOCwjFWEpMIDSPdZ1d+2/UuHNemwvTrzuRmRtnZueSfe9O ip6SaLD58BigHd3dMIGNy1+7Rcp5tUlsip57iimHVf3UfEB1KlpVq4z9s umV0SpQnHoRNCaH7zQHthl6IYsMeCze3VLx3+SXCnF8+vmO4v60ZvIYsw Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF2vdVCtJXG//2dsb2JhbABEvzGBCIIgAQEBAwEBAQEPAUIZAwgFBwQLEQQBAQEnBycfCQgGEyKHXAYLl0agIItHFA6FHmADlWyORYFrgwmBPgk X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="130263361" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 10 Oct 2012 17:26:27 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9AHQQoM013448; Wed, 10 Oct 2012 17:26:27 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: Date: Wed, 10 Oct 2012 13:26:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> <50756986.3070103@fkie.fraunhofer.de> <50757322.4030306 @fkie.fraunhofer.de> <22CA732E-8915-4A58-879C-3FFF487AADC7@cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1085) Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 17:26:28 -0000 On Oct 10, 2012, at 1:13 PM, Dearlove, Christopher (UK) wrote: > In the grandmother egg-sucking department, also what to do when ACKS = don't come - retries, number, any backoff, etc. Are there any state = issues? yes, these should be explained, defined >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Bo Berry > Sent: 10 October 2012 14:20 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I suggest we define the ACKs. A radio implementation may choose > to ignore an ack is a specific case. I'm OK with that. >=20 > So let's rally around defining the ACKS. >=20 >=20 > On Oct 10, 2012, at 9:07 AM, Henning Rogge wrote: >=20 >> On 10/10/2012 03:04 PM, Teco Boot wrote: >>> Let the radio wait on ACK, or not, is very different. >>=20 >> I was talking about "router sends ACK" and radio process it or = ignores it. >>=20 >>> If router wants to send data to radio, the protocol gets more = complex. I lost the status on this, do we want to keep it? >>=20 >> Ahh sorry, you are right... >>=20 >> had only thought about the "neighbor up/down" ACK, not about the Peer = Terminate ACK. >>=20 >> (I think that are the only messages that have an ACK in the current = DLEP draft) >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From prvs=06314f90c2=npowell@harris.com Wed Oct 10 17:32:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B371F041F for ; Wed, 10 Oct 2012 17:32:52 -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, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcTPFlPUFZi0 for ; Wed, 10 Oct 2012 17:32:51 -0700 (PDT) Received: from mlbefw1.harris.com (mlbefw1.ngenready.com [192.52.233.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA7C21F8440 for ; Wed, 10 Oct 2012 17:32:51 -0700 (PDT) From: "Powell III, Nelson" To: Bo Berry , Thomas Heide Clausen Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfxI3NnYC7q8k+nkZtOb2VpkZenf/vAgABxjoCAAgCEgIAAsLWAgAAxoACAA+2GAIAAcJkAgAA8ZICAAbOXgIAAA3MAgAAiiwCAAABqgIAABVmAgAAAgQCAAAI6AIAAAy6AgAAD2gCAAAHFAIAAAX4AgAAAWgCAAAQ7AIAAAWUAgAABboCAAADdAIAAAUcAgAAGPQCAAAzBgIAAB8yAgAADmQCAAAkKgIAATpUAgAFxjcA= Date: Thu, 11 Oct 2012 00:32:41 +0000 Message-ID: <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> In-Reply-To: <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:32:52 -0000 Bo, Sorry I'm a bit "late to the party" on this thread. I was thinking, if a= radio does not have the channel capacity to support the messaging to deter= mine RLQ to a distant station (e.g. narrowband waveforms that require serio= us optimization to push traffic), then a waveform design would automaticall= y assume the RLQ is 100% for all transmissions. Maybe that is a bit presum= ptuous on my part, but I would not want to assume less than 100% of a RLQ u= nless I could actually measure it. =20 Even if I could measure it, I would probably use discrete steps based on= the waveforms capabilities, such as auto-rating. Even for auto-rating, IMO= , it would make more sense to modify the Current Data Rate (CDR) rather tha= n issue a change to the RLQ. But my experience in the area is specific to = certain frequency ranges, so maybe there is some cellular industry advantag= e I'm missing with the RLQ. That being said, I'm not opposed to RLQ; but would I assume RLQ=3D100% i= f the value cannot be derived by the radio device. That would normalize an= y algorithm used to generate a routing protocol metric to the MDR and CDR. Nelson -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry Sent: Tuesday, October 09, 2012 6:18 PM To: Thomas Heide Clausen Cc: Dearlove, Christopher (UK); manet@ietf.org; Stan Ratliff (sratliff) Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 9, 2012, at 1:36 PM, Thomas Heide Clausen wrote: >=20 > On 9 oct. 2012, at 19:04, "Stan Ratliff (sratliff)" = wrote: >=20 >>=20 >> On Oct 9, 2012, at 12:51 PM, Thomas Heide Clausen wrote: >>=20 >>> Stan, >>>=20 >>> On 9 oct. 2012, at 18:23, "Stan Ratliff (sratliff)" wrote: >>>=20 >>>>=20 >>>> On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>>=20 >>>>> On 9 oct. 2012, at 17:15, "Duke, Martin" wro= te: >>>>>=20 >>>>>> Although I have never implemented a router that uses these metrics, = I suspect that I would want to treat RLQ=3D100 links as best for forwarding= , RLQ=3D0 links worst, and RLQ=3Dunknown as somewhere in between. >>>>>>=20 >>>>>=20 >>>>> I'm in somewhat of the same boat as you, experience-wise but my concl= usions would be somewhat different: >>>>>=20 >>>>> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>>>>=20 >>>>> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer to = "use a link with known characteristics, even if not with RLQ=3DMAXVALUE" ov= er using a link with entirely unknown characteristics. >>>>>=20 >>>>> At least, using a link with known characteristics could allow (for ex= ample) parametrizing the traffic to something guaranteed to "fit" over the = link..... >>>>>=20 >>>>> I do not know if that is a realistic usecase or not (I know that I've= deployed something where it made sense like that for L3 routing) >>>>>=20 >>>>=20 >>>> Well, having implemented a DLEP router that uses the metrics, I don't = understand what I'd do with an "Unknown" value... Just on a purely esoteric= level, Thomas has a point in that there's a difference between "I can't ca= lculate RLQ. Ever." and "I can calculate RLQ, but I don't know what it is y= et." To extend that definition slightly, from the router's perspective, lea= ds me to trying to deal (in general) with the notion of the radio telling t= he router: "I have a new neighbor! However, I don't have the foggiest notio= n as to what the link characteristics are to said neighbor. Have a nice day= !" Again, just from the perspective of the router, I'm tempted to want to = respond to that by effectively saying "Call me when you figure it out..." M= aybe I'm not seeing the forest for all of these trees...=20 >>>=20 >>> Thanks for taking time to answer to this, and for taking it in the inqu= isitive spirit my mail was meant. I insist, I am no expert in this domain o= f DLEP and I do not know if it is realistic. >>>=20 >>> What you are saying is, that proper behavior is "don't say anything abo= ut a neighbor until you have an useful RQL to report"? If so, then your arg= ument is probably right (could, then, that be specified behavior?) >>=20 >> Yes, that's what I'm advocating for.=20 This sounds like a radio requirement. I do not think having a RLQ should be= a prerequisite for a neighbor. The radio should be able to report neighbo= r status by excluding the TLV. For example, if I build one radio that cons= tantly sends (hard codes) RLQ=3D100 and another radio that dynamically comp= utes-reports RLQ and another radio that never sends RLQ (and the spectrums = are compatible), DLEP should handle all. Another metric, resources, is also a percentage (0-100). What if a radio h= as no means to compute resources? The radio should be able to exclude this= TLV also, or simply report 100. Again if I build a simple radio and hard = code resources to 100, its compliant.=20 Suggest these tlvs be optional or let the radio send 100. I'm OK with an u= nknown value (255).=20 The router obviously will need to handle the diff cases. >>=20 >=20 > Great. If documented thus, I am happy with that outcome. >=20 > Thomas >=20 >> Regards, >> Stan >>=20 >>>=20 >>> Thomas >>>=20 >>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>> Thomas >>>>>=20 >>>>>> Martin >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>>>>> Sent: Tuesday, October 09, 2012 8:11 AM >>>>>> To: Duke, Martin >>>>>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; Bo Be= rry (boberry) >>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>=20 >>>>>>=20 >>>>>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>>>>=20 >>>>>>> RLQ calculation is so loosely defined that it's hard to precisely d= escribe how this kind of thing might happen. Latency is a bit easier. But i= n either case, I can imagine a situation where a radio is RLQ/Latency capab= le, but it hasn't heard from a neighbor in a while, at least in a way where= it can make any sort of reasonable estimate of either quantity. In this ca= se, it should report to the router a transition from an RLQ of "foo" to an = RLQ of "unknown". Therefore, we need an unknown code point. >>>>>>=20 >>>>>> I'm having a hard time with the notion of a Link Quality that is "un= known". Seems like a radio would report a quality of "0" (worst case) in th= at event.=20 >>>>>>=20 >>>>>> Stan >>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>>>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>>>>> To: Duke, Martin >>>>>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry (boberry);= Stan Ratliff (sratliff) >>>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>>=20 >>>>>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin wrote: >>>>>>>> The only concern with reporting an unknown value by simply not inc= luding the TLV is if the link state transitions from a known value to an un= known value. I'm not sure how often this would happen, but it seems easy en= ough to reserve 255 (or whatever) as an 'unknown' code point. >>>>>>>=20 >>>>>>> If a radio supports RLQ it should ALWAYS include the TLV... if it d= oes not, it should NEVER include it. >>>>>>> (maybe this should be a MUST in the final RFC) >>>>>>>=20 >>>>>>> So the transition should not happen at all. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them.=20 Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Wed Oct 10 17:42:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5972811E80DC for ; Wed, 10 Oct 2012 17:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.872 X-Spam-Level: X-Spam-Status: No, score=-9.872 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51gCXaUu1sX1 for ; Wed, 10 Oct 2012 17:42:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0F90611E808D for ; Wed, 10 Oct 2012 17:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8640; q=dns/txt; s=iport; t=1349916129; x=1351125729; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gZS1rmCBl+SFfRjccI1d73hAt5X3b4wg8dHl0z3QPy8=; b=j0AaG5VRDw8kmQzrPypJdrHrS1BeED/uFPT1WpxhHObU9GG7bmHhM9uC bHjxiuOBjMVszdGTnyr8J8dtSh46/HN/UQU3DmYWDUmO6v9tUXFKEm072 SBd6EWHK5dUPG8m42pN8PAbYcUis5qaI+1so9eNbx5QcuTXe95OznT05q 0=; X-IronPort-AV: E=Sophos;i="4.80,567,1344211200"; d="scan'208";a="130380905" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2012 00:42:08 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-79.cisco.com [10.81.230.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9B0g7hw031644; Thu, 11 Oct 2012 00:42:07 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> Date: Wed, 10 Oct 2012 20:42:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <461D1D66-EB20-449A-B53F-9A1378DC451F@cisco.com> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <50740805.3020603@fkie.fraunhofer.de> <87E75735-A1CC-4407-9EC6-80C80A9BF61F@thomasclausen.org> <1D01707E-D076-4AEB-A599-F8192A76CDDA@thomasclausen.org> <854690FB-19C9-455F-80A9-2462640D38E4@cisco.com> <010A2FC5-D34F-4D2C-A615-E60FE162B178@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400364@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B 015123FB6385C@ROCMXUS20.cs.myharris.net> To: "Powell III, Nelson" X-Mailer: Apple Mail (2.1085) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:42:10 -0000 Hi Nelson Thanks for the insights. =20 -Bo On Oct 10, 2012, at 8:32 PM, Powell III, Nelson wrote: > Bo, > Sorry I'm a bit "late to the party" on this thread. I was thinking, = if a radio does not have the channel capacity to support the messaging = to determine RLQ to a distant station (e.g. narrowband waveforms that = require serious optimization to push traffic), then a waveform design = would automatically assume the RLQ is 100% for all transmissions. Maybe = that is a bit presumptuous on my part, but I would not want to assume = less than 100% of a RLQ unless I could actually measure it. =20 > Even if I could measure it, I would probably use discrete steps = based on the waveforms capabilities, such as auto-rating. Even for = auto-rating, IMO, it would make more sense to modify the Current Data = Rate (CDR) rather than issue a change to the RLQ. But my experience in = the area is specific to certain frequency ranges, so maybe there is some = cellular industry advantage I'm missing with the RLQ. > That being said, I'm not opposed to RLQ; but would I assume RLQ=3D100%= if the value cannot be derived by the radio device. That would = normalize any algorithm used to generate a routing protocol metric to = the MDR and CDR. >=20 > Nelson >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Bo Berry > Sent: Tuesday, October 09, 2012 6:18 PM > To: Thomas Heide Clausen > Cc: Dearlove, Christopher (UK); manet@ietf.org; Stan Ratliff = (sratliff) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 >=20 > On Oct 9, 2012, at 1:36 PM, Thomas Heide Clausen wrote: >=20 >>=20 >> On 9 oct. 2012, at 19:04, "Stan Ratliff (sratliff)" = wrote: >>=20 >>>=20 >>> On Oct 9, 2012, at 12:51 PM, Thomas Heide Clausen wrote: >>>=20 >>>> Stan, >>>>=20 >>>> On 9 oct. 2012, at 18:23, "Stan Ratliff (sratliff)" = wrote: >>>>=20 >>>>>=20 >>>>> On Oct 9, 2012, at 11:38 AM, Thomas Heide Clausen wrote: >>>>>=20 >>>>>>=20 >>>>>> On 9 oct. 2012, at 17:15, "Duke, Martin" = wrote: >>>>>>=20 >>>>>>> Although I have never implemented a router that uses these = metrics, I suspect that I would want to treat RLQ=3D100 links as best = for forwarding, RLQ=3D0 links worst, and RLQ=3Dunknown as somewhere in = between. >>>>>>>=20 >>>>>>=20 >>>>>> I'm in somewhat of the same boat as you, experience-wise but my = conclusions would be somewhat different: >>>>>>=20 >>>>>> RLQ=3DMAXVALUE would be best, RLQ=3D0 worst. >>>>>>=20 >>>>>> RLQ=3DUNKNOWN, I might imagine that one could envision to prefer = to "use a link with known characteristics, even if not with = RLQ=3DMAXVALUE" over using a link with entirely unknown characteristics. >>>>>>=20 >>>>>> At least, using a link with known characteristics could allow = (for example) parametrizing the traffic to something guaranteed to "fit" = over the link..... >>>>>>=20 >>>>>> I do not know if that is a realistic usecase or not (I know that = I've deployed something where it made sense like that for L3 routing) >>>>>>=20 >>>>>=20 >>>>> Well, having implemented a DLEP router that uses the metrics, I = don't understand what I'd do with an "Unknown" value... Just on a purely = esoteric level, Thomas has a point in that there's a difference between = "I can't calculate RLQ. Ever." and "I can calculate RLQ, but I don't = know what it is yet." To extend that definition slightly, from the = router's perspective, leads me to trying to deal (in general) with the = notion of the radio telling the router: "I have a new neighbor! However, = I don't have the foggiest notion as to what the link characteristics are = to said neighbor. Have a nice day!" Again, just from the perspective of = the router, I'm tempted to want to respond to that by effectively saying = "Call me when you figure it out..." Maybe I'm not seeing the forest for = all of these trees...=20 >>>>=20 >>>> Thanks for taking time to answer to this, and for taking it in the = inquisitive spirit my mail was meant. I insist, I am no expert in this = domain of DLEP and I do not know if it is realistic. >>>>=20 >>>> What you are saying is, that proper behavior is "don't say anything = about a neighbor until you have an useful RQL to report"? If so, then = your argument is probably right (could, then, that be specified = behavior?) >>>=20 >>> Yes, that's what I'm advocating for.=20 >=20 > This sounds like a radio requirement. I do not think having a RLQ = should be a prerequisite for a neighbor. The radio should be able to = report neighbor status by excluding the TLV. For example, if I build = one radio that constantly sends (hard codes) RLQ=3D100 and another radio = that dynamically computes-reports RLQ and another radio that never sends = RLQ (and the spectrums are compatible), DLEP should handle all. >=20 > Another metric, resources, is also a percentage (0-100). What if a = radio has no means to compute resources? The radio should be able to = exclude this TLV also, or simply report 100. Again if I build a simple = radio and hard code resources to 100, its compliant.=20 >=20 > Suggest these tlvs be optional or let the radio send 100. I'm OK with = an unknown value (255).=20 >=20 > The router obviously will need to handle the diff cases. >=20 >>>=20 >>=20 >> Great. If documented thus, I am happy with that outcome. >>=20 >> Thomas >>=20 >>> Regards, >>> Stan >>>=20 >>>>=20 >>>> Thomas >>>>=20 >>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>>> Martin >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>>>>>> Sent: Tuesday, October 09, 2012 8:11 AM >>>>>>> To: Duke, Martin >>>>>>> Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org; = Bo Berry (boberry) >>>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Oct 9, 2012, at 11:08 AM, Duke, Martin wrote: >>>>>>>=20 >>>>>>>> RLQ calculation is so loosely defined that it's hard to = precisely describe how this kind of thing might happen. Latency is a bit = easier. But in either case, I can imagine a situation where a radio is = RLQ/Latency capable, but it hasn't heard from a neighbor in a while, at = least in a way where it can make any sort of reasonable estimate of = either quantity. In this case, it should report to the router a = transition from an RLQ of "foo" to an RLQ of "unknown". Therefore, we = need an unknown code point. >>>>>>>=20 >>>>>>> I'm having a hard time with the notion of a Link Quality that is = "unknown". Seems like a radio would report a quality of "0" (worst case) = in that event.=20 >>>>>>>=20 >>>>>>> Stan >>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Henning Rogge [mailto:hrogge@googlemail.com]=20 >>>>>>>> Sent: Tuesday, October 09, 2012 8:03 AM >>>>>>>> To: Duke, Martin >>>>>>>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry = (boberry); Stan Ratliff (sratliff) >>>>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>>>=20 >>>>>>>> On Tue, Oct 9, 2012 at 4:58 PM, Duke, Martin = wrote: >>>>>>>>> The only concern with reporting an unknown value by simply not = including the TLV is if the link state transitions from a known value to = an unknown value. I'm not sure how often this would happen, but it seems = easy enough to reserve 255 (or whatever) as an 'unknown' code point. >>>>>>>>=20 >>>>>>>> If a radio supports RLQ it should ALWAYS include the TLV... if = it does not, it should NEVER include it. >>>>>>>> (maybe this should be a MUST in the final RFC) >>>>>>>>=20 >>>>>>>> So the transition should not happen at all. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From prvs=06314f90c2=npowell@harris.com Wed Oct 10 17:42:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F51A11E80E4 for ; Wed, 10 Oct 2012 17:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l+s2b96EVZL for ; Wed, 10 Oct 2012 17:42:24 -0700 (PDT) Received: from mlbefw2.harris.com (mlbefw2.ngenready.com [192.52.233.80]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE611E80E3 for ; Wed, 10 Oct 2012 17:42:24 -0700 (PDT) From: "Powell III, Nelson" To: Thomas Clausen , Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfxI3NnYC7q8k+nkZtOb2VpkZenf/vAgABxjoCAAgCEgIAAsLWAgAAxoACAA+2GAIAAcJkAgACYe4CAAVjVgIAABxcAgAAGf4CAAAXWAIAAB0CAgABtjACAALfsgIAAETSAgAAaPQCAAMJ1MA== Date: Thu, 11 Oct 2012 00:42:21 +0000 Message-ID: <13044204616BFB43BC7F6B4EC6B015123FB6388A@ROCMXUS20.cs.myharris.net> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> In-Reply-To: <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:42:25 -0000 Thomas, I agree, I prefer the use of MUST in the case of heartbeats and ACKs. A= s a radio designer, if I decide to make the radio block on an ACK, that's m= y bad for not recognizing the possibility of a lost response. The use of h= eartbeats and message timers allow for retries without the use of TCP. Nelson -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= homas Clausen Sent: Wednesday, October 10, 2012 5:05 AM To: Teco Boot Cc: manet@ietf.org; Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 10, 2012, at 9:30 AM, Teco Boot wrote: > Some thoughts on how we may get out of some issues. If we use RFC 2119=20 > SHOULD language for what is needed for a standard, we can accept=20 > modified implementations. >=20 > So we can say: > o And DLEP implementations SHOULD use UDP o And DLEP=20 > implementations SHOULD use heartbeats o And DLEP implementations=20 > SHOULD use ACK etc. >=20 Uhh, I am no great fan of SHOULD - it seems a cop-out, unless it is well ar= gued under which circumstances and with which consequences one can deviate = from the SHOULD. Generally, most SHOULD SHOULD be MUST - or so I've heard the saying go ;)=20 > If we think TCP is overkill (I can accept that), we can specify each=20 > single packet (or message) SHOULD be ACKked. This provides reliability=20 > and eliminates any congestion. Not if it is a SHOULD; it may increase congestion (if someone does not ACK,= for example, with an aggressive retransmission schedule). My preference is a much much tighter specification than generous use of SHO= ULD. Thomas > Bulk transfer is slowed > down, but with sending updates only, this should not be a problem. > Startup message transfer would take a little bit longer, but might be=20 > faster than TCP in many cases. > An alternative for congestion avoidance would be rate limiting. This=20 > needs a parameter. Not my preference. >=20 > Teco >=20 >=20 > Op 10 okt. 2012, om 08:29 heeft Henning Rogge het volgende geschreven: >=20 >> On 10/09/2012 09:30 PM, Bo Berry wrote: >>> Teco >>> I reviewed >>> Request for Comments: 5405 >>> BCP: 145, Unicast UDP Usage Guidelines for Application Designers >>>=20 >>> DLEP is only control plane traffic between the router and its=20 >>> connected radio. The draft should allow for driver implementations=20 >>> (pci SDRs for example) as well as ethernet protocols: UDP, SCTP,=20 >>> TLS. So abstracting DLEP from the transport is good. >>=20 >> If we allow this (especially the pci part), we cannot use the IP/port tu= ple as a router/radio identification. >>=20 >> I see the reason for this (and one of the suggestions of the original DL= EP proposal was to make it transport independent). >>=20 >> Can we maybe handle this with an OPTIONAL identification TLV of (at leas= t) six bytes for both router and radio? The standard could define that in t= he absence of this tuples and the usage of IP/UDP, the IP/Port combination = MUST be used as an id. >>=20 >> The problem is that with IPv6 we will have 18-bytes tuples for radio and= for router (for a total of 36 bytes). Either we have to specify that this = is a valid ID or we might break some router/radio implementations because t= hey expect only 4 or 6 bytes. >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20 >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From prvs=06314f90c2=npowell@harris.com Wed Oct 10 17:44:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042CA1F040A for ; Wed, 10 Oct 2012 17:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opXiSwiU-wae for ; Wed, 10 Oct 2012 17:44:15 -0700 (PDT) Received: from mlbefw1.harris.com (mlbefw1.ngenready.com [192.52.233.75]) by ietfa.amsl.com (Postfix) with ESMTP id E2D9E21F860B for ; Wed, 10 Oct 2012 17:44:10 -0700 (PDT) From: "Powell III, Nelson" To: Henning Rogge , Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfxI3NnYC7q8k+nkZtOb2VpkZenf/vAgABxjoCAAgCEgIAAsLWAgAAxoACAA+2GAIAAcJkAgACYe4CAAVjVgIAABxcAgAAGf4CAAAXWAIAAB0CAgABtjACAALfsgIAAETSAgAAN5ACAAAvGgIAAAZGAgADCL2A= Date: Thu, 11 Oct 2012 00:44:08 +0000 Message-ID: <13044204616BFB43BC7F6B4EC6B015123FB638A3@ROCMXUS20.cs.myharris.net> References: <13044204616BFB43BC7F6B4EC6B015123FB5D39C@ROCMXUS20.cs.myharris.net> <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <50752FC6.5050901@fkie.fraunhofer.de> <19000B20-1B1F-43B3-8EEB-C6C3BBA44DC3@inf-net.nl > <50753AF7.10401@fkie.fraunhofer.de> In-Reply-To: <50753AF7.10401@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:44:16 -0000 I know the idea of the FSM is not popular, but if we have some event/transi= tion strategy or FSM that drives the client and one for the server, err... = radio and router, then we would be able to include session recovery. -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: Wednesday, October 10, 2012 5:08 AM To: Teco Boot Cc: manet@ietf.org; Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 Am 10.10.2012 11:02, schrieb Teco Boot: > > Op 10 okt. 2012, om 10:20 heeft Henning Rogge het volgende geschreven: > >> Am 10.10.2012 09:30, schrieb Teco Boot: >>> Some thoughts on how we may get out of some issues. If we use RFC=20 >>> 2119 SHOULD language for what is needed for a standard, we can=20 >>> accept modified implementations. >>> >>> So we can say: >>> o And DLEP implementations SHOULD use UDP >>> o And DLEP implementations SHOULD use heartbeats >>> o And DLEP implementations SHOULD use ACK >> >> If ACK stays optional, we have to make sure this will not lead to starva= tion. > It is not "we have to make sure". > The implementer of the protocol that does not implement the SHOULD=20 > must take care if this. This doesn't work if its not well specified how the protocol will handle th= is case. > > >> >> What happens if we have a Radio that supports ACKs (and expects them) bu= t the Router does NOT? > The router vendor MUST solve this problem. We are done. The router vendor CAN NOT solve this problem, because the protocol does not= specify how the radio will react. >> Wouldn't the Radio wait for ACKs that will never arrive and maybe even t= erminate the session because of this? > I don't care. I will not buy such a router. If the protocol does not describe how interaction will work between an impl= ementation supporting an optional feature and one NOT supporting it, the fe= ature should not be optional. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation= , Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) F= raunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From henning.rogge@fkie.fraunhofer.de Thu Oct 11 00:29:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0152221F85A2 for ; Thu, 11 Oct 2012 00:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLl5UTyKFvMg for ; Thu, 11 Oct 2012 00:29:29 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 096D321F8585 for ; Thu, 11 Oct 2012 00:29:28 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMDCu-00085i-Kx; Thu, 11 Oct 2012 09:29:24 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMDCu-0003wQ-IH; Thu, 11 Oct 2012 09:29:24 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 09:29:24 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 09:29:24 +0200 Message-ID: <5076754D.7020904@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 09:29:17 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <507512BA.2000908@fkie.fraunhofer.de> <8D8EA6EF-8A64-4880-9C6B-2D565C359492@cisco.com> <50755D99.6040208@fkie.fraunhofer.de> <5E9B1C84-17D0-45D5-AF02-75E8E1FB208B@cisco.com> <5075669F.90706@fkie.fraunhofer.de> <4D99F6B0-12DD-4207-815F-90128835FF82@inf-net.nl> <50756986.3070103@fkie.fraunhofer.de> <50757322.4030306 @fkie.fraunhofer.de> <22CA732E-8915-4A58-879C-3FFF487AADC7@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010506060607020701030504" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 07:29:24.0351 (UTC) FILETIME=[234DF0F0:01CDA782] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 43fe4b22ce746091c894ec5715882e1d Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 07:29:30 -0000 --------------ms010506060607020701030504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/10/2012 07:26 PM, Bo Berry wrote: > > On Oct 10, 2012, at 1:13 PM, Dearlove, Christopher (UK) wrote: > >> In the grandmother egg-sucking department, also what to do when ACKS d= on't come - retries, number, any backoff, etc. Are there any state issues= ? > > yes, these should be explained, defined Even if we do not specify the retries/backoff-mechanism (they could be=20 "implementation specific" variants), we must specify what happens if=20 this mechanisms fail. Even if its just a "drop connection, start from scratch". Otherwise the=20 protocol is not in a defined state anymore. I think we need at least something like this: 1) transport data to other side 2) if you succeed, go to step "okay" 3) "something happens here to compensate the loss" 4) if you succeed, go to step "okay" 5) go to step "fail" We have defined step 1) and 2)... and I think we must also (at least)=20 define step 4) and 5) in the specification. Of course giving a good example how to handle a packet loss and state=20 that every modification of the example must END in the same states (but=20 not necessarily by doing the same steps) might be even better. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010506060607020701030504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTEwNzI5MjJaMCMGCSqGSIb3DQEJBDEWBBSeuQ3vgqS3PLacwptJYDEPliAw0zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAuCUbotexjXYj1vaEWfbEuBRZ859G2dQiVB9lnjf7M//c 8zNRA96PN/KfQpifAdQ5ONmeC0oRX9WemZPwN3QzJsUm9XJvsERKddyU03Pa21X2T2Gyj1sw 1phtk1Vp3oD080YUeYIZrsc5dQXoMgmq+HNfRP3j3jEPb/foqc/X3/TNssXUd271bIGkh1EG WHmwB0aJXHyAX4pkgFBedDyht42ZVmsv+apa0HdUKwMV8Mm0mufC4yzZejTrz58vUri/7LC+ JYh6GoV8v/1xRlyVG4V5wWP1hMh+FvVOuMDQZf0ZkljmJlsS9jiJlwfPzTcBlLyXCTieRqN+ 9lvgbD5uSwAAAAAAAA== --------------ms010506060607020701030504-- From henning.rogge@fkie.fraunhofer.de Thu Oct 11 00:34:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5775921F85F4 for ; Thu, 11 Oct 2012 00:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP5PXSBRGLYR for ; Thu, 11 Oct 2012 00:34:36 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id F416421F8585 for ; Thu, 11 Oct 2012 00:34:35 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMDHv-0001Lw-Av for manet@ietf.org; Thu, 11 Oct 2012 09:34:35 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMDHv-00044c-8H for manet@ietf.org; Thu, 11 Oct 2012 09:34:35 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 09:34:35 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 09:34:34 +0200 Message-ID: <50767689.6040202@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 09:34:33 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> In-Reply-To: <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090509070908090308020600" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 07:34:35.0040 (UTC) FILETIME=[DC7D5200:01CDA782] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2d58c557eff95fe6d1f20ba5c7a78ca3 Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 07:34:37 -0000 --------------ms090509070908090308020600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 02:32 AM, Powell III, Nelson wrote: > Bo, Sorry I'm a bit "late to the party" on this thread. I was > thinking, if a radio does not have the channel capacity to support > the messaging to determine RLQ to a distant station (e.g. narrowband > waveforms that require serious optimization to push traffic), then a > waveform design would automatically assume the RLQ is 100% for all > transmissions. Maybe that is a bit presumptuous on my part, but I > would not want to assume less than 100% of a RLQ unless I could > actually measure it. Even if I could measure it, I would probably use > discrete steps based on the waveforms capabilities, such as > auto-rating. Even for auto-rating, IMO, it would make more sense to > modify the Current Data Rate (CDR) rather than issue a change to the > RLQ. But my experience in the area is specific to certain frequency > ranges, so maybe there is some cellular industry advantage I'm > missing with the RLQ. That being said, I'm not opposed to RLQ; but > would I assume RLQ=3D100% if the value cannot be derived by the radio > device. That would normalize any algorithm used to generate a > routing protocol metric to the MDR and CDR. The main issue I have with this is that we are moving a decision on=20 "network level" (how to handle bad/unknown links) to the radio. The router can easily implement a configuration setting like "how to=20 handle no RLQ/unknown RLQ" with options like "drop this links",=20 "consider link perfect" or even "consider link as user-defined value X". The "unknown =3D perfect" assumes that RLQ will be 100 for a "typical=20 radio link", which might not be the case on some radios. In which case=20 the DLEP specification would make the network to consider=20 "non-measurable/unknown" links better than the typical ones. I think we can do anything with the "special codepoint for unknown, no=20 TLV for non-supported" RLQ TLV than we can do with the current=20 specification. And we can sidestep some potential pit traps with it. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090509070908090308020600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTEwNzM0MzNaMCMGCSqGSIb3DQEJBDEWBBQeN6vNDpoMBId1d4QfEV3lAI/LzjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAsKpF6byALdEHVfeeoLrLnynx9T99QXVSDmJTHPsyzdrp 6mbaTM33ZVySY2WyHhEo6qd+QrB4gc9iSeTHhismuSy32pyeScuTtXZMm3fL0AGNm9T7uxYU JvJDmaO9hHDO0vG4u20ayRZL3LJ9rC7H+kTtRB9V2QS1Lg7Ra6oVIeGCwKl5dHoZAXogzyXL zSS5lyT/FjetyJtdSvSdinS+LhVps9I/QnXbJiKJL46lTYdTZxXEy0x1UjrqQtIkHeK5V+U5 N9A4nrFpJh+mJ8Sdav4FiCrzMr10qD5NIT5GBMt5YtIa0niLr4hhqxgW9+XjJ8CnO4YtO2HJ o5oxLJ3TQAAAAAAAAA== --------------ms090509070908090308020600-- From henning.rogge@fkie.fraunhofer.de Thu Oct 11 01:08:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF421F84CE for ; Thu, 11 Oct 2012 01:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwJ3K+cXBYAW for ; Thu, 11 Oct 2012 01:08:29 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7E71521F84AE for ; Thu, 11 Oct 2012 01:08:29 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMDoi-0004cT-Mb for manet@ietf.org; Thu, 11 Oct 2012 10:08:28 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMDoi-0004zn-Jz for manet@ietf.org; Thu, 11 Oct 2012 10:08:28 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 10:08:28 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 10:08:28 +0200 Message-ID: <50767E77.5090801@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 10:08:23 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: References: <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> <13044204616BFB43BC7F6B4EC6B015123FB6388A@ROCMXUS20.cs.myharris.net> In-Reply-To: <13044204616BFB43BC7F6B4EC6B015123FB6388A@ROCMXUS20.cs.myharris.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060908010107020601040201" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 08:08:28.0413 (UTC) FILETIME=[98796AD0:01CDA787] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 306d475cb774b7f15678e7079d6bc338 Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 08:08:30 -0000 --------------ms060908010107020601040201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 02:42 AM, Powell III, Nelson wrote: > Thomas, I agree, I prefer the use of MUST in the case of heartbeats > and ACKs. As a radio designer, if I decide to make the radio block > on an ACK, that's my bad for not recognizing the possibility of a > lost response. The use of heartbeats and message timers allow for > retries without the use of TCP. The current packet format of DLEP does not contain a sequence number.=20 You cannot send a second packet before you received a successful ACK.=20 You can just try to send the packet again or drop the connection. But maybe you see yourself that the DLEP transport mechanism will get=20 quite complex if we want to avoid all that problems. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060908010107020601040201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTEwODA4MjZaMCMGCSqGSIb3DQEJBDEWBBRgAwP2A2z/aqUx7YM5lMYWcH+H1DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAREO2e+LCUhGXK82PNAL7XVZ0tRZXazwPT4npe1PZ3vHg yY0FdC+oInxETZ3LlcJpC/ERbXfyteLZvr6ixYBXxj+UCcC3f9qfC8ukle1YJUmTroqE5q7A hymfL51GQHSxpden46BOaTsMQUWKPLCyJ3DB1fU0E4W3HM8EOJ/97KHLJZIFw6oYNabu5Ag3 Hlfb/XieH3Cn7jOqBe/bMRqrQte0vGp4X+QdkAkBR+cYMOjm6F70Jm+OWIgASj6H1ewtYHWM uEDsYX7Gmg/CmaupsmimpMvk6bDCtDdSSwdDDowhVLlDWIGE4DR/Wh8Aj8/TRS0lJ7dw1C4H CBZmYdb98gAAAAAAAA== --------------ms060908010107020601040201-- From henning.rogge@fkie.fraunhofer.de Thu Oct 11 01:10:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C4521F8686 for ; Thu, 11 Oct 2012 01:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfJCVbU4OT-k for ; Thu, 11 Oct 2012 01:10:22 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 4388121F84CE for ; Thu, 11 Oct 2012 01:10:04 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMDqE-0004f0-Pl; Thu, 11 Oct 2012 10:10:02 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMDqE-00050U-N3; Thu, 11 Oct 2012 10:10:02 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 10:10:02 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 10:10:02 +0200 Message-ID: <50767ED9.9070806@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 10:10:01 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: "Powell III, Nelson" References: <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <50752FC6.5050901@fkie.fraunhofer.de> <19000B20-1B1F-43B3-8EEB-C6C3BBA44DC3@inf-net.nl > <50753AF7.10401@fkie.fraunhofer.de> <13044204616BFB43BC7F6B4EC6B015123FB638A3@ROCMXUS20.cs.myharris.net> In-Reply-To: <13044204616BFB43BC7F6B4EC6B015123FB638A3@ROCMXUS20.cs.myharris.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060704010801090000020307" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 08:10:02.0492 (UTC) FILETIME=[D08CBBC0:01CDA787] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2f486c1bd65b83532f5a9ca975ef026a Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 08:10:23 -0000 --------------ms060704010801090000020307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 02:44 AM, Powell III, Nelson wrote: > I know the idea of the FSM is not popular, but if we have some > event/transition strategy or FSM that drives the client and one for > the server, err... radio and router, then we would be able to include > session recovery. But for this we will need a well-specified FSM. Otherwise the "recovery=20 strategies" of one side might not fit to the receiver on the other side. Even if a part of the strategy can be "implementation detail", the final = states must be well defined. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060704010801090000020307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTEwODEwMDFaMCMGCSqGSIb3DQEJBDEWBBTB0OJl6QMOJ4SKSX2P8aFzEjlGhjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAYjlWbYZ6V1Ukx0ciPX4PVW8W46LnGK6+KMkkoVKn2q6V kiFygiM7aFRO6boe46h2xKgwr8v0KRHcEWe/Wnn8hHCJ6SRDrmq8MRP69nPp0zsweNXvRPt0 c9MEX1dEotKXRux9XStc4EsB3RUcf5msZCuspGPk00VZSirciAk+LIxeqvw3x+GYh7hn94dH S1x14iUPSPA3XCbfh4DBAaPz88XrTrLOy26+ZJ65IQJpQcK3vO1Z8m4MrbQeahesg7u39XDi 76pp6jTLuqcCfqe+DfjntYYIvTz5PiOZ0VvmhIH0NFtH+J821ribCy2ON6SKQtAO2QZiH5qQ Dm0vMPGp3AAAAAAAAA== --------------ms060704010801090000020307-- From abdussalambaryun@gmail.com Thu Oct 11 02:18:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DA821F8672 for ; Thu, 11 Oct 2012 02:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhpx6JrVp0o2 for ; Thu, 11 Oct 2012 02:18:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCEF21F8666 for ; Thu, 11 Oct 2012 02:18:07 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2115046vcb.31 for ; Thu, 11 Oct 2012 02:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=wTfy8aQk1oBJo6SnkPLwBjVYYTmGsksfaPO43hEkTjI=; b=TyTsammF6Pb+AkbJNeU2t00xOg8oWwk3S06h3v9eO2KjAVgarj0Hglw2p78reKsATK 0u0XnWgnka43sYMyDJ2rPG8aauCVVYKHmz6JBn2SMSRc3Hf4IqzCl1iLQexnKvevRshx Xo3Vnou5C/d6o3tc67vuKH/gwbfz7ZLA86wQoBysHMRxrKpXLZ2wutsbZXsHkr+CgRDi P2myIicsSkMRm8Ecvk3AJzePHAbLPLlOBPQErf31i6ZTbJ/scYcrMJcU8wfAslvf9tRB mKlHrJyfbOtezZuj2V8Cd6SjJCjjBJ5A8t0XElMz9dIbXwYdRopw+CqqcCk/mMr+FEv8 Xzdw== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr113972vdw.25.1349947087110; Thu, 11 Oct 2012 02:18:07 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 11 Oct 2012 02:18:07 -0700 (PDT) Date: Thu, 11 Oct 2012 11:18:07 +0200 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03/RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:18:08 -0000 > Any other comments, perspectives from the WG? I really don't think we're at rough consensus. I think we are in discussion, so I hope we can argue why RFC5444 or why not in more details. There are advantages in using RFC5444. My position is that we postpone collecting consensus until we solve the dlep issues, without closing its discussion by the WG. It may be reasonable to consider RFC5444 in future. IMHO, for now I don't think we can use TLVs in the current draft update, because we are updating dlep not routings. AB On 10/9/12, Bo Berry wrote: > Christopher > I'm getting the impression that we're at rough consensus, if not very > close. > > Any other comments, perspectives from the WG? > > -Bo > > On Oct 9, 2012, at 10:04 AM, Dearlove, Christopher (UK) wrote: > >> Actually, I haven't caught up properly yet, so I can't judge if the things >> being discussed are converging successfully or still have major issues. (I >> can make guesses, but they aren't well-enough informed.) >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Thomas Clausen [mailto:ietf@thomasclausen.org] >> Sent: 09 October 2012 14:57 >> To: Bo Berry >> Cc: Dearlove, Christopher (UK); manet@ietf.org >> Subject: Re: [manet] Some comments on manet-dlep-03 >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Bo, >> >> I think that neither of Chris nor I suggested that it should (or should >> not) be opened. >> >> I think that we, generally, agreed that there were other, more important, >> thing to get right before considering if it should (or should not) be >> opened. >> >> Thomas >> >> >> On Oct 9, 2012, at 3:55 PM, Bo Berry wrote: >> >>> Thomas, Christopher >>> I understand your perspectives towards using 5444. >>> >>> DLEP is not a manet routing protocol and is thus not required to use >>> 5444. We have tried to resolve the issues on this list which lead >>> us to using standard TLVs. This is simplier, more efficient than >>> the 5444 encoding. >>> >>> So I do not agree that we need to re-open this discussion. >>> >>> Thanks >>> -Bo From abdussalambaryun@gmail.com Thu Oct 11 02:30:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE51121F8661 for ; Thu, 11 Oct 2012 02:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIRSoa3Uylqj for ; Thu, 11 Oct 2012 02:30:06 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05DD121F8645 for ; Thu, 11 Oct 2012 02:30:05 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2128702vcb.31 for ; Thu, 11 Oct 2012 02:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZrKS7/5iwbQTHz0X664bGpDroLvwBysLRD189vCvH+E=; b=ff4qjN4vqyB80vMkSbyTJG6ofUuL21mPImmm1wGrtIEWzsF+Xdx0n94T7JuaKfaVWV gG2yqnGK7RXtZY8WtaGr7rEfypJK7QVnKt1/v4mXEYMKkYuTwezSA4Q4eWLvH14k2u0R U3SX4o+UVnVLH7o638MDegF+Ld1lS8ZJDPimj0Xh1LD8SVzmMIUtKIRBdrt4j0oSNYGO TussPvfASQLe9yLrJS6JvXcXvcTQhGy0nPlsrLN1SCWOYV2K1AxYWXKFgL4YvP8Zp4S/ fBTwlFU4IOLTyrvDLkz6RaHj8ZATM4hdBWFWME+GiMQ10x3qBHdAgFJ5Rdg0tiaEVvAw R1mw== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr130897vdv.20.1349947805192; Thu, 11 Oct 2012 02:30:05 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 11 Oct 2012 02:30:05 -0700 (PDT) Date: Thu, 11 Oct 2012 11:30:05 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03/FSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:30:06 -0000 +1 On 10/11/12, Henning Rogge wrote: > On 10/11/2012 02:44 AM, Powell III, Nelson wrote: >> I know the idea of the FSM is not popular, but if we have some >> event/transition strategy or FSM that drives the client and one for >> the server, err... radio and router, then we would be able to include >> session recovery. > > But for this we will need a well-specified FSM. Otherwise the "recovery > strategies" of one side might not fit to the receiver on the other side. > > Even if a part of the strategy can be "implementation detail", the final > states must be well defined. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From abdussalambaryun@gmail.com Thu Oct 11 02:36:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F31821F858E for ; Thu, 11 Oct 2012 02:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqMDP2qoEOs1 for ; Thu, 11 Oct 2012 02:36:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2E021F853B for ; Thu, 11 Oct 2012 02:36:48 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2136147vcb.31 for ; Thu, 11 Oct 2012 02:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Ni+9oYLLrhs5UXEe8PSxsHKIXPX5cuTajgpybtfEcKk=; b=HK2VAqooyvVhIzDYkfIkerpoaJAtzy9eqzcDGn/clPduyoMeL4wKRGFcnyiyngh2Lg m2XeJ+2qmkjyUAYN+9TACltQIvidJ/6S02DknxJBsWh5NtHe5GiEqsGXrt4LMCykSm+l +KqwEjuTQsyNElm+Np5W+kBUJNSllXWiZ16B7rwthKEz8ell7gZqIMzRcKvXTncN0tIa 20/zYpsOWxUDaXyHuKyFu/qVuRzRXnuBqugk9xgTvxu3CQXEgCeSfrYuTO0T83UKw7pi /SqXNk7IUBJbGvnwUx5JLuOUNeUQ54UEJwa5d2uJ3SFwJpvX1PQlyEFmrdhp997gl0dc 9N0w== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr123860vdi.55.1349948207948; Thu, 11 Oct 2012 02:36:47 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 11 Oct 2012 02:36:47 -0700 (PDT) Date: Thu, 11 Oct 2012 11:36:47 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03/ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:36:49 -0000 +1 So we can say: o And DLEP implementations SHOULD use UDP o And DLEP implementations MUST use heartbeats o And DLEP implementations MUST use ACK etc. AB On 10/10/12, Thomas Clausen wrote: > > On Oct 10, 2012, at 9:30 AM, Teco Boot wrote: > >> Some thoughts on how we may get out of some issues. If we use >> RFC 2119 SHOULD language for what is needed for a standard, >> we can accept modified implementations. >> >> So we can say: >> o And DLEP implementations SHOULD use UDP >> o And DLEP implementations SHOULD use heartbeats >> o And DLEP implementations SHOULD use ACK >> etc. >> > > Uhh, I am no great fan of SHOULD - it seems a cop-out, unless it is well > argued under which circumstances and with which consequences one can deviate > from the SHOULD. > > Generally, most SHOULD SHOULD be MUST - or so I've heard the saying go ;) > >> If we think TCP is overkill (I can accept that), we can specify >> each single packet (or message) SHOULD be ACKked. This provides >> reliability and eliminates any congestion. > > Not if it is a SHOULD; it may increase congestion (if someone does not ACK, > for example, with an aggressive retransmission schedule). > > My preference is a much much tighter specification than generous use of > SHOULD. > > Thomas > From abdussalambaryun@gmail.com Thu Oct 11 02:42:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC3D21F84DE for ; Thu, 11 Oct 2012 02:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv4ja3BQBV+e for ; Thu, 11 Oct 2012 02:42:22 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1AAE21F84CF for ; Thu, 11 Oct 2012 02:42:21 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2142287vcb.31 for ; Thu, 11 Oct 2012 02:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xgcDvWim0s2LZYsBZIavURgelBPHQSKpKwbe90OIw6I=; b=HxFUzI9UzP6s8pWoHWNNepXyi63N3IFKuIl8oQFquKYAi5BMLETGkamgXAziVojnyF gSXIqpFr4p/pgzHYIMQs1uajnkKqvLnBBgFUvJI1lnDPPAzYlv9drsi/f8Sa/w4Cv6pa uVMQi6smojudcJNUJM8TEgprQZ1lEl5ErS44EUDX/hVzaZ+bdmXk1Bp7frJiLJOCgDa6 L6jRIJFIXt3fzopJpnl4SToPQqoZWXSaLd3fDPzoFJQDbppFHHev6DlV7blt1PGh8Rpe zprsB66hMgREXFgXEZ3XwDf3S0cFLywyGhy9ly/kPZaWlIfSMkhWL26l6IuVaRaf+KuO Dtrw== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr97580vdb.125.1349948541433; Thu, 11 Oct 2012 02:42:21 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 11 Oct 2012 02:42:21 -0700 (PDT) Date: Thu, 11 Oct 2012 11:42:21 +0200 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03/FSM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:42:22 -0000 > Are there any state issues? > yes, these should be explained, defined easy to trace with FSM, AB On 10/10/12, Bo Berry wrote: > > On Oct 10, 2012, at 1:13 PM, Dearlove, Christopher (UK) wrote: > >> In the grandmother egg-sucking department, also what to do when ACKS don= 't >> come - retries, number, any backoff, etc. Are there any state issues? > > yes, these should be explained, defined > > >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Bo Berry >> Sent: 10 October 2012 14:20 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] Some comments on manet-dlep-03 >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> I suggest we define the ACKs. A radio implementation may choose >> to ignore an ack is a specific case. I'm OK with that. >> >> So let's rally around defining the ACKS. >> >> >> On Oct 10, 2012, at 9:07 AM, Henning Rogge wrote: >> >>> On 10/10/2012 03:04 PM, Teco Boot wrote: >>>> Let the radio wait on ACK, or not, is very different. >>> >>> I was talking about "router sends ACK" and radio process it or ignores >>> it. >>> >>>> If router wants to send data to radio, the protocol gets more complex.= I >>>> lost the status on this, do we want to keep it? >>> >>> Ahh sorry, you are right... >>> >>> had only thought about the "neighbor up/down" ACK, not about the Peer >>> Terminate ACK. >>> >>> (I think that are the only messages that have an ACK in the current DLE= P >>> draft) >>> >>> Henning Rogge >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> >> >> --- >> We cannot solve our problems with the same thinking we used when we >> created them. >> Albert Einstein >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > --- > We cannot solve our problems with the same thinking we used when we creat= ed > them. > Albert Einstein > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Oct 11 02:47:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A736321F86E2 for ; Thu, 11 Oct 2012 02:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDc7VIGWSKnO for ; Thu, 11 Oct 2012 02:47:49 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF7D21F86DD for ; Thu, 11 Oct 2012 02:47:48 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2148335vcb.31 for ; Thu, 11 Oct 2012 02:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3t5MV9UiA3OYWyue0f4wf1SJZWleg3INGMo+rifvEIE=; b=dvTaDSFVOgbQsZ1wWWx3uDaUptofmcbgGe/aBy2Y7L7/2z+CBzG5sipBXg5LuPYDrc mlBaaSZucxEvyn9mewgtiT9i9bslXmQGKzmeus6sA8AcAXHMudJXphb9krlr3FHNgecB avCI1fZCnZeULyxJzsfiDJkkSmook3ybkapc5X7WjPF2Wv71Mvs8IWHoSBRaAVb1l0HC MBDxpIErD5skZdiSvxxV79uMwSxWh/D/2o3HvuBbNKgemFmuOIEnH1ALPmj3IsT55n5r hDoZsq+iOx3p5vKCHtQtjQCX52zMtNVWbZmVE4/FHSStFzLdT208d/WV4hB7coE6xDBG ggYw== MIME-Version: 1.0 Received: by 10.220.154.17 with SMTP id m17mr165741vcw.31.1349948867716; Thu, 11 Oct 2012 02:47:47 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 11 Oct 2012 02:47:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Oct 2012 11:47:47 +0200 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03/RFC5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:47:49 -0000 sorry, please read: IMHO, for now we can use TLVs in the current draft update, because we are updating dlep not routings. AB On 10/11/12, Abdussalam Baryun wrote: >> Any other comments, perspectives from the WG? > > I really don't think we're at rough consensus. I think we are in > discussion, so I hope we can argue why RFC5444 or why not in more > details. There are advantages in using RFC5444. > > My position is that we postpone collecting consensus until we solve > the dlep issues, without closing its discussion by the WG. It may be > reasonable to consider RFC5444 in future. IMHO, for now I don't think > we can use TLVs in the current draft update, because we are updating > dlep not routings. > > AB From aaron@lo-res.org Thu Oct 11 04:15:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A92E21F8661 for ; Thu, 11 Oct 2012 04:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JftNP-W5BvUn for ; Thu, 11 Oct 2012 04:15:10 -0700 (PDT) Received: from mate.lo-res.org (mate.lo-res.org [193.238.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id BCE3E21F862B for ; Thu, 11 Oct 2012 04:15:10 -0700 (PDT) Received: by mate.lo-res.org (Postfix, from userid 65534) id 954AF406D1; Thu, 11 Oct 2012 13:15:07 +0200 (CEST) Received: from [10.71.8.16] (vpn.lo-res.org [193.238.157.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mate.lo-res.org (Postfix) with ESMTPSA id 65686404AB for ; Thu, 11 Oct 2012 13:15:02 +0200 (CEST) From: "L. Aaron Kaplan" Content-Type: multipart/signed; boundary="Apple-Mail=_5988817A-96E5-4459-B03C-50DB35A41385"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Thu, 11 Oct 2012 13:15:00 +0200 Message-Id: To: manet Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [manet] Open call for the CONFINE project X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:15:13 -0000 --Apple-Mail=_5988817A-96E5-4459-B03C-50DB35A41385 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I am probably a bit late at announcing the open call for participants in = the EU FP7 funded CONFINE project. But on the other hand my colleagues = should/could have sent that out already to here. Didn't happen, so I'll do it now (and the deadline got extended anyway). We have a EU FP-7 funded project called CONFINE. The goal is to have experiments in a real world federated wireless = community based network. This is in a sense similar to planetlab, just = that we have a wireless community mesh testbed. Details: http://confine-project.eu/ You can participate in this project and try out all kinds of research = questions that you ever had concerning real world deployments of mesh = networks. In this open call, a part of the total budget is reserved for = researchers (you). Please note that you must be eligible for funding according the to EU = regulations for FP-7. If you are not (for example US institutions are = not directly), you can of course still do experiments on our testbed but = you might not be eligible for EU funding. Deadline for application: 31st of Oct. Details: http://confine-project.eu/open-call-1/ Contact: Felix Freitag, UPC, phone: +34 934011609, Email (preferably) = for information (not submissions): opencall1@confine-project.eu Kind regards, L. Aaron Kaplan --Apple-Mail=_5988817A-96E5-4459-B03C-50DB35A41385 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iEYEARECAAYFAlB2qjQACgkQxEgyMttZ8Yw4MgCdGluOgUOoiCjNMetIIv88fcbU h1kAoIJRJbAky8oC9PZMYhD+QAeoDp+g =i5bD -----END PGP SIGNATURE----- --Apple-Mail=_5988817A-96E5-4459-B03C-50DB35A41385-- From boberry@cisco.com Thu Oct 11 04:35:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADE621F8625 for ; Thu, 11 Oct 2012 04:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.443 X-Spam-Level: X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz6MZKFjJ3PK for ; Thu, 11 Oct 2012 04:35:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1502821F8611 for ; Thu, 11 Oct 2012 04:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1514; q=dns/txt; s=iport; t=1349955337; x=1351164937; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BkkSVbZ0Jsr1yPQFGSqrBAGTeucLDF1zG/7rkHXqg8Y=; b=jsla38bSgLyiqngAgVL6HRcuPckst8JuQxWPD24cKxWDcbkKXB3tMl5D kP1rVxwAWTLzkaInaARaq0ZHbPMBmpPzfiIS3TTinKL1lT51oBiUYZzjG LRqKttehxl48RctMv1XiNTNTQUU65LCkYcu0q/SRCt+L36QJn8//QkG5S Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAeudlCtJV2c/2dsb2JhbABEv0WBCIIgAQEBAwEBAQEPAVsLBQsLGCcHJx8RBhMih1wGC5kkoB6LR4VAYAOVbYViiGOBa4MJ X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130518437" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 11 Oct 2012 11:35:36 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9BBZa51006998; Thu, 11 Oct 2012 11:35:36 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <50767E77.5090801@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 07:35:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <35A848E1-09E8-49A1-8554-903A64299A2B@cisco.com> References: <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> <13044204616BFB43BC7F6B4EC6B015123FB6388A@ROCMXUS20.cs.myharris.net> <50767E77.5090801@fkie.fraunh ofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:35:41 -0000 Henning, I agree, we should add a seq number to the header, needed to support = retries. -Bo On Oct 11, 2012, at 4:08 AM, Henning Rogge wrote: > On 10/11/2012 02:42 AM, Powell III, Nelson wrote: >> Thomas, I agree, I prefer the use of MUST in the case of heartbeats >> and ACKs. As a radio designer, if I decide to make the radio block >> on an ACK, that's my bad for not recognizing the possibility of a >> lost response. The use of heartbeats and message timers allow for >> retries without the use of TCP. >=20 > The current packet format of DLEP does not contain a sequence number. = You cannot send a second packet before you received a successful ACK. = You can just try to send the packet again or drop the connection. >=20 > But maybe you see yourself that the DLEP transport mechanism will get = quite complex if we want to avoid all that problems. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From boberry@cisco.com Thu Oct 11 04:40:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ABD21F8620 for ; Thu, 11 Oct 2012 04:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lNaMpsuoZF1 for ; Thu, 11 Oct 2012 04:40:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5C60521F8582 for ; Thu, 11 Oct 2012 04:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3022; q=dns/txt; s=iport; t=1349955606; x=1351165206; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1mT0aplKSpJLkcpjlzc2+5I2BxY/l2orMZsbAgU8aYM=; b=SX6mJ7rLzZB7UCUSma9INo3UudWjIjdPgeCytVB/nXsolewoSk8xwFxl IVpwZmk6eXsg1p5xSgI8dYV7Gn4ll1N8uKbJAbfuKVnycHjnrHDqywcoT SNXMX9mTKGicGbcd0iz7Ezo9nNjwvL9bIGgMcGgXkLzGlT/VGjgXJWYmT c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALKvdlCtJV2Y/2dsb2JhbABEv0WBCIIgAQEBAwEBAQEPAVsLBQsLGCcHJx8RBhMih1wGC5kmoBqLR4VAYAOVbYViiGOBa4MJ X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130500681" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 11 Oct 2012 11:40:06 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9BBe5d8018565; Thu, 11 Oct 2012 11:40:05 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <50767689.6040202@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 07:40:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202 @fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:40:07 -0000 On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote: > On 10/11/2012 02:32 AM, Powell III, Nelson wrote: >> Bo, Sorry I'm a bit "late to the party" on this thread. I was >> thinking, if a radio does not have the channel capacity to support >> the messaging to determine RLQ to a distant station (e.g. narrowband >> waveforms that require serious optimization to push traffic), then a >> waveform design would automatically assume the RLQ is 100% for all >> transmissions. Maybe that is a bit presumptuous on my part, but I >> would not want to assume less than 100% of a RLQ unless I could >> actually measure it. Even if I could measure it, I would probably use >> discrete steps based on the waveforms capabilities, such as >> auto-rating. Even for auto-rating, IMO, it would make more sense to >> modify the Current Data Rate (CDR) rather than issue a change to the >> RLQ. But my experience in the area is specific to certain frequency >> ranges, so maybe there is some cellular industry advantage I'm >> missing with the RLQ. That being said, I'm not opposed to RLQ; but >> would I assume RLQ=3D100% if the value cannot be derived by the radio >> device. That would normalize any algorithm used to generate a >> routing protocol metric to the MDR and CDR. >=20 > The main issue I have with this is that we are moving a decision on = "network level" (how to handle bad/unknown links) to the radio. No, not really. The router can also use configuration, as you mention = below, to handle optional features and metrics. The router = implementation and computing routing metrics for different routing = protocols is out of scope for DLEP.=20 > The router can easily implement a configuration setting like "how to = handle no RLQ/unknown RLQ" with options like "drop this links", = "consider link perfect" or even "consider link as user-defined value X". >=20 > The "unknown =3D perfect" assumes that RLQ will be 100 for a "typical = radio link", which might not be the case on some radios. In which case = the DLEP specification would make the network to consider = "non-measurable/unknown" links better than the typical ones. >=20 > I think we can do anything with the "special codepoint for unknown, no = TLV for non-supported" RLQ TLV than we can do with the current = specification. And we can sidestep some potential pit traps with it. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Thu Oct 11 04:41:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81F21F8620 for ; Thu, 11 Oct 2012 04:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgrvtKfa45Fq for ; Thu, 11 Oct 2012 04:41:56 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43D21F85F4 for ; Thu, 11 Oct 2012 04:41:56 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMH9H-0000tx-Fd; Thu, 11 Oct 2012 13:41:55 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMH9H-0002VT-Cz; Thu, 11 Oct 2012 13:41:55 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 13:41:55 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 13:41:54 +0200 Message-ID: <5076B07D.3000503@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 13:41:49 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <39E26AB0-91A1-4C6E-8EAF-69405ABF39CF@cisco.com> <9DE79DC3-79DF-4CBA-AF4A-C74728CEF230@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F3FBD62@xmb-aln-x03.cisco.com> <50740923.8040502@fkie.fraunhofer.de> <58C1DE55-5887-49F8-BF6C-312D3AB05A7D@inf-net.nl> <93C32C45-BE9D-46EF-8E05-750BD5454AC8@cisco.com> <507515B1.5030809@fkie.fraunhofer.de> <212B1E1D-9B61-4AF9-8E8D-A8A90E62BADB@inf-net.nl> <05EFA692-3662-4B3C-B927-DA954CECA41B@thomasclausen.org> <13044204616BFB43BC7F6B4EC6B015123FB6388A@ROCMXUS20.cs.myharris.net> <50767E77.5090801@fkie.fraunhofer.de> <35A848E1-09E8-49A1-8554-903A64299A2B@cisco.com> In-Reply-To: <35A848E1-09E8-49A1-8554-903A64299A2B@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060902080301060900050807" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 11:41:55.0245 (UTC) FILETIME=[69F0E5D0:01CDA7A5] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 324d8966091bca9045707e25a905f109 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:41:57 -0000 --------------ms060902080301060900050807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 01:35 PM, Bo Berry wrote: > Henning, > I agree, we should add a seq number to the header, needed to support re= tries. If you only want to do "stop and wait", you do not need them... you just = wait for the ACK before sending anything new. On the other side, if you want "send multiple messages before receiving=20 ACK" you need them both in the message header and in the ACKs TLVs. And we will need to think about sliding windows. And we need to consider that it cannot send out messages that depend on=20 the context of another message that is still not ACKed. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060902080301060900050807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTExMTQxNTJaMCMGCSqGSIb3DQEJBDEWBBSRN+J2miajY3Vy5CKJQIcDuvgUzTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAgMqu/0M8YiH4cJg36QE4EE79LO7mY9bhxBpxJcsI/TyL 7rnjbxJ0g4gob9SS883unXrXW7HOhiOMW7SghyuZW/Pn7sfdfa3v8hq7wDTuND+d4Bt4bJc3 Dm8kj5X9+4qQF4zPDzfyiYsnCIKqLWMDhW/2U36a/Cl9zIOw1VCixHfscgXB4N12EziCuYxS hxeEWungRu2hCYMBBNaT+SC4hsUk6UkKBBt4eZIujuUMz5ZpnzlGh2NWiG5KPeEXBdcsVidh 1YsNlXm/FMUtw7lAhgRtJd+UPo4xVzmutNC9FlwWDIS4F9WEFgsypStyjJFuxkt/GTrqppLU NFSIk6X0HQAAAAAAAA== --------------ms060902080301060900050807-- From henning.rogge@fkie.fraunhofer.de Thu Oct 11 04:44:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE76221F86B4 for ; Thu, 11 Oct 2012 04:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsNR2QoZrRpA for ; Thu, 11 Oct 2012 04:44:04 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0978821F84B5 for ; Thu, 11 Oct 2012 04:44:01 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMHBI-0000xc-CW; Thu, 11 Oct 2012 13:44:00 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMHBI-0002Wx-9t; Thu, 11 Oct 2012 13:44:00 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 13:44:00 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 13:43:59 +0200 Message-ID: <5076B0FE.4080400@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 13:43:58 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.co m> In-Reply-To: <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000506050905090607010600" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 11:44:00.0168 (UTC) FILETIME=[B466A280:01CDA7A5] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d11929bbb37d0bf82123645737fe3651 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:44:04 -0000 --------------ms000506050905090607010600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 01:40 PM, Bo Berry wrote: > On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote: >> The main issue I have with this is that we are moving a decision on >> "network level" (how to handle bad/unknown links) to the radio. > > No, not really. The router can also use configuration, as you > mention below, to handle optional features and metrics. The router > implementation and computing routing metrics for different routing > protocols is out of scope for DLEP. If the Radio HIDES the difference between "perfect RLQ" and "unknown=20 RLQ", the Router is unable to make this decision. And I think most of us (including you) already agreed adding a "255 =3D=20 unknown" codepoint (and allowing to leave out the whole TLV) is a better = strategy than putting two things into the same encoding before. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000506050905090607010600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTExMTQzNThaMCMGCSqGSIb3DQEJBDEWBBRd3wz6B3GfCkSlCMr6slQdhkQk/TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAP2jqA7BGJW3itUVh6C4+gZShL1hYeoOkSmFm++oWW3tT HIBW0tZeYJCxYJjPXU32UkF4YmUZktTt43JZXMn22pTYJfOIsMcvbav2MaTelSUqAU/OACk3 UVQ618qACr3i46kRSSfCe7vkxhvHfTgcNP0Ko11UwzbrzbmDlENE0128wxRe0KHsvXOryiI5 K87y4VgRidLjtxDWrXE/7S3yJq7npph4ZVy7mDIkH/bCGLQoXitTuDIDUs2R7HFzCDFQyyKR J+cajJ60EEGrN6OElTeQS44lv95fFcZ201jaJxXpSfgvHMdGJccF3FIa/XYClEhBMy0LI1r2 Q/gzBBE+WAAAAAAAAA== --------------ms000506050905090607010600-- From boberry@cisco.com Thu Oct 11 04:49:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39F121F862A for ; Thu, 11 Oct 2012 04:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18N8o-GoYiKe for ; Thu, 11 Oct 2012 04:49:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F401921F861D for ; Thu, 11 Oct 2012 04:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1568; q=dns/txt; s=iport; t=1349956158; x=1351165758; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FBMTVCn7b7h2zhwflFY6iFT63kaXqP9P9xin7zPRAsY=; b=FBkUeict6mv+kRjdk8/WmuFldySiYWIjcWnP0v5fGa3GLQsnfOyctgn8 heqNRvsIS1H1+wEkShu+RfRGd4Pz6VlteUZX7+9+YjeomcV5X/SzzS733 qtePLC9ZdVPcK0LimO+Lt3rb4AD0Qxs62zkDqAg6ZR4/UKV1IxEGlajCh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGKxdlCtJV2b/2dsb2JhbABEv0WBCIIgAQEBAwESAWYFCwsYJwdGEQYTIodcBpkqoBqLR4VAYAOVbYViiGOBa4MJ X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130561229" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2012 11:49:17 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9BBnH84009525; Thu, 11 Oct 2012 11:49:17 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <5076B0FE.4080400@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 07:49:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.co m> <5076B0FE.4080400@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:49:18 -0000 On Oct 11, 2012, at 7:43 AM, Henning Rogge wrote: > On 10/11/2012 01:40 PM, Bo Berry wrote: >> On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote: >>> The main issue I have with this is that we are moving a decision on >>> "network level" (how to handle bad/unknown links) to the radio. >>=20 >> No, not really. The router can also use configuration, as you >> mention below, to handle optional features and metrics. The router >> implementation and computing routing metrics for different routing >> protocols is out of scope for DLEP. >=20 > If the Radio HIDES the difference between "perfect RLQ" and "unknown = RLQ", the Router is unable to make this decision. I said I'm OK with defining it. But making use of it when computing a = routing cost is a different matter. The 'unknown' value would be discarded most likely. >=20 > And I think most of us (including you) already agreed adding a "255 =3D = unknown" codepoint (and allowing to leave out the whole TLV) is a better = strategy than putting two things into the same encoding before. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Thu Oct 11 04:51:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3882A21F862B for ; Thu, 11 Oct 2012 04:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.524 X-Spam-Level: X-Spam-Status: No, score=-1.524 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH2E3LyxFh96 for ; Thu, 11 Oct 2012 04:51:20 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D629F21F862A for ; Thu, 11 Oct 2012 04:51:19 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMHIN-0003TT-7A; Thu, 11 Oct 2012 13:51:19 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMHIN-0002oG-4U; Thu, 11 Oct 2012 13:51:19 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 13:51:18 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 13:51:18 +0200 Message-ID: <5076B2B5.8040403@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 13:51:17 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> In-Reply-To: <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070908070504080408050104" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 11:51:18.0983 (UTC) FILETIME=[B9F47D70:01CDA7A6] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e2b21d81e24158e5c3d75098b3c9c024 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:51:21 -0000 --------------ms070908070504080408050104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 01:49 PM, Bo Berry wrote: > > On Oct 11, 2012, at 7:43 AM, Henning Rogge wrote: > >> On 10/11/2012 01:40 PM, Bo Berry wrote: >>> On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote: >>>> The main issue I have with this is that we are moving a decision on >>>> "network level" (how to handle bad/unknown links) to the radio. >>> >>> No, not really. The router can also use configuration, as you >>> mention below, to handle optional features and metrics. The router >>> implementation and computing routing metrics for different routing >>> protocols is out of scope for DLEP. >> >> If the Radio HIDES the difference between "perfect RLQ" and "unknown R= LQ", the Router is unable to make this decision. > > I said I'm OK with defining it. But making use of it when computing a = routing cost is a different matter. > The 'unknown' value would be discarded most likely. As long as we make using this codepoint on the RADIO side mandatory this = is fine. As I said above, its a network/routing-layer decision how to interpret a = "unknown RLQ" value... discarding it is a perfectly fine decision for=20 the ROUTER. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070908070504080408050104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTExMTUxMTdaMCMGCSqGSIb3DQEJBDEWBBRnqvuBw/dOjFR6igh4RT31lTnCnzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAKsCUc/v/iogM65U3+1uvhwe1lde5G34MxLAhmdy0grb/ 5DU7kvD8OXMFY5zfEpdSR68ANYCMP4xq0ORuhHaijyuqJ5ume+ftncNplafuejIbOVeJy2R1 7CqduWjz1CWo8hbC2iLeszKWu0S4DQvKTkLZTWz1uCjakAQ66/Pd/7fTARdoMnWa0bPgKDrQ B9YyamQb/auYiv4r3mpYaley/9P9DWV0F9Xkyli+WjwDz4Rzp9KbbhfkXLfY7o5n3AhJFm73 rUplose9oFS2VvQWzCtWaC9DaLTUwH4ncgn16f46iAabUxpuSY8uwUhBW/MHcM6wb0T2jdqu gsih8x27lgAAAAAAAA== --------------ms070908070504080408050104-- From boberry@cisco.com Thu Oct 11 04:54:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8514321F8618 for ; Thu, 11 Oct 2012 04:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1Pg023izOey for ; Thu, 11 Oct 2012 04:54:43 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 71AEF21F861C for ; Thu, 11 Oct 2012 04:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1837; q=dns/txt; s=iport; t=1349956477; x=1351166077; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=N3JXwnOLGBBwsb/J8DXPw/qjipmcsvVfcPcnIFmHWq8=; b=jc7/OMJ+mn9KUGAHwaXroqMFCAXiJInF3WiKhsE3nM1/GB8tB0CxrDf+ TkUW9VoQPEqfCnF5/ybvVg1giFYOllY5QfRtvTdu4gwVtb9MCfkMATwlE 5Xw/FOBV9LRvndTBflAOx/mIqQGiW+wnIwmRlvzgkFzCXnqJoA+DVgC9a k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPuydlCtJXG8/2dsb2JhbABEv0WBCIIgAQEBAwESAWYFCwsYJwdGEQYTIodcBpkmoBuLR4VAYAOVbYViiGOBa4MJ X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130523193" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 11 Oct 2012 11:54:37 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9BBsal3025934; Thu, 11 Oct 2012 11:54:36 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <5076B2B5.8040403@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 07:54:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:54:44 -0000 On Oct 11, 2012, at 7:51 AM, Henning Rogge wrote: > On 10/11/2012 01:49 PM, Bo Berry wrote: >>=20 >> On Oct 11, 2012, at 7:43 AM, Henning Rogge wrote: >>=20 >>> On 10/11/2012 01:40 PM, Bo Berry wrote: >>>> On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote: >>>>> The main issue I have with this is that we are moving a decision = on >>>>> "network level" (how to handle bad/unknown links) to the radio. >>>>=20 >>>> No, not really. The router can also use configuration, as you >>>> mention below, to handle optional features and metrics. The router >>>> implementation and computing routing metrics for different routing >>>> protocols is out of scope for DLEP. >>>=20 >>> If the Radio HIDES the difference between "perfect RLQ" and "unknown = RLQ", the Router is unable to make this decision. >>=20 >> I said I'm OK with defining it. But making use of it when computing = a routing cost is a different matter. >> The 'unknown' value would be discarded most likely. >=20 > As long as we make using this codepoint on the RADIO side mandatory = this is fine. I do not think this is necessary and do not think it should be = mandatory. >=20 > As I said above, its a network/routing-layer decision how to interpret = a "unknown RLQ" value... discarding it is a perfectly fine decision for = the ROUTER. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Thu Oct 11 05:12:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6051521F8718 for ; Thu, 11 Oct 2012 05:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhVoQxi9yYii for ; Thu, 11 Oct 2012 05:12:21 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 20B6821F86D3 for ; Thu, 11 Oct 2012 05:12:21 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMHcg-0002dP-61; Thu, 11 Oct 2012 14:12:18 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMHcg-0003Np-3L; Thu, 11 Oct 2012 14:12:18 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 14:12:17 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 14:12:17 +0200 Message-ID: <5076B7A0.2050206@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 14:12:16 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020500030802040103030007" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 12:12:17.0960 (UTC) FILETIME=[A85D2280:01CDA7A9] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 9fba06858ea504e244212894029289c9 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:12:22 -0000 --------------ms020500030802040103030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 01:54 PM, Bo Berry wrote: > > On Oct 11, 2012, at 7:51 AM, Henning Rogge wrote: > >> On 10/11/2012 01:49 PM, Bo Berry wrote: >>> >>> On Oct 11, 2012, at 7:43 AM, Henning Rogge wrote: >>> >>>> On 10/11/2012 01:40 PM, Bo Berry wrote: >>>>> On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote: >>>>>> The main issue I have with this is that we are moving a >>>>>> decision on "network level" (how to handle bad/unknown >>>>>> links) to the radio. >>>>> >>>>> No, not really. The router can also use configuration, as >>>>> you mention below, to handle optional features and metrics. >>>>> The router implementation and computing routing metrics for >>>>> different routing protocols is out of scope for DLEP. >>>> >>>> If the Radio HIDES the difference between "perfect RLQ" and >>>> "unknown RLQ", the Router is unable to make this decision. >>> >>> I said I'm OK with defining it. But making use of it when >>> computing a routing cost is a different matter. The 'unknown' >>> value would be discarded most likely. >> >> As long as we make using this codepoint on the RADIO side mandatory >> this is fine. > > I do not think this is necessary and do not think it should be > mandatory. I hope I do not misinterpret you, but I will try to summarize the two=20 positions. First, some radios want to publish an RLQ value, even when their=20 algorithm couldn't measure one. This might make sense, depending on the=20 method how the RLQ is calculated and how the linklayer works. Second, some routers want to decide for themselves how they handle links = with a RLQ which the radio cannot measure. Maybe we can decouple this two things to get a good compromise (I think=20 it was already proposed yesterday): We allow the radio to publish any kind of RLQ it wants (even when=20 incalculable), but we add a second byte (or just a bit?) information to=20 the RLQ TLV, which contains a flag that tells the router if the RLQ=20 value was measured or not. With this the radio is able to suggest an RLQ value for unmeasurable=20 links, but its still the routers implementation decision if the router=20 accepts this value or not. Do you think that could fit to both suggested use-cases? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020500030802040103030007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTExMjEyMTZaMCMGCSqGSIb3DQEJBDEWBBQtwG6uCXo+BqvdFmurwd64Tm+b8TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAmMPKh/nWgL8L6Im/kBXAeXKtcAVioluhzdVisZUAWmbj psXtv70VmBNL6Sr2mHaKSr6eXUKJ3/OMCviwWM0broVYD1Hgw5eIHKS77ACI7TVpXnRt0QSh xE0lkRlVknQScjJr0C/fG1b6r8/9L2mI2SvR6fUnWnpzowqXWhF334uW8+PTeJWsZZhBqGf2 Molc3KOpUAXS7UcuIQtMG05RiEUTuIoN0FWnE6B/Fz0/NtJoKZ1CgP5j+svDoZ+CY/4hWuiW SoMYbUbiw6DtpBFq7VpLSQN9DJ8RpViE5mClUd6+332kH6olLo2vW1tKkb33t6aFjAZdcvWf qvB6GWL79QAAAAAAAA== --------------ms020500030802040103030007-- From boberry@cisco.com Thu Oct 11 05:25:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6287121F8718 for ; Thu, 11 Oct 2012 05:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuwWXx88J6vN for ; Thu, 11 Oct 2012 05:25:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8356A21F870B for ; Thu, 11 Oct 2012 05:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3412; q=dns/txt; s=iport; t=1349958340; x=1351167940; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yLy74i1FTVBmDXdOzLEQ/R+8LADa6Gz5v8rAeXY7X90=; b=PRfasHCG41wy1/H0en/GckBKRGa/x8UwM+s8w7oqa9xDP7NvSvJr6zoe dqJ5EbjtZDrbeqWDslVzeGGGwZHEcJ2gSaO49q8wQiJEvSxCYyffl/qc0 2tXANo/LODuDqQ5l5+WFNEYlMl+nXc16wOzGQKMAlDoHGwZgK2fVNpdy5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcFAAW6dlCtJV2d/2dsb2JhbABEt0MEh36BCIIgAQEBAwESAWYFCwsYJwdGEQYKCSKHXAaZEKAYi0eFQGADlW2FYohjgWuDCQ X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130532398" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2012 12:25:40 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9BCPcUR020889; Thu, 11 Oct 2012 12:25:39 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <5076B7A0.2050206@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 08:25:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.d e> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:25:41 -0000 On Oct 11, 2012, at 8:12 AM, Henning Rogge wrote: > On 10/11/2012 01:54 PM, Bo Berry wrote: >>=20 >> On Oct 11, 2012, at 7:51 AM, Henning Rogge wrote: >>=20 >>> On 10/11/2012 01:49 PM, Bo Berry wrote: >>>>=20 >>>> On Oct 11, 2012, at 7:43 AM, Henning Rogge wrote: >>>>=20 >>>>> On 10/11/2012 01:40 PM, Bo Berry wrote: >>>>>> On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote: >>>>>>> The main issue I have with this is that we are moving a >>>>>>> decision on "network level" (how to handle bad/unknown >>>>>>> links) to the radio. >>>>>>=20 >>>>>> No, not really. The router can also use configuration, as >>>>>> you mention below, to handle optional features and metrics. >>>>>> The router implementation and computing routing metrics for >>>>>> different routing protocols is out of scope for DLEP. >>>>>=20 >>>>> If the Radio HIDES the difference between "perfect RLQ" and >>>>> "unknown RLQ", the Router is unable to make this decision. >>>>=20 >>>> I said I'm OK with defining it. But making use of it when >>>> computing a routing cost is a different matter. The 'unknown' >>>> value would be discarded most likely. >>>=20 >>> As long as we make using this codepoint on the RADIO side mandatory >>> this is fine. >>=20 >> I do not think this is necessary and do not think it should be >> mandatory. >=20 > I hope I do not misinterpret you, but I will try to summarize the two = positions. >=20 > First, some radios want to publish an RLQ value, even when their = algorithm couldn't measure one. This might make sense, depending on the = method how the RLQ is calculated and how the linklayer works. >=20 > Second, some routers want to decide for themselves how they handle = links with a RLQ which the radio cannot measure. >=20 > Maybe we can decouple this two things to get a good compromise (I = think it was already proposed yesterday): >=20 > We allow the radio to publish any kind of RLQ it wants (even when = incalculable), but we add a second byte (or just a bit?) information to = the RLQ TLV, which contains a flag that tells the router if the RLQ = value was measured or not. >=20 > With this the radio is able to suggest an RLQ value for unmeasurable = links, but its still the routers implementation decision if the router = accepts this value or not. >=20 > Do you think that could fit to both suggested use-cases? Why? Don't see the value. Just define the TLV as optional. I do not = think we need to start defining flags. I do not think we want to mandate a TLV transfer from a resource = constrained (typically) radio that would indicate an unknown value. = While one radio may choose to generate TLVs with 100 or with 'unknown', = another may not.=20 The same shuold be applied to the Resource TLV, optional.=20 Just because the radio sends a valid metric, does not imply it will be = used in a routing cost.=20 >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From henning.rogge@fkie.fraunhofer.de Thu Oct 11 05:29:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7818621F8606 for ; Thu, 11 Oct 2012 05:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmgY1q6QO0vg for ; Thu, 11 Oct 2012 05:29:04 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3221F8607 for ; Thu, 11 Oct 2012 05:29:03 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMHss-0007i3-OU; Thu, 11 Oct 2012 14:29:02 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMHss-0003q6-Ll; Thu, 11 Oct 2012 14:29:02 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 14:29:02 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 11 Oct 2012 14:29:02 +0200 Message-ID: <5076BB8D.4000705@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 14:29:01 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121006 Thunderbird/16.0 MIME-Version: 1.0 To: Bo Berry References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> In-Reply-To: <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060506090705020206000106" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 11 Oct 2012 12:29:02.0513 (UTC) FILETIME=[FF1FC210:01CDA7AB] X-Virus-Scanned: yes (ClamAV 0.97.5/15453/Thu Oct 11 06:09:16 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: da8eb4258d586be99f3c918cac8a614c Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:29:04 -0000 --------------ms060506090705020206000106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 02:25 PM, Bo Berry wrote: >> I hope I do not misinterpret you, but I will try to summarize the >> two positions. >> >> First, some radios want to publish an RLQ value, even when their >> algorithm couldn't measure one. This might make sense, depending on >> the method how the RLQ is calculated and how the linklayer works. >> >> Second, some routers want to decide for themselves how they handle >> links with a RLQ which the radio cannot measure. >> >> Maybe we can decouple this two things to get a good compromise (I >> think it was already proposed yesterday): >> >> We allow the radio to publish any kind of RLQ it wants (even when >> incalculable), but we add a second byte (or just a bit?) >> information to the RLQ TLV, which contains a flag that tells the >> router if the RLQ value was measured or not. >> >> With this the radio is able to suggest an RLQ value for >> unmeasurable links, but its still the routers implementation >> decision if the router accepts this value or not. >> >> Do you think that could fit to both suggested use-cases? > > Why? Don't see the value. Just define the TLV as optional. I do not > think we need to start defining flags. > > I do not think we want to mandate a TLV transfer from a resource > constrained (typically) radio that would indicate an unknown value. > While one radio may choose to generate TLVs with 100 or with > 'unknown', another may not. > > The same shuold be applied to the Resource TLV, optional. > > Just because the radio sends a valid metric, does not imply it will > be used in a routing cost. The point is that if we do as you suggest, the router will not know how=20 to interpret the "100" value. A protocol like DLEP should not be=20 ambiguous with its transmitted values, especially if the data has been=20 available to the sender! The radio does not know the need of the router, so it should not decide=20 if it hides the "unknown" value from the router or not. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060506090705020206000106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTExMjI5MDFaMCMGCSqGSIb3DQEJBDEWBBQ3yMvP4V1ThUHvlfcTu6WArw1lHzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEADNrNVK8CY6Gn1cRyOjSrc0pkBiFPC8Cf2N5Tbp9hr2V/ hsMlE5icdmfGuwu4QMoGOzqNWiDX5zP0qyth2Eu0bwFjFKjD9hm47BrCKjYs+gWMJ/eySr4I E0aN4+rRs/icvlg1M+HuXcv1ZJorVKTLH99ec2h/wi6NWosu8RSHs69HkV4pLek2ZuETnhHh ni4VO9yyh+G0S6VxWF7BHl7I27mHaPeyjTYSVIGxaEsD4YHkLUKPfkCTt6a+rFnfT/nU5uxl c43mpD/Cfsmnvkt8Zsr05HSOqoEZ0f/Cj8q3uhk6Yl9MJmQxB7LF9ldJ7D6wz2yRMoD7Tr2K lJmEFzpNMAAAAAAAAA== --------------ms060506090705020206000106-- From boberry@cisco.com Thu Oct 11 05:35:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18421F870F for ; Thu, 11 Oct 2012 05:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSRrcDYfR574 for ; Thu, 11 Oct 2012 05:35:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AA6C321F870E for ; Thu, 11 Oct 2012 05:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2871; q=dns/txt; s=iport; t=1349958953; x=1351168553; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uRz6a1H9rLW9GibdohrdJ6TVFDqSbv5MSZFx9Z6DwyM=; b=DbycyU9mb6KLZWnCkwG/sokVlgLUrsWmC71j3KjG2/Kdfxfxs0oSiWIl 665WZYCoN2vqyUKgJ6I7F32aVwN1dW0OOIxCNREalp3ouoRF0SlTrZgi7 XV26ClDgqyunu2+qXEGqjfiW7nTUYe/fpUe/JT/NbwXXRyEgpe953QzcW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgFAKi7dlCtJV2b/2dsb2JhbABEt0MEh36BCIIgAQEBAwESAWYFCwsYFRIHRhEGCgkih1wGmQWgGItHgnOCTWADlW2FYohjgWuDCQ X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130569606" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 11 Oct 2012 12:35:53 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9BCZqZm019880; Thu, 11 Oct 2012 12:35:52 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <5076BB8D.4000705@fkie.fraunhofer.de> Date: Thu, 11 Oct 2012 08:35:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:35:54 -0000 On Oct 11, 2012, at 8:29 AM, Henning Rogge wrote: > On 10/11/2012 02:25 PM, Bo Berry wrote: >>> I hope I do not misinterpret you, but I will try to summarize the >>> two positions. >>>=20 >>> First, some radios want to publish an RLQ value, even when their >>> algorithm couldn't measure one. This might make sense, depending on >>> the method how the RLQ is calculated and how the linklayer works. >>>=20 >>> Second, some routers want to decide for themselves how they handle >>> links with a RLQ which the radio cannot measure. >>>=20 >>> Maybe we can decouple this two things to get a good compromise (I >>> think it was already proposed yesterday): >>>=20 >>> We allow the radio to publish any kind of RLQ it wants (even when >>> incalculable), but we add a second byte (or just a bit?) >>> information to the RLQ TLV, which contains a flag that tells the >>> router if the RLQ value was measured or not. >>>=20 >>> With this the radio is able to suggest an RLQ value for >>> unmeasurable links, but its still the routers implementation >>> decision if the router accepts this value or not. >>>=20 >>> Do you think that could fit to both suggested use-cases? >>=20 >> Why? Don't see the value. Just define the TLV as optional. I do not >> think we need to start defining flags. >>=20 >> I do not think we want to mandate a TLV transfer from a resource >> constrained (typically) radio that would indicate an unknown value. >> While one radio may choose to generate TLVs with 100 or with >> 'unknown', another may not. >>=20 >> The same shuold be applied to the Resource TLV, optional. >>=20 >> Just because the radio sends a valid metric, does not imply it will >> be used in a routing cost. >=20 > The point is that if we do as you suggest, the router will not know = how to interpret the "100" value. A protocol like DLEP should not be = ambiguous with its transmitted values, especially if the data has been = available to the sender! We can mandate the RLQ TLV and an unknown value. A radio that cannot = compute RLQ can hard code 100. Another radio hard codes unknown. =20 Or make it optional. Either way the router has to account for. =20 Optional works for me. >=20 > The radio does not know the need of the router, so it should not = decide if it hides the "unknown" value from the router or not. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From prvs=06314f90c2=npowell@harris.com Thu Oct 11 05:39:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D3221F873C for ; Thu, 11 Oct 2012 05:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaWGJvTKyBs3 for ; Thu, 11 Oct 2012 05:39:37 -0700 (PDT) Received: from mlbefw1.harris.com (mlbefw1.harris.com [192.52.233.75]) by ietfa.amsl.com (Postfix) with ESMTP id 13A7A21F871A for ; Thu, 11 Oct 2012 05:39:36 -0700 (PDT) From: "Powell III, Nelson" To: Bo Berry , Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfxI3NnYC7q8k+nkZtOb2VpkZenf/vAgABxjoCAAgCEgIAAsLWAgAAxoACAA+2GAIAAcJkAgAA8ZICAAbOXgIAAA3MAgAAiiwCAAABqgIAABVmAgAAAgQCAAAI6AIAAAy6AgAAD2gCAAAHFAIAAAX4AgAAAWgCAAAQ7AIAAAWUAgAABboCAAADdAIAAAUcAgAAGPQCAAAzBgIAAB8yAgAADmQCAAAkKgIAATpUAgAFxjcCAALw2gIAARJ2AgAABEwCAAAF/gIAAAIyAgAAA8ACAAATtAIAAA78AgAAA74CAAAHtAP//vT9Q Date: Thu, 11 Oct 2012 12:39:19 +0000 Message-ID: <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> In-Reply-To: <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:39:39 -0000 Bo, +1 to the optional approach. I would rather the radio be able to inform the router that it cannot provid= e an RLQ and never send that TLV. Could the session establishment procedur= es allow for enabling or disabling the use of TLV's like LCP does for PPP c= onnections? Nelson -----Original Message----- From: Bo Berry [mailto:boberry@cisco.com]=20 Sent: Thursday, October 11, 2012 8:36 AM To: Henning Rogge Cc: manet@ietf.org; Powell III, Nelson Subject: Re: [manet] Some comments on manet-dlep-03 On Oct 11, 2012, at 8:29 AM, Henning Rogge wrote: > On 10/11/2012 02:25 PM, Bo Berry wrote: >>> I hope I do not misinterpret you, but I will try to summarize the=20 >>> two positions. >>>=20 >>> First, some radios want to publish an RLQ value, even when their=20 >>> algorithm couldn't measure one. This might make sense, depending on=20 >>> the method how the RLQ is calculated and how the linklayer works. >>>=20 >>> Second, some routers want to decide for themselves how they handle=20 >>> links with a RLQ which the radio cannot measure. >>>=20 >>> Maybe we can decouple this two things to get a good compromise (I=20 >>> think it was already proposed yesterday): >>>=20 >>> We allow the radio to publish any kind of RLQ it wants (even when=20 >>> incalculable), but we add a second byte (or just a bit?) information=20 >>> to the RLQ TLV, which contains a flag that tells the router if the=20 >>> RLQ value was measured or not. >>>=20 >>> With this the radio is able to suggest an RLQ value for unmeasurable=20 >>> links, but its still the routers implementation decision if the=20 >>> router accepts this value or not. >>>=20 >>> Do you think that could fit to both suggested use-cases? >>=20 >> Why? Don't see the value. Just define the TLV as optional. I do not=20 >> think we need to start defining flags. >>=20 >> I do not think we want to mandate a TLV transfer from a resource=20 >> constrained (typically) radio that would indicate an unknown value. >> While one radio may choose to generate TLVs with 100 or with=20 >> 'unknown', another may not. >>=20 >> The same shuold be applied to the Resource TLV, optional. >>=20 >> Just because the radio sends a valid metric, does not imply it will=20 >> be used in a routing cost. >=20 > The point is that if we do as you suggest, the router will not know how t= o interpret the "100" value. A protocol like DLEP should not be ambiguous w= ith its transmitted values, especially if the data has been available to th= e sender! We can mandate the RLQ TLV and an unknown value. A radio that cannot compu= te RLQ can hard code 100. Another radio hard codes unknown. =20 Or make it optional. Either way the router has to account for. =20 Optional works for me. >=20 > The radio does not know the need of the router, so it should not decide i= f it hides the "unknown" value from the router or not. >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 > Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 > Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20 > Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 --- We cannot solve our problems with the same thinking we used when we created= them.=20 Albert Einstein From sratliff@cisco.com Thu Oct 11 07:05:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1833621F86F8 for ; Thu, 11 Oct 2012 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CKvAli6Api8 for ; Thu, 11 Oct 2012 07:05:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 06B5B21F86C7 for ; Thu, 11 Oct 2012 07:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4783; q=dns/txt; s=iport; t=1349964341; x=1351173941; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GLwxi3og4XcXVmIYyFCMI2CTNhJHJY3PjO+zdYDAReg=; b=GMmZYAe9JqJFZVG5vlTOjZAWiSqqgtWVkO98PxqXgRd5bvC1877JIOdL /dzFMIlF4SZA8XeA2FXjOv97nu71hNmfgSGpElTxBQxVF8KCGYqHJq8ag X/xibngaf9aUXrXO6Zj7rUWKUwQdM9uXPCy0W/TgZeutyZXYrE5pCLTgn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFADfRdlCtJV2c/2dsb2JhbABEt0MEh36BCIIgAQEBAwEBAQEPAVsLBQcEAgEIEQQBAQEKCxIHJwsUCQgCBAoEBQgah1wGC5owoBaLR4Jzgk1gA4gjnA+Ba4JtgVoHNg X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130567104" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2012 14:05:40 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9BE5e3j006754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 14:05:40 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 09:05:40 -0500 From: "Stan Ratliff (sratliff)" To: "Powell III, Nelson" Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIIA= Date: Thu, 11 Oct 2012 14:05:39 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> In-Reply-To: <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--46.845100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:05:42 -0000 I've read the thread, trying to catch-up on the conversation. To be honest,= I'm not sure where we're at, presently.=20 I think there's consensus around making RLQ (and Latency, and Resources) OP= TIONAL TLVs. As to reserving a code point for an RLQ value of "unknown", I = don't think we have consensus. I for one am at a complete loss trying to un= derstand the circumstances under which a router would get an "unknown" valu= e, and what the router would actually do with it (other than ignore and dis= card it). Lastly, I'm still going to need someone to suggest some text as t= o how we explain this in the draft, to avoid the obvious questions after pu= blication.=20 My position (FWIW) is that we make RLQ, Resources, and Latency optional, an= d put some text in explaining to implementers that if they get in a situati= on where, for example, RLQ cannot be calculated (e.g. the "unknown" case), = then simply don't send the TLV.=20 Regards, Stan On Oct 11, 2012, at 8:39 AM, Powell III, Nelson wrote: > Bo, > +1 to the optional approach. >=20 > I would rather the radio be able to inform the router that it cannot prov= ide an RLQ and never send that TLV. Could the session establishment proced= ures allow for enabling or disabling the use of TLV's like LCP does for PPP= connections? >=20 > Nelson >=20 > -----Original Message----- > From: Bo Berry [mailto:boberry@cisco.com]=20 > Sent: Thursday, October 11, 2012 8:36 AM > To: Henning Rogge > Cc: manet@ietf.org; Powell III, Nelson > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 >=20 > On Oct 11, 2012, at 8:29 AM, Henning Rogge wrote: >=20 >> On 10/11/2012 02:25 PM, Bo Berry wrote: >>>> I hope I do not misinterpret you, but I will try to summarize the=20 >>>> two positions. >>>>=20 >>>> First, some radios want to publish an RLQ value, even when their=20 >>>> algorithm couldn't measure one. This might make sense, depending on=20 >>>> the method how the RLQ is calculated and how the linklayer works. >>>>=20 >>>> Second, some routers want to decide for themselves how they handle=20 >>>> links with a RLQ which the radio cannot measure. >>>>=20 >>>> Maybe we can decouple this two things to get a good compromise (I=20 >>>> think it was already proposed yesterday): >>>>=20 >>>> We allow the radio to publish any kind of RLQ it wants (even when=20 >>>> incalculable), but we add a second byte (or just a bit?) information=20 >>>> to the RLQ TLV, which contains a flag that tells the router if the=20 >>>> RLQ value was measured or not. >>>>=20 >>>> With this the radio is able to suggest an RLQ value for unmeasurable=20 >>>> links, but its still the routers implementation decision if the=20 >>>> router accepts this value or not. >>>>=20 >>>> Do you think that could fit to both suggested use-cases? >>>=20 >>> Why? Don't see the value. Just define the TLV as optional. I do not=20 >>> think we need to start defining flags. >>>=20 >>> I do not think we want to mandate a TLV transfer from a resource=20 >>> constrained (typically) radio that would indicate an unknown value. >>> While one radio may choose to generate TLVs with 100 or with=20 >>> 'unknown', another may not. >>>=20 >>> The same shuold be applied to the Resource TLV, optional. >>>=20 >>> Just because the radio sends a valid metric, does not imply it will=20 >>> be used in a routing cost. >>=20 >> The point is that if we do as you suggest, the router will not know how = to interpret the "100" value. A protocol like DLEP should not be ambiguous = with its transmitted values, especially if the data has been available to t= he sender! >=20 >=20 > We can mandate the RLQ TLV and an unknown value. A radio that cannot com= pute RLQ can hard code 100. Another radio hard codes unknown. =20 >=20 > Or make it optional. >=20 > Either way the router has to account for. =20 >=20 > Optional works for me. >=20 >=20 >>=20 >> The radio does not know the need of the router, so it should not decide = if it hides the "unknown" value from the router or not. >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20 >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >=20 > --- > We cannot solve our problems with the same thinking we used when we creat= ed them.=20 > Albert Einstein >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Martin.Duke@boeing.com Thu Oct 11 07:43:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3F421F8738 for ; Thu, 11 Oct 2012 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-nRtbu-yeXN for ; Thu, 11 Oct 2012 07:43:11 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FF21F872A for ; Thu, 11 Oct 2012 07:43:10 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9BEhJFE017190 for ; Thu, 11 Oct 2012 07:43:20 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9BEhJ72017187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Oct 2012 07:43:19 -0700 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Thu, 11 Oct 2012 07:43:09 -0700 From: "Duke, Martin" To: "Stan Ratliff (sratliff)" , "Powell III, Nelson" Date: Thu, 11 Oct 2012 07:43:08 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScA== Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:43:12 -0000 I don't understand the objection that we don't know yet what to do with cod= e UNKNOWN. My understanding of the DLEP draft is it provides a way for radi= os to present information to the routers and routers to send requests to ra= dios, and does not cover what the router does with those reports. It's enti= rely reasonable for the radio to throw out RLQ or latency reports because t= raffic doesn't care much about either. It seems to odd to create an ambiguity for one particular codepoint that re= presents both an acceptable value (e.g., 100 or 0) and an unknown value. I = agree that simply omitting the TLV is adequate, except in cases when the me= tric transitions from a known state to an unknown one. I think this is a co= rner case, but a corner case that's low-cost to resolve. Why not give as mu= ch information as possible to the router and let the smart guys who build r= outers figure out what they can do with it? To be clear, I'm not trying to disallow the case that radios with no measur= ement simply omit the TLV. Martin=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff (sratliff) Sent: Thursday, October 11, 2012 7:06 AM To: Powell III, Nelson Cc: manet@ietf.org; Bo Berry (boberry) Subject: Re: [manet] Some comments on manet-dlep-03 I've read the thread, trying to catch-up on the conversation. To be honest,= I'm not sure where we're at, presently.=20 I think there's consensus around making RLQ (and Latency, and Resources) OP= TIONAL TLVs. As to reserving a code point for an RLQ value of "unknown", I = don't think we have consensus. I for one am at a complete loss trying to un= derstand the circumstances under which a router would get an "unknown" valu= e, and what the router would actually do with it (other than ignore and dis= card it). Lastly, I'm still going to need someone to suggest some text as t= o how we explain this in the draft, to avoid the obvious questions after pu= blication.=20 My position (FWIW) is that we make RLQ, Resources, and Latency optional, an= d put some text in explaining to implementers that if they get in a situati= on where, for example, RLQ cannot be calculated (e.g. the "unknown" case), = then simply don't send the TLV.=20 Regards, Stan From sratliff@cisco.com Thu Oct 11 08:24:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88C21F86C3 for ; Thu, 11 Oct 2012 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkHgQeTxA9mG for ; Thu, 11 Oct 2012 08:24:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 434BF21F856F for ; Thu, 11 Oct 2012 08:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3640; q=dns/txt; s=iport; t=1349969064; x=1351178664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lFZoLBnim+eaDuSl6MkaXg8dZklAnPM3rbJ4Ua2O6QA=; b=c9lc2q/OoBrXzOAsaZvsF4yx5jTA0ag7/RB59dV+XJZlLTl5Z0lCXyeE LnMYJnQH/ry8IsbNQwPc3at190esX3A6LPp3cnlcqHk5R3BvZjb7wTPZz oi2SbvKNeqNkSMp+Wi/v7aPiDoelDGkXirug+sNHn8rlVzumflEI1Tj4Z Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEbjdlCtJV2Z/2dsb2JhbABEv0eBCIIgAQEBAwESASc/BQcEAgEIEQQBAQsUCQcyFAkIAgQOBQgah1wGmgegIYtHFIUsYAOkMoFrgm2BWgk0 X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="scan'208";a="130642463" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2012 15:24:23 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9BFON9J012330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 15:24:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 10:24:23 -0500 From: "Stan Ratliff (sratliff)" To: "Duke, Martin" Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwA Date: Thu, 11 Oct 2012 15:24:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.34.126] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--46.547900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7D27DE1F9C93194BAC8CCA8B0F31301C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:24:27 -0000 Again, my objection is purely based on the fat that I don't understand how/= where/when/why this would be used. It's hard to insert even generic, "hand-= waving" level text on something without at least having some notion of why = it would be used. I keep asking for suggested text to explain, and I don't = get a response. So, IF we get consensus on "unknown", my proposed text is:= =20 "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ is = supported, but not currently calculable. The authors have no idea under wha= t circumstances this would occur. Routers receiving a value of RLQ_UNKNOWN = are free to take any action deemed appropriate, including (but not limited = to) ignoring the value, producing log messages, or bursting into flames. Th= e RLQ_UNKNOWN (TBD) value was added at the request of the working group, as= consensus formed around the key ideas that this MAY allow for innovation, = even though none of the working group members were able to note a set of ci= rcumstances under which this innovation might take place. So, in an effort = to stop the email storm, the authors added the additional code point." Stan On Oct 11, 2012, at 10:43 AM, Duke, Martin wrote: > I don't understand the objection that we don't know yet what to do with c= ode UNKNOWN. My understanding of the DLEP draft is it provides a way for ra= dios to present information to the routers and routers to send requests to = radios, and does not cover what the router does with those reports. It's en= tirely reasonable for the radio to throw out RLQ or latency reports because= traffic doesn't care much about either. >=20 > It seems to odd to create an ambiguity for one particular codepoint that = represents both an acceptable value (e.g., 100 or 0) and an unknown value. = I agree that simply omitting the TLV is adequate, except in cases when the = metric transitions from a known state to an unknown one. I think this is a = corner case, but a corner case that's low-cost to resolve. Why not give as = much information as possible to the router and let the smart guys who build= routers figure out what they can do with it? >=20 > To be clear, I'm not trying to disallow the case that radios with no meas= urement simply omit the TLV. >=20 > Martin=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Stan Ratliff (sratliff) > Sent: Thursday, October 11, 2012 7:06 AM > To: Powell III, Nelson > Cc: manet@ietf.org; Bo Berry (boberry) > Subject: Re: [manet] Some comments on manet-dlep-03 >=20 > I've read the thread, trying to catch-up on the conversation. To be hones= t, I'm not sure where we're at, presently.=20 >=20 > I think there's consensus around making RLQ (and Latency, and Resources) = OPTIONAL TLVs. As to reserving a code point for an RLQ value of "unknown", = I don't think we have consensus. I for one am at a complete loss trying to = understand the circumstances under which a router would get an "unknown" va= lue, and what the router would actually do with it (other than ignore and d= iscard it). Lastly, I'm still going to need someone to suggest some text as= to how we explain this in the draft, to avoid the obvious questions after = publication.=20 >=20 > My position (FWIW) is that we make RLQ, Resources, and Latency optional, = and put some text in explaining to implementers that if they get in a situa= tion where, for example, RLQ cannot be calculated (e.g. the "unknown" case)= , then simply don't send the TLV.=20 >=20 > Regards, > Stan >=20 From teco@inf-net.nl Thu Oct 11 09:07:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402F921F850D for ; Thu, 11 Oct 2012 09:07:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez7yaFtCpv7K for ; Thu, 11 Oct 2012 09:07:27 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCCF21F8508 for ; Thu, 11 Oct 2012 09:07:26 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so374825eaa.31 for ; Thu, 11 Oct 2012 09:07:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=l81/Rs+96riWpeCuIcBPhMfm+HuiW+3v3z6lDRGGvQk=; b=UDlZ7MPex9hPIrCqCvUQUygr/SiqWKIN3wR0VZpJY8ISgwQLm3lFhsRW+ZTWZwWMzL QSp2jKkHWYGFyiAmLyRg9GtJB1fztzLjrPSjhrQzcgEqypYw9MC2SXv67hbxJIYhaYmJ O8mTtC79NIJYFk1l0hUOjm4nrfDr+YPIRULuqsEEQswp4lkeIVowXQspSbsa2ijFa1U1 6/nZQxigMgxxfhl1q0RTZKMB1TYClE39UBTrrmwDlGlda/KVPducagA65fvBN1XvTRk1 x3Dgz2KNjfHHkO1pi1fGwIwFy40QNiSr4CRA6AuDx/hSND9nxwa1QsYrknY3OTtzL12q q2EQ== Received: by 10.14.193.136 with SMTP id k8mr2417205een.30.1349971645644; Thu, 11 Oct 2012 09:07:25 -0700 (PDT) Received: from [172.16.4.172] ([188.205.88.52]) by mx.google.com with ESMTPS id i1sm7533027eeo.8.2012.10.11.09.07.23 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 09:07:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> Date: Thu, 11 Oct 2012 18:07:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlZdKK8+zwEZlZjGyxJy7z5UvdYEm2o+fFyXMT+BA114fDsau1/QImcBO2j/aOOnOblB4YZ Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 16:07:29 -0000 Op 11 okt. 2012, om 17:24 heeft Stan Ratliff (sratliff) het volgende = geschreven: > Again, my objection is purely based on the fat that I don't understand = how/where/when/why this would be used. It's hard to insert even generic, = "hand-waving" level text on something without at least having some = notion of why it would be used. I keep asking for suggested text to = explain, and I don't get a response. So, IF we get consensus on = "unknown", my proposed text is:=20 >=20 > "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where = RLQ is supported, but not currently calculable. The authors have no idea = under what circumstances this would occur. Routers receiving a value of = RLQ_UNKNOWN are free to take any action deemed appropriate, including = (but not limited to) ignoring the value, producing log messages, or = bursting into flames. The RLQ_UNKNOWN (TBD) value was added at the = request of the working group, as consensus formed around the key ideas = that this MAY allow for innovation, even though none of the working = group members were able to note a set of circumstances under which this = innovation might take place. So, in an effort to stop the email storm, = the authors added the additional code point." I did read more useful descriptions having the RLQ_UNKNOWN. If a radio = did send something, but want to revoke it, there must be a mechanism for = such. Without, the protocol is not complete. With TLV, we can have Length=3D0. IMHO a better choice than RLQ_UNKNOWN. Teco >=20 >=20 >=20 > Stan >=20 > On Oct 11, 2012, at 10:43 AM, Duke, Martin wrote: >=20 >> I don't understand the objection that we don't know yet what to do = with code UNKNOWN. My understanding of the DLEP draft is it provides a = way for radios to present information to the routers and routers to send = requests to radios, and does not cover what the router does with those = reports. It's entirely reasonable for the radio to throw out RLQ or = latency reports because traffic doesn't care much about either. >>=20 >> It seems to odd to create an ambiguity for one particular codepoint = that represents both an acceptable value (e.g., 100 or 0) and an unknown = value. I agree that simply omitting the TLV is adequate, except in cases = when the metric transitions from a known state to an unknown one. I = think this is a corner case, but a corner case that's low-cost to = resolve. Why not give as much information as possible to the router and = let the smart guys who build routers figure out what they can do with = it? >>=20 >> To be clear, I'm not trying to disallow the case that radios with no = measurement simply omit the TLV. >>=20 >> Martin=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Stan Ratliff (sratliff) >> Sent: Thursday, October 11, 2012 7:06 AM >> To: Powell III, Nelson >> Cc: manet@ietf.org; Bo Berry (boberry) >> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >> I've read the thread, trying to catch-up on the conversation. To be = honest, I'm not sure where we're at, presently.=20 >>=20 >> I think there's consensus around making RLQ (and Latency, and = Resources) OPTIONAL TLVs. As to reserving a code point for an RLQ value = of "unknown", I don't think we have consensus. I for one am at a = complete loss trying to understand the circumstances under which a = router would get an "unknown" value, and what the router would actually = do with it (other than ignore and discard it). Lastly, I'm still going = to need someone to suggest some text as to how we explain this in the = draft, to avoid the obvious questions after publication.=20 >>=20 >> My position (FWIW) is that we make RLQ, Resources, and Latency = optional, and put some text in explaining to implementers that if they = get in a situation where, for example, RLQ cannot be calculated (e.g. = the "unknown" case), then simply don't send the TLV.=20 >>=20 >> Regards, >> Stan >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Oct 11 10:41:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27121F8712 for ; Thu, 11 Oct 2012 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StgjkCMT8-Zl for ; Thu, 11 Oct 2012 10:41:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 790D821F8710 for ; Thu, 11 Oct 2012 10:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4659; q=dns/txt; s=iport; t=1349977295; x=1351186895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=07wHal18UaxV4OATixyRzHO8iPv2rgJSPIzC3oaEUVk=; b=TmapUUWuoruHQlA2F1wRbLN+vZeD1X+rZ2vEB06ZKbwkDMQI7kOLuHqT OAoCZ7OLQRC7kYgjs8KMEgGaW4P80WZ3VHGW95+dBTXqg8dun3s8+oU61 9wUhWjYJJpYNcdh330fvGqmFq6lx2XGLSHyJkVZRNonbejCnpqWfdsnWa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAIEd1CtJV2c/2dsb2JhbABEv1SBCIIgAQEBAwEBAQEPASc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCBqHXAYLmU6gJQSLRxSFLGADpDKBa4JtgVoJGBw X-IronPort-AV: E=Sophos;i="4.80,573,1344211200"; d="scan'208";a="130677219" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 11 Oct 2012 17:41:34 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9BHfZ5o001636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 17:41:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 12:41:35 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgA== Date: Thu, 11 Oct 2012 17:41:35 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--50.975500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:41:37 -0000 On Oct 11, 2012, at 12:07 PM, Teco Boot wrote: >=20 > Op 11 okt. 2012, om 17:24 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >=20 >> Again, my objection is purely based on the fat that I don't understand h= ow/where/when/why this would be used. It's hard to insert even generic, "ha= nd-waving" level text on something without at least having some notion of w= hy it would be used. I keep asking for suggested text to explain, and I don= 't get a response. So, IF we get consensus on "unknown", my proposed text i= s:=20 >>=20 >> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ = is supported, but not currently calculable. The authors have no idea under = what circumstances this would occur. Routers receiving a value of RLQ_UNKNO= WN are free to take any action deemed appropriate, including (but not limit= ed to) ignoring the value, producing log messages, or bursting into flames.= The RLQ_UNKNOWN (TBD) value was added at the request of the working group,= as consensus formed around the key ideas that this MAY allow for innovatio= n, even though none of the working group members were able to note a set of= circumstances under which this innovation might take place. So, in an effo= rt to stop the email storm, the authors added the additional code point." >=20 > I did read more useful descriptions having the RLQ_UNKNOWN. If a radio di= d send something, but want to revoke it, there must be a mechanism for such= . Without, the protocol is not complete. >=20 > With TLV, we can have Length=3D0. IMHO a better choice than RLQ_UNKNOWN. >=20 > Teco My apologies for begin frustrated. It's simply that I'm in the position of = documenting something that I don't understand. That makes it fairly difficu= lt to explain. So, basically what I'm saying is "Tell me what you want this= to say. I'll cut and paste your text into the document." Regards, Stan >=20 >>=20 >>=20 >>=20 >> Stan >>=20 >> On Oct 11, 2012, at 10:43 AM, Duke, Martin wrote: >>=20 >>> I don't understand the objection that we don't know yet what to do with= code UNKNOWN. My understanding of the DLEP draft is it provides a way for = radios to present information to the routers and routers to send requests t= o radios, and does not cover what the router does with those reports. It's = entirely reasonable for the radio to throw out RLQ or latency reports becau= se traffic doesn't care much about either. >>>=20 >>> It seems to odd to create an ambiguity for one particular codepoint tha= t represents both an acceptable value (e.g., 100 or 0) and an unknown value= . I agree that simply omitting the TLV is adequate, except in cases when th= e metric transitions from a known state to an unknown one. I think this is = a corner case, but a corner case that's low-cost to resolve. Why not give a= s much information as possible to the router and let the smart guys who bui= ld routers figure out what they can do with it? >>>=20 >>> To be clear, I'm not trying to disallow the case that radios with no me= asurement simply omit the TLV. >>>=20 >>> Martin=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Stan Ratliff (sratliff) >>> Sent: Thursday, October 11, 2012 7:06 AM >>> To: Powell III, Nelson >>> Cc: manet@ietf.org; Bo Berry (boberry) >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>> I've read the thread, trying to catch-up on the conversation. To be hon= est, I'm not sure where we're at, presently.=20 >>>=20 >>> I think there's consensus around making RLQ (and Latency, and Resources= ) OPTIONAL TLVs. As to reserving a code point for an RLQ value of "unknown"= , I don't think we have consensus. I for one am at a complete loss trying t= o understand the circumstances under which a router would get an "unknown" = value, and what the router would actually do with it (other than ignore and= discard it). Lastly, I'm still going to need someone to suggest some text = as to how we explain this in the draft, to avoid the obvious questions afte= r publication.=20 >>>=20 >>> My position (FWIW) is that we make RLQ, Resources, and Latency optional= , and put some text in explaining to implementers that if they get in a sit= uation where, for example, RLQ cannot be calculated (e.g. the "unknown" cas= e), then simply don't send the TLV.=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Thu Oct 11 10:54:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2ED21F8703 for ; Thu, 11 Oct 2012 10:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe7o75L9wEzG for ; Thu, 11 Oct 2012 10:54:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7A37821F8700 for ; Thu, 11 Oct 2012 10:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=161; q=dns/txt; s=iport; t=1349978052; x=1351187652; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yfI7RLTLxvR9IhKajkMTb9qbTnrzPOvSH3AJMG1mU9w=; b=kKquw2FBc/mIe+ctjpfWUSbp73/RSvTSWOaqmDEAL7oPYY3EGRXE1rWD fxvO14fVrPYCtpy9MDDFls+dh5wJCfGrt+2sYt3CmcDuFa/LIVvyOUI9O 7lq/T2IqZZPaoKltxCNA13/ipTAPW5DZRoS8kBRfD4QjsqH6FWNIDevLb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP4Gd1CtJXHA/2dsb2JhbABEv1SBCIIhAQEEEgEnTwIBKhQQMiUCBBsah2KZVaAri0eFQGADpDKBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,573,1344211200"; d="scan'208";a="130715717" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 11 Oct 2012 17:54:09 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9BHs9f2015915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Oct 2012 17:54:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 12:54:08 -0500 From: "Stan Ratliff (sratliff)" To: "manet@ietf.org List" Thread-Topic: WGLC on draft-ietf-manet-olsrv2-metrics-rationale-01 Thread-Index: AQHNp9lpfpiKLNzD3U2J2QiY5eOHTA== Date: Thu, 11 Oct 2012 17:54:08 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4046CD@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--26.396700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <6FEDE8ADAE3E0F4E9D58FB77EE1558B5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] WGLC on draft-ietf-manet-olsrv2-metrics-rationale-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:54:13 -0000 The above mentioned draft has been moved to Last Call status. This document= has a 2-week last call period, ending on October 25, 2012.=20 Regards, Stan= From ulrich@herberg.name Thu Oct 11 11:15:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FC021F86C2 for ; Thu, 11 Oct 2012 11:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnDCkzMNYjhR for ; Thu, 11 Oct 2012 11:15:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1021F86B5 for ; Thu, 11 Oct 2012 11:15:29 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2389065vbb.31 for ; Thu, 11 Oct 2012 11:15:29 -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=j3JjpaYJUZivCNBSMNOuht6TsKVM22QZdFbmkFtWVqg=; b=NYr7h1I5Z07fa3+zgJyJCzHaen8VO/0u4MJ98GBMdDvCxAKWErXHFnbtItkuZ6COcY k0iOnNMVyb/q8ynf0+LTBVj78jQ7771uSmJ6OUoaqJIcnNzxnMK5tVLOwH4Ch7/a6luG GpTmSRYEqD25S96l5ObrN7i597YvtbXdkNEcw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=j3JjpaYJUZivCNBSMNOuht6TsKVM22QZdFbmkFtWVqg=; b=lspdSjUXqOAbB0j+C3KxifvVuxh9q6KKuFeUDdM3RcxJABzmFY1FZbLqlr2aMqQSKx rYzhzfvDcXUUMDXkNsIlHNwbWFvaZkm9Pq6TAFWH0teDTopwmYG2mAClZcDV151YbNCW x29Z45pcqELR/kz6jytvIgKWRRuEc5vPoIBOgG1QSBqtv16uH0BNpKX11VNeCCDAcywa R+eM7VLA09o0TTnW13xsNjEUWi0UhCh6bC/klHhhAVw/eiNawfYQQHjUqM47Tj63rLF/ PuOI0VhH+oeWoOg9AKne1UKVHHutwv1HPWhjmGtlfkpkTSadLC+/DbtleiDc6tnCUsGv 7gqw== MIME-Version: 1.0 Received: by 10.58.32.234 with SMTP id m10mr946750vei.60.1349979329361; Thu, 11 Oct 2012 11:15:29 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 11 Oct 2012 11:15:29 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4046CD@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4046CD@xmb-aln-x03.cisco.com> Date: Thu, 11 Oct 2012 11:15:29 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7b2ee4cb6178f704cbcc8ed6 X-Gm-Message-State: ALoCoQmdcMCfrvWSG+QgqB7MKoBISXi4z7HJaajN5mmhr4I7yGhVeVh+XSJHSnE2QivzD7gygSY/ Cc: "manet@ietf.org List" Subject: Re: [manet] WGLC on draft-ietf-manet-olsrv2-metrics-rationale-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:15:31 -0000 --047d7b2ee4cb6178f704cbcc8ed6 Content-Type: text/plain; charset=ISO-8859-1 I am in favor of proceeding with the publication of this document. My previous review of an earlier revision has been addressed. The document retains important rationale that should be documented by the IETF. Regards Ulrich On Thu, Oct 11, 2012 at 10:54 AM, Stan Ratliff (sratliff) < sratliff@cisco.com> wrote: > The above mentioned draft has been moved to Last Call status. This > document has a 2-week last call period, ending on October 25, 2012. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b2ee4cb6178f704cbcc8ed6 Content-Type: text/html; charset=ISO-8859-1 I am in favor of proceeding with the publication of this document. My previous review of an earlier revision has been addressed. The document retains important rationale that should be documented by the IETF.

Regards
Ulrich

On Thu, Oct 11, 2012 at 10:54 AM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:
The above mentioned draft has been moved to Last Call status. This document has a 2-week last call period, ending on October 25, 2012.

Regards,
Stan
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--047d7b2ee4cb6178f704cbcc8ed6-- From henning.rogge@fkie.fraunhofer.de Thu Oct 11 23:58:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F173521F8419 for ; Thu, 11 Oct 2012 23:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyDuJ9xSW0KO for ; Thu, 11 Oct 2012 23:58:43 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id CEBDF21F8417 for ; Thu, 11 Oct 2012 23:58:42 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMZCj-00088M-01; Fri, 12 Oct 2012 08:58:41 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMZCi-0001Mh-Td; Fri, 12 Oct 2012 08:58:40 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Oct 2012 08:58:40 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 08:58:40 +0200 Message-ID: <5077BF94.80904@fkie.fraunhofer.de> Date: Fri, 12 Oct 2012 08:58:28 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040207070708040200030708" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 12 Oct 2012 06:58:40.0738 (UTC) FILETIME=[02D6AC20:01CDA847] X-Virus-Scanned: yes (ClamAV 0.97.5/15456/Fri Oct 12 04:01:13 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2d58c557eff95fe6d1f20ba5c7a78ca3 Cc: Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 06:58:44 -0000 --------------ms040207070708040200030708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/11/2012 07:41 PM, Stan Ratliff (sratliff) wrote: > My apologies for begin frustrated. It's simply that I'm in the > position of documenting something that I don't understand. That makes > it fairly difficult to explain. So, basically what I'm saying is > "Tell me what you want this to say. I'll cut and paste your text into > the document." Do you think you are the only one? I thought we had a rough consensus with the "drop the RLQ TLV if you=20 cannot measure the RLQ". But then people began to argue "not supporting RLQ is different from=20 incalculable RLQ". Thats what lead to the suggestion of the=20 255=3Dincalculable codepoint. Some time later we got the argument that the radio still wants to push=20 its "guessed" RLQ, even when it cannot calculate it. I talked with a=20 co-worker and he suggested using an additional bit/byte as a flag, so we = can support both use-cases (radio can always suggest RLQ, but mark it as = 'not measured' if necessary). But that was "too complex". I do not care which of the three solutions we take. I just want a way to penalize links that have not been measured. Because = non-measurable links (especially with "perfect link quality") degrade=20 the routing metric to hopcount, which can be a disaster for adhoc network= s. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040207070708040200030708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTIwNjU4MzhaMCMGCSqGSIb3DQEJBDEWBBR0o0VZnWwqt/8cHs94vVJrcdY1SjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAfc/q8wBhPSGz6Va3soa4NoEUb+BaYO2tFvecAkHb+M/w aUSlj9pUZ+/QrYulHDQZ63ur60F80pWRFJ2Hw1ayka4yRBhD2o3KisDajTl8Qahez1NdagOV DZFOPQVe+K0Tbz7s/Om6cLJ8HQuRGthKEvKEdNYI+7eZC5/V5gvK72+UauFUjSIi27jJBzzr lTVDGDEpii5XVsiRoDDgiKXcLAtEosmeI7TEEK++kwm7R4vE8QGEMVZSZpOIuZ4cpQ/sCPAe Gx7BtCd6j9v/ezhJHOhFP5YkLTG7EFPRU3a8Suoxdc8J9XyCXbDjoB0HnaZDnLisj100h0nO xXg4sJymuAAAAAAAAA== --------------ms040207070708040200030708-- From teco@inf-net.nl Fri Oct 12 00:20:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E62D21F84C5 for ; Fri, 12 Oct 2012 00:20:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgoqBzH6g1+J for ; Fri, 12 Oct 2012 00:20:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E93421F84A2 for ; Fri, 12 Oct 2012 00:20:40 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1744405eek.31 for ; Fri, 12 Oct 2012 00:20:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=avXnUhObtPur+mSFrdHp6YKfrOSjs+pTsWK+4M0bEvk=; b=VBKxO1pGF+wyQKhiL+vnA7G7LCpGZiDADyZuxsk1ElSK2Qhk0Zt+pPKsythtZ5X/B+ wBapAM/b4DHQOdcyAp5Vr1k2yB7gKIxAQSBcZ048AFVcstmgJkLsUreWNQu0KiOkkH0q V73DWuLMKTV1Uo9dQbkGFvgShpicM21oIZN6m5DC7HeC51OtG2O7dF5WPtduZ8ddtUX8 taLBa1toTde/eX3C5LfKmEWrz5pnR6X+cQaxvs0fArdZdV54YJ0eM0NdWosaqduTICME K68llNpXb6nhdxVIWBhj9FgB7oJ+xQgePwFS+0PtR18/KMCOTwQvKhSCYR/YrYFwyIyR XUZw== Received: by 10.14.224.135 with SMTP id x7mr5512748eep.34.1350026439772; Fri, 12 Oct 2012 00:20:39 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:14d9:a372:33ba:46a2? ([2001:470:7a9b:1:14d9:a372:33ba:46a2]) by mx.google.com with ESMTPS id i1sm10228352eeo.8.2012.10.12.00.20.38 (version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 00:20:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> Date: Fri, 12 Oct 2012 09:20:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm3dAQGZz2BzlaX55odG0Zrg0rltuGSFpp0AgbDnJ7Cb1X0MX0X3MPGcjyAw0KzmG146LsZ Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 07:20:42 -0000 Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>> It's hard to insert even generic, "hand-waving" level text .... > So, basically what I'm saying is "Tell me what you want this to say. = I'll cut and paste your text into the document." The UNKNOWN condition does not apply to RLQ only. Resources is somewhat = equivalent. In fact all TLVs can be unknown, just after Neighbor Up and = no optional TLVs, and no info from peer. Also, the protocol is not = complete if there is no way to get back to a previous state of the = information base. I straightforward solution is to have a method to revoke everything that = is send before. Length=3D0 or the existing drop indicator. Text would = be: Length - (the value for TLV with info) A zero length can be used to revoke previous provided = information for this Data Item TLV. This could also be used to override the peer provided defaults. Teco From abdussalambaryun@gmail.com Fri Oct 12 00:54:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D5221F84F0 for ; Fri, 12 Oct 2012 00:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW57475Q6Wcc for ; Fri, 12 Oct 2012 00:54:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB1221F84BF for ; Fri, 12 Oct 2012 00:54:01 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3055444vbb.31 for ; Fri, 12 Oct 2012 00:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fbfGpOKpt+0dElii7y4/beJk6hKPPTPE4/AAxRml4L0=; b=yHlZ+7TNvfGXhz7XNfjleBKqgjvIDxV6MCwS7L5204MFKN7aTJ8iqI7nppkCsLeLZV XT36CnIcswIeYi7xzECykKK2kO6igaLzpC9skg3oF2qgR87pvSH01kXa+bKYnWl+/eVq GCAKFtYmzgybqUYKfqjEcS+oxpn/w/MwWaDmTjgScnTjwqWw/ousaUQKtutid5S47bv4 moH0hF7Hnzp7ijhK5S+us/QjrFgUC6MoVYUMbqpzJ8/BOGCyJfic+xlJHUqSXYalq1TY 3ZoGCZPbjy33utVsW1iERCIpmcbSRXP4pm7EtEWvROIEd9735v+WlPkPvC73LKCBm5RO HzcA== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr2116642vca.14.1350028440043; Fri, 12 Oct 2012 00:54:00 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 00:53:59 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4046CD@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4046CD@xmb-aln-x03.cisco.com> Date: Fri, 12 Oct 2012 09:53:59 +0200 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org List" Subject: Re: [manet] WGLC on draft-ietf-manet-olsrv2-metrics-rationale-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 07:54:02 -0000 +1 It is an excellent draft/work, I support the draft and your process. Thanks to all: authors, you and the WG, AB On 10/11/12, Stan Ratliff (sratliff) wrote: > The above mentioned draft has been moved to Last Call status. This document > has a 2-week last call period, ending on October 25, 2012. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Fri Oct 12 00:56:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2618121F84E7 for ; Fri, 12 Oct 2012 00:56:47 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqK9mu60IKAU for ; Fri, 12 Oct 2012 00:56:46 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2579621F84BF for ; Fri, 12 Oct 2012 00:56:45 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1699005wey.31 for ; Fri, 12 Oct 2012 00:56:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JUbsE/ZiRYD/xLkDdswz2KK23hkEBw2BtCiwnB+CSQ4=; b=n9aXdCjpWMCHwLqUX/kcY8ra0G5l3TuOGRf3s46TxTTokXuOcb2z7SVVuTtuvplOG3 XnTP6zkyB1aRDnme7ZDyjHO2SUzqlr0kKWYIlyc61WD1ZKFJtiDTN9xsqzOzq2LDaCnn KK+6j6SUiOPSo/CyirN2yl1F32VlxQ5VYe6i8CuZqxJbvF9Au7rXeOJPx9GxlXaDJZDw 3u/X5Ebla9iS6Xa5wp5DOQXOWyeEjNxeYUteJZxbbHV1zXPNvyhcGSBxLM9cbMH/42SQ fbIuoBSQuhGDxLF9fWnugN5m3b4smul+eonIu/Oe8+EEJI9ZTdS93I0QaThjSXErcYhJ Mriw== Received: by 10.216.209.40 with SMTP id r40mr2171597weo.144.1350028605263; Fri, 12 Oct 2012 00:56:45 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id cn6sm2303041wib.9.2012.10.12.00.56.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 00:56:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Teco Boot In-Reply-To: <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> Date: Fri, 12 Oct 2012 09:56:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C0DD756-036C-4A59-8960-B00F42FD212A@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> To: " List" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmiv4knsvyGFxfwjNySXledfNMAVDNh6ktoJ0x1HpZqmjIM91JT342S/3w8joV+lqMF147l Subject: [manet] Another comment on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 07:56:47 -0000 Another somewhat old discussion on DLEP (August 11th 2010): >>>>>>>>> Another topic is the choice on which side of a link gets what = information. >>>>>>>>> Draft-dearlove-olsrv2-metrics proposes the routing protocol = instance gets >>>>>>>>> the L2 metrics for incoming side of links, OLSR/NHDP take care = of metric >>>>>>>>> transfer to TC originator. Other protocols work otherwise (e.g = the >>>>>>>>> OSPF-MANET family). There, in case of asymmetric metrics, it = is assumed that >>>>>>>>> the radios would run another (L2 or L3) protocol for metric = transfer, if >>>>>>>>> needed. Are asymmetric metrics supported, and if so, what = model is proposed? >>>>>>=20 >>>>>> I believe the DLEP draft would support asymmetric links -- at = least links where bi-directional connectivity exists, though potentially = at different speeds. This is analogous to RFC 5778 operation. In RFC = 5778, each side of a connection gets metrics that represent the ability = of that side to send to the partner. If one side runs at a slower speed = than the other, different "send metrics" are reported to the respective = routers. >>>>>=20 >>>>> I think it is important to specify the semantics of the provided = metrics. For what direction does this data apply? >>>>> OSPF-MANET and OLSR have different requirements here: OSPF = requires outbound direction, OLSR inbound. >>>>> Maybe DLEP could support both models, and mode is negotiated. >>>>>=20 >>>>=20 >>>> OK, what if we changed the metric packet to include both inbound = and outbound bandwidth? That way, no negotiation would be required, and = the routing protocol could select the data it needs. >>> If information is available, it can be provided without high costs. >>> If it is optionally available, e.g. it requires transfer over the = radio, it should be made available only if needed. >>> This can be configuration or negotiation.=20 >>>=20 >>> It is not only bandwidth, it applies to other metrics also. Maybe = the whole set.=20 >>=20 >> I'm OK with this. Are there other opinions on the list? >=20 > Look in the IEEE 802.16 specification. Table 14 (in Chapter 6 of the > -2004 version I have) contains the roughly four dozen MAC messages = that > control the network segment. Many of the variables trafficked here = are > reflected one way or another in the MIB. =20 >=20 > Is not what your asking for is some way to reflect some of this data = up > to layer 3? I don't think the draft was updated to reflect the outcome of this = discussion. @Stan: is there a follow-up? Teco= From abdussalambaryun@gmail.com Fri Oct 12 01:00:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E6A21F850B for ; Fri, 12 Oct 2012 01:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAnelDrRijQE for ; Fri, 12 Oct 2012 01:00:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 095CA21F8501 for ; Fri, 12 Oct 2012 01:00:23 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3061093vbb.31 for ; Fri, 12 Oct 2012 01:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HJpNUoZQjBkJJAiUifqSVCwLoSEI8Hcpttv5Ui1OPhQ=; b=LZNFG9cZi46l1ntjbNtcaQCYJZGr5pZUW3lCZ6v6R+7VtRw/h+ayIwgKbrzcD6VkAq 7DXVLryPE2orGWGSJZXabRdmHxr9oWkXaHa9vJ79tPsVE114CoZ94TUpPcnABC1/JOjz +j4gkTrjijhgeTHKBaKTFManWh1Z4dCI7bVdSP0eJkqtyyZxZb1iioXjWsX4ptpK4Udx vU56zHKbh9vds7O1yCCzrTJmlYV/aplGqdcGIior4Pzgab7yEZVFb60YYu5WGg37cxAW pm1DiIh1sL/l/njio4X6/zi/e3vvKuoDcq5CKNDEjmaXRIZasup6umgHM489M+r+hlLI dzWA== MIME-Version: 1.0 Received: by 10.220.240.135 with SMTP id la7mr2079259vcb.44.1350028823180; Fri, 12 Oct 2012 01:00:23 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 01:00:22 -0700 (PDT) In-Reply-To: <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> Date: Fri, 12 Oct 2012 10:00:22 +0200 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 08:00:25 -0000 +1 AB On 10/12/12, Teco Boot wrote: > Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het volgende > geschreven: > >>>> It's hard to insert even generic, "hand-waving" level text > .... >> So, basically what I'm saying is "Tell me what you want this to say. I'll >> cut and paste your text into the document." > > > The UNKNOWN condition does not apply to RLQ only. Resources is somewhat > equivalent. In fact all TLVs can be unknown, just after Neighbor Up and no > optional TLVs, and no info from peer. Also, the protocol is not complete if > there is no way to get back to a previous state of the information base. > I straightforward solution is to have a method to revoke everything that is > send before. Length=0 or the existing drop indicator. Text would be: > > Length - (the value for TLV with info) > A zero length can be used to revoke previous provided > information for this Data Item TLV. > > This could also be used to override the peer provided defaults. > > Teco > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Oct 12 01:04:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4873121F8527 for ; Fri, 12 Oct 2012 01:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-6MpS6FkWXI for ; Fri, 12 Oct 2012 01:04:31 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 767E121F8525 for ; Fri, 12 Oct 2012 01:04:31 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3532875vcb.31 for ; Fri, 12 Oct 2012 01:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mWOq/R12v1Ve8Dz8xdty/G+y7CzIr/GzO1YxfMRSQIo=; b=G7hI6EUm5GpwfW37G+MtgdaPEtoyqLKXTb7Qcdgw2nSVNJLdXxeOo3wu6r5LYWndyZ aw+vP6iwSBfN2y4/aT4ILNHlzpCumDtDMeN/TDx51js4ovgVFuqWwxQ1e65sBuBcuWD9 6qaYyx2z9X1wxi71GaxCoJn01dNA3Tldx7PkKs0QVsKVH89qcG/oL92YGV/CF0wku7pA FA8Xw4PUs11lpBYi7hduPKeYvT5o+ZrTPX3QmyY4jASCtFngrQgHO90Qm3l2JEWHoAp+ wyNTk5U5h+YiOYYg/xIeNhLwnCYjGtAiIZ7ZFJrqbX6C0IFQDPhYKfAOvxCpCoRv98A1 n/VQ== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr1744991vdi.55.1350029070730; Fri, 12 Oct 2012 01:04:30 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 01:04:30 -0700 (PDT) In-Reply-To: <2C0DD756-036C-4A59-8960-B00F42FD212A@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2C0DD756-036C-4A59-8960-B00F42FD212A@inf-net.nl> Date: Fri, 12 Oct 2012 10:04:30 +0200 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] Another comment on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 08:04:32 -0000 Thanks for this reminder, I think there is no much follow up, because many say they are bussy with other work, but I recommend we all follow up together for the best of our WG drafts. I remember giving some feedback on dlep but not put in as well, however, always reminders are important :) AB On 10/12/12, Teco Boot wrote: > Another somewhat old discussion on DLEP (August 11th 2010): > >>>>>>>>>> Another topic is the choice on which side of a link gets what >>>>>>>>>> information. >>>>>>>>>> Draft-dearlove-olsrv2-metrics proposes the routing protocol >>>>>>>>>> instance gets >>>>>>>>>> the L2 metrics for incoming side of links, OLSR/NHDP take care of >>>>>>>>>> metric >>>>>>>>>> transfer to TC originator. Other protocols work otherwise (e.g >>>>>>>>>> the >>>>>>>>>> OSPF-MANET family). There, in case of asymmetric metrics, it is >>>>>>>>>> assumed that >>>>>>>>>> the radios would run another (L2 or L3) protocol for metric >>>>>>>>>> transfer, if >>>>>>>>>> needed. Are asymmetric metrics supported, and if so, what model is >>>>>>>>>> proposed? >>>>>>> >>>>>>> I believe the DLEP draft would support asymmetric links -- at least >>>>>>> links where bi-directional connectivity exists, though potentially at >>>>>>> different speeds. This is analogous to RFC 5778 operation. In RFC >>>>>>> 5778, each side of a connection gets metrics that represent the >>>>>>> ability of that side to send to the partner. If one side runs at a >>>>>>> slower speed than the other, different "send metrics" are reported to >>>>>>> the respective routers. >>>>>> >>>>>> I think it is important to specify the semantics of the provided >>>>>> metrics. For what direction does this data apply? >>>>>> OSPF-MANET and OLSR have different requirements here: OSPF requires >>>>>> outbound direction, OLSR inbound. >>>>>> Maybe DLEP could support both models, and mode is negotiated. >>>>>> >>>>> >>>>> OK, what if we changed the metric packet to include both inbound and >>>>> outbound bandwidth? That way, no negotiation would be required, and the >>>>> routing protocol could select the data it needs. >>>> If information is available, it can be provided without high costs. >>>> If it is optionally available, e.g. it requires transfer over the radio, >>>> it should be made available only if needed. >>>> This can be configuration or negotiation. >>>> >>>> It is not only bandwidth, it applies to other metrics also. Maybe the >>>> whole set. >>> >>> I'm OK with this. Are there other opinions on the list? >> >> Look in the IEEE 802.16 specification. Table 14 (in Chapter 6 of the >> -2004 version I have) contains the roughly four dozen MAC messages that >> control the network segment. Many of the variables trafficked here are >> reflected one way or another in the MIB. >> >> Is not what your asking for is some way to reflect some of this data up >> to layer 3? > > I don't think the draft was updated to reflect the outcome of this > discussion. > @Stan: is there a follow-up? > > Teco > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From henning.rogge@fkie.fraunhofer.de Fri Oct 12 01:09:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C7D21F84FE for ; Fri, 12 Oct 2012 01:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LosNTUUoNMMe for ; Fri, 12 Oct 2012 01:09:33 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id ADF9021F8441 for ; Fri, 12 Oct 2012 01:09:32 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMaJH-0006Iu-NN for manet@ietf.org; Fri, 12 Oct 2012 10:09:31 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TMaJH-0003Fo-Kl for manet@ietf.org; Fri, 12 Oct 2012 10:09:31 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Oct 2012 10:09:31 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 10:09:31 +0200 Message-ID: <5077D036.6080209@fkie.fraunhofer.de> Date: Fri, 12 Oct 2012 10:09:26 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4046CD@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070704070304060202080303" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 12 Oct 2012 08:09:31.0453 (UTC) FILETIME=[E8764ED0:01CDA850] X-Virus-Scanned: yes (ClamAV 0.97.5/15456/Fri Oct 12 04:01:13 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 44205366898805df1de72924aa95b600 Subject: Re: [manet] WGLC on draft-ietf-manet-olsrv2-metrics-rationale-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 08:09:33 -0000 --------------ms070704070304060202080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/12/2012 09:53 AM, Abdussalam Baryun wrote: > +1 > > It is an excellent draft/work, I support the draft and your process. > Thanks to all: authors, you and the WG, The document will be a great help as a pointer for people who still=20 arguing the use of link metrics. Good to see it here. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070704070304060202080303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTIwODA5MjlaMCMGCSqGSIb3DQEJBDEWBBQnBfJNz4qX0Whk3vDPlVAWYHzhBTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAnNNbZdixDOCeqsHkFFHhaW4BSYDenHsau70qCZc9Zvol V6Jc3GM/OwjgSTx9y7QXztJ/Jc+ZibJGYWqGgwptUaqcAu2R7y2DLfQa3Rsz8pUTGdIMnACf pkg73sj628rMrGSWGXDT7xMMW4kpvpnS0NcmziudYfbOvy1w4N+f6yNNha4+H8mfbj+usIV0 Yme1vUTj3PBZyDNpdgPnpfhy7XNXjT/ngb32/bwTqaYEB84Cm4U0pBi2YNRwxzRqeR3Liqpy cL5OVDFuv9r6vAMP+0K9iuwn7H0kCGprb+otxTvjNMV2xkMIp7/bsIiPyoQ8aTo7eD1EBTb9 kJG+D8JnjgAAAAAAAA== --------------ms070704070304060202080303-- From christoph.barz@gmail.com Fri Oct 12 02:21:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1264021F8491 for ; Fri, 12 Oct 2012 02:21:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au6+7lob7dQa for ; Fri, 12 Oct 2012 02:21:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D904B21F8425 for ; Fri, 12 Oct 2012 02:21:09 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3136612vbb.31 for ; Fri, 12 Oct 2012 02:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ZFhrBFoo/qxghpfOkyGOeDG3ToOvRR2sh18BPBOOJwY=; b=FF3XXshEYHx3EjGE5zLUAn/FE0V1GBdJTpzUbBY2BJy6YJZpmpsVluApitbSsjhVT2 Jf4uw5VrE9TMXWZovD4+bPezNoJ6d0YCW5IvXma2k2py/YlS8uPLe9M0Zt/Oxc8Ma5xi 8mG9NgfREXUxZYgh52auqoR+8/g89LggXYN3Zqzn7VGV23JgWpbYambu4+GO0ODoCKYT 50/vdtZ+I9uu7d2XjkqzDvLM8U7MdnKPTv+/jW8POAUXQ6iHrM8X9v2t7EFL9BAtmMDt yFQEk/HxtZafmIWWlKK0jAFR8PqR8kDyhnRk0CZGCGhdz3v5/35Rqtn/O/M5vZs5tMjz Fkzw== MIME-Version: 1.0 Received: by 10.52.34.168 with SMTP id a8mr1811570vdj.49.1350033669287; Fri, 12 Oct 2012 02:21:09 -0700 (PDT) Received: by 10.220.153.211 with HTTP; Fri, 12 Oct 2012 02:21:08 -0700 (PDT) In-Reply-To: <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> Date: Fri, 12 Oct 2012 11:21:08 +0200 Message-ID: From: Christoph Barz To: "Powell III, Nelson" , manet@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:21:11 -0000 Dear Nelson, > > I would rather the radio be able to inform the router that it cannot prov= ide an RLQ and never send that TLV. Could the session establishment proced= ures allow for enabling or disabling the use of TLV's like LCP does for PPP= connections? +1 If we want to got towards a session oriented approch, having the radio and router exchange their capabilities could make many things easier. This would not only include enabling or disabling TLVs. It could also include other protocol mechanisms like acknowledgements. In the end, it could also help regarding problem diagnosis and to identify supported features regarding special radio and router combinations. Best regards Christoph > Nelson > > -----Original Message----- > From: Bo Berry [mailto:boberry@cisco.com] > Sent: Thursday, October 11, 2012 8:36 AM > To: Henning Rogge > Cc: manet@ietf.org; Powell III, Nelson > Subject: Re: [manet] Some comments on manet-dlep-03 > > > On Oct 11, 2012, at 8:29 AM, Henning Rogge wrote: > >> On 10/11/2012 02:25 PM, Bo Berry wrote: >>>> I hope I do not misinterpret you, but I will try to summarize the >>>> two positions. >>>> >>>> First, some radios want to publish an RLQ value, even when their >>>> algorithm couldn't measure one. This might make sense, depending on >>>> the method how the RLQ is calculated and how the linklayer works. >>>> >>>> Second, some routers want to decide for themselves how they handle >>>> links with a RLQ which the radio cannot measure. >>>> >>>> Maybe we can decouple this two things to get a good compromise (I >>>> think it was already proposed yesterday): >>>> >>>> We allow the radio to publish any kind of RLQ it wants (even when >>>> incalculable), but we add a second byte (or just a bit?) information >>>> to the RLQ TLV, which contains a flag that tells the router if the >>>> RLQ value was measured or not. >>>> >>>> With this the radio is able to suggest an RLQ value for unmeasurable >>>> links, but its still the routers implementation decision if the >>>> router accepts this value or not. >>>> >>>> Do you think that could fit to both suggested use-cases? >>> >>> Why? Don't see the value. Just define the TLV as optional. I do not >>> think we need to start defining flags. >>> >>> I do not think we want to mandate a TLV transfer from a resource >>> constrained (typically) radio that would indicate an unknown value. >>> While one radio may choose to generate TLVs with 100 or with >>> 'unknown', another may not. >>> >>> The same shuold be applied to the Resource TLV, optional. >>> >>> Just because the radio sends a valid metric, does not imply it will >>> be used in a routing cost. >> >> The point is that if we do as you suggest, the router will not know how = to interpret the "100" value. A protocol like DLEP should not be ambiguous = with its transmitted values, especially if the data has been available to t= he sender! > > > We can mandate the RLQ TLV and an unknown value. A radio that cannot com= pute RLQ can hard code 100. Another radio hard codes unknown. > > Or make it optional. > > Either way the router has to account for. > > Optional works for me. > > >> >> The radio does not know the need of the router, so it should not decide = if it hides the "unknown" value from the router or not. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> > > --- > We cannot solve our problems with the same thinking we used when we creat= ed them. > Albert Einstein > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Oct 12 02:34:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93921F853F for ; Fri, 12 Oct 2012 02:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LghQHg3P6d2 for ; Fri, 12 Oct 2012 02:34:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCF421F8540 for ; Fri, 12 Oct 2012 02:34:37 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3620080vcb.31 for ; Fri, 12 Oct 2012 02:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MPnoasxqP24TidLxfVJmMbjJZ2m4nylQpOjOgbkDbO4=; b=HFhcV/zX9crvbJqU0Z/vxbqZUE1gAFW2umEWyGbfvsyHj/oBv/SwOkojcPTaGGLx0j KasB0sIY0o9ZR+s5VhmycfvTK3uabo3ovvFe450eeka1pU3A/Z5Tezrh7X1bYLe9XlGh P7l9vmmhXxyQzwv6wAts6ijDznsHolLj8p5WZC61nI2sLM0pUmEqwB+u5pr1tfmDJ4cS cIvAW3dhLm7lQfZf3rdMZfzKqKdORuISeLioAsPGjtbN80uHu7qwClzIMhveMH61GmnM FaGEYHVn8i3xZcZus6gTEeDxK1DwoY0qxkvaKfrc0zImq+ibbFWXCmDwpTZ1GAIlDz1w GGvw== MIME-Version: 1.0 Received: by 10.58.252.67 with SMTP id zq3mr2297258vec.43.1350034477108; Fri, 12 Oct 2012 02:34:37 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 02:34:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Oct 2012 11:34:36 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:34:38 -0000 Please note that I strongly object any including of LOADng draft in the Agenda. The document is not for MANET, was already presented before, and the authors are not discussing on ietf lists of any progress. The draft is not reasonable for the WG, if it is not discussed on the MANET list. I got no reasonable reply to all my efforts, the last as: http://www.ietf.org/mail-archive/web/manet/current/msg13448.html AB On 10/9/12, Ulrich Herberg wrote: > Hi, > > the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. > If you intend to present something, please send a request to the chairs. > > Best regards > Ulrich > From boberry@cisco.com Fri Oct 12 04:34:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B45121F8532 for ; Fri, 12 Oct 2012 04:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48itUXgImWMu for ; Fri, 12 Oct 2012 04:34:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7647321F8530 for ; Fri, 12 Oct 2012 04:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3859; q=dns/txt; s=iport; t=1350041659; x=1351251259; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SJLNex+zTi9Ld3Kw8KKMV4dAjxpfFY6pF9svdNZDJV8=; b=fQf7XB7QtKuZA9N3U7tW/MO+hlReoZ5TdOJeyQil2kqXdC5vjCSeo2x6 rVuTNvoXJOjZkbVFDePCNhcw0wy7w2WsQ5ApXhxp74+tlNBQL3J9c25ef VZopG9+MleK/RDtGCXwiEigsg6V9sCIA1bE4+ThpLwA257tApGqHYYn+8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMb/d1CtJV2a/2dsb2JhbABEv1yBCIIgAQEBAwEBAQEPASc0AwgFCwsYLicwBgoJIodcBguZfKAKBItQhV1gA5ICg2uFYohjgWuDCQ X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130920904" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2012 11:34:19 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9CBYI7Q007882; Fri, 12 Oct 2012 11:34:18 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Fri, 12 Oct 2012 07:34:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9 D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2C0DD756-036C-4A59-8960-B00F42FD212A@inf-net.nl> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1085) Cc: " List" Subject: Re: [manet] Another comment on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:34:20 -0000 On Oct 12, 2012, at 4:04 AM, Abdussalam Baryun wrote: > Thanks for this reminder, >=20 > I think there is no much follow up, because many say they are bussy > with other work, but I recommend we all follow up together for the > best of our WG drafts. I remember giving some feedback on dlep but not > put in as well, however, always reminders are important :) Making a suggestion does not mean the suggestion is automatically added to the draft. The suggestion needs consensus and agreement.=20 >=20 > AB >=20 > On 10/12/12, Teco Boot wrote: >> Another somewhat old discussion on DLEP (August 11th 2010): >>=20 >>>>>>>>>>> Another topic is the choice on which side of a link gets = what >>>>>>>>>>> information. >>>>>>>>>>> Draft-dearlove-olsrv2-metrics proposes the routing protocol >>>>>>>>>>> instance gets >>>>>>>>>>> the L2 metrics for incoming side of links, OLSR/NHDP take = care of >>>>>>>>>>> metric >>>>>>>>>>> transfer to TC originator. Other protocols work otherwise = (e.g >>>>>>>>>>> the >>>>>>>>>>> OSPF-MANET family). There, in case of asymmetric metrics, it = is >>>>>>>>>>> assumed that >>>>>>>>>>> the radios would run another (L2 or L3) protocol for metric >>>>>>>>>>> transfer, if >>>>>>>>>>> needed. Are asymmetric metrics supported, and if so, what = model is >>>>>>>>>>> proposed? >>>>>>>>=20 >>>>>>>> I believe the DLEP draft would support asymmetric links -- at = least >>>>>>>> links where bi-directional connectivity exists, though = potentially at >>>>>>>> different speeds. This is analogous to RFC 5778 operation. In = RFC >>>>>>>> 5778, each side of a connection gets metrics that represent the >>>>>>>> ability of that side to send to the partner. If one side runs = at a >>>>>>>> slower speed than the other, different "send metrics" are = reported to >>>>>>>> the respective routers. >>>>>>>=20 >>>>>>> I think it is important to specify the semantics of the provided >>>>>>> metrics. For what direction does this data apply? >>>>>>> OSPF-MANET and OLSR have different requirements here: OSPF = requires >>>>>>> outbound direction, OLSR inbound. >>>>>>> Maybe DLEP could support both models, and mode is negotiated. >>>>>>>=20 >>>>>>=20 >>>>>> OK, what if we changed the metric packet to include both inbound = and >>>>>> outbound bandwidth? That way, no negotiation would be required, = and the >>>>>> routing protocol could select the data it needs. >>>>> If information is available, it can be provided without high = costs. >>>>> If it is optionally available, e.g. it requires transfer over the = radio, >>>>> it should be made available only if needed. >>>>> This can be configuration or negotiation. >>>>>=20 >>>>> It is not only bandwidth, it applies to other metrics also. Maybe = the >>>>> whole set. >>>>=20 >>>> I'm OK with this. Are there other opinions on the list? >>>=20 >>> Look in the IEEE 802.16 specification. Table 14 (in Chapter 6 of = the >>> -2004 version I have) contains the roughly four dozen MAC messages = that >>> control the network segment. Many of the variables trafficked here = are >>> reflected one way or another in the MIB. >>>=20 >>> Is not what your asking for is some way to reflect some of this data = up >>> to layer 3? >>=20 >> I don't think the draft was updated to reflect the outcome of this >> discussion. >> @Stan: is there a follow-up? >>=20 >> Teco >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From boberry@cisco.com Fri Oct 12 04:39:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26C21F853B for ; Fri, 12 Oct 2012 04:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT7MNJBoSEMA for ; Fri, 12 Oct 2012 04:39:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B665F21F8533 for ; Fri, 12 Oct 2012 04:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1187; q=dns/txt; s=iport; t=1350041950; x=1351251550; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=l1pfEUY5GJG9DJ44ZN7tYun5xWUo4IumC9V5K3RPFuo=; b=QY76VFNLg2vrr3DrgV36Lpv/TZRNhxsDXLjYtaSfw4h8Kv4EmImv6Xdp RZg2zHhiWDQ9NevKFMp2dwB1p8Q3aQKFEvedzVBWZzSOO/2I3a9ziijzp nYb50XFtOU/djWpuAm8h7kG0HF/flYHpZiPBNgFrXjBAdvjAyscAkIB/+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE0AeFCtJV2Z/2dsb2JhbABEv1yBCIIgAQEBAwEBAQEPASc0CwULCxguJzAGEwkZh1wGC5l8oA6LUBqFQ2ADlW2FYohjgWuDCYFH X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130922385" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 12 Oct 2012 11:39:10 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-78.cisco.com [10.81.230.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9CBd9KM000502; Fri, 12 Oct 2012 11:39:09 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Fri, 12 Oct 2012 07:39:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:39:11 -0000 I've seen a number of emails on the alias but not sure LOADng=20 has been accepted by the WG. Is LOADng asking to be a MANET WG draft? -Bo On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: > Please note that I strongly object any including of LOADng draft in = the Agenda. > The document is not for MANET, was already presented before, and the > authors are not discussing on ietf lists of any progress. The draft is > not reasonable for the WG, if it is not discussed on the MANET list. >=20 > I got no reasonable reply to all my efforts, the last as: > http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >=20 > AB > On 10/9/12, Ulrich Herberg wrote: >> Hi, >>=20 >> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in = Salon A. >> If you intend to present something, please send a request to the = chairs. >>=20 >> Best regards >> Ulrich >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From boberry@cisco.com Fri Oct 12 05:40:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C97D21F84EF for ; Fri, 12 Oct 2012 05:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwvN7w1enUaZ for ; Fri, 12 Oct 2012 05:40:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 417F021F844C for ; Fri, 12 Oct 2012 05:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2470; q=dns/txt; s=iport; t=1350045607; x=1351255207; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=vBsdZg9ohqQ5ORxfhdGjoR6gR1pOGWcbkSn3mBiJRd8=; b=Wsa7Kr43s43D9EoDxh7t/JDtpWmjcjcPMGUHnsU0NElcE5lQR4Pkr147 6aasgqUDxDYUBt6ngnS6q3M/0zUSzJM9dL9dkxw7xj4lt53zn+CqQfLo9 +15n0tRCRWnEGy/W7iU98WA5r//g2n+bYaiOkn82Hb4aGd1jvlQRJPIT4 0=; X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130975076" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 12 Oct 2012 12:40:07 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-79.cisco.com [10.81.230.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9CCe63W028592; Fri, 12 Oct 2012 12:40:06 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Bo Berry In-Reply-To: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> Date: Fri, 12 Oct 2012 08:40:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> To: Abdussalam Baryun , " List" , Bo Berry X-Mailer: Apple Mail (2.1085) Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 12:40:08 -0000 Looking at the MANET WG Documents page, LOADng is not on the list. So = until LOADng is accepted by the WG, gotta agree with Abdussalam, no need = to discuss it in the little time we have for the work we've already = accepted. How does this fit into the WG Charter? -Bo Active Internet-Drafts draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP)=09 draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the = Neighborhood Discovery Protocol=09 draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and = Timestamps For Router Admittance in NHDP=09 draft-ietf-manet-olsrv2-16 The Optimized Link State Routing = Protocol version 2 draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the = Mobile Ad Hoc Network (MANET) Routing=20 draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the = Optimized Link State Routing Protocol=20 On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: > I've seen a number of emails on the alias but not sure LOADng=20 > has been accepted by the WG. Is LOADng asking to be a MANET WG > draft? >=20 > -Bo >=20 >=20 > On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >=20 >> Please note that I strongly object any including of LOADng draft in = the Agenda. >> The document is not for MANET, was already presented before, and the >> authors are not discussing on ietf lists of any progress. The draft = is >> not reasonable for the WG, if it is not discussed on the MANET list. >>=20 >> I got no reasonable reply to all my efforts, the last as: >> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>=20 >> AB >> On 10/9/12, Ulrich Herberg wrote: >>> Hi, >>>=20 >>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in = Salon A. >>> If you intend to present something, please send a request to the = chairs. >>>=20 >>> Best regards >>> Ulrich >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From Chris.Dearlove@baesystems.com Fri Oct 12 06:19:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6B321F850B for ; Fri, 12 Oct 2012 06:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGCqc2I9u5ZT for ; Fri, 12 Oct 2012 06:19:58 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 686D921F8510 for ; Fri, 12 Oct 2012 06:19:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,576,1344207600"; d="scan'208";a="277957280" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Oct 2012 14:19:57 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9CDJueG021022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 14:19:56 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Fri, 12 Oct 2012 14:19:56 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry , Abdussalam Baryun , " List" Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg2l5EwSF9H40GgZ3/Q87Dtwpe1XAIAgAAi0ACAABEHgIAAG2Zg Date: Fri, 12 Oct 2012 13:19:55 +0000 Message-ID: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:20:00 -0000 We have often discussed things not yet accepted by the WG, it can be a step= towards getting them accepted. That's not a comment for or against LOADng, discussing LOADng, or adopting = LOADng, just an observation on what has happened in the past. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry Sent: 12 October 2012 13:40 To: Abdussalam Baryun; List; Bo Berry Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Looking at the MANET WG Documents page, LOADng is not on the list. So until= LOADng is accepted by the WG, gotta agree with Abdussalam, no need to disc= uss it in the little time we have for the work we've already accepted. How does this fit into the WG Charter? -Bo Active Internet-Drafts draft-ietf-manet-dlep-03=09Dynamic Link Exchange Protocol (DLEP)=09 draft-ietf-manet-nhdp-mib-19=09Definition of Managed Objects for the Neighb= orhood Discovery Protocol=09 draft-ietf-manet-nhdp-sec-02=09Using Integrity Check Values and Timestamps = For Router Admittance in NHDP=09 draft-ietf-manet-olsrv2-16=09The Optimized Link State Routing Protocol vers= ion 2 draft-ietf-manet-olsrv2-metrics-rationale-01=09Link Metrics for the Mobile = Ad Hoc Network (MANET) Routing=20 draft-ietf-manet-olsrv2-mib-04=09Definition of Managed Objects for the Opti= mized Link State Routing Protocol=20 On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: > I've seen a number of emails on the alias but not sure LOADng=20 > has been accepted by the WG. Is LOADng asking to be a MANET WG > draft? >=20 > -Bo >=20 >=20 > On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >=20 >> Please note that I strongly object any including of LOADng draft in the = Agenda. >> The document is not for MANET, was already presented before, and the >> authors are not discussing on ietf lists of any progress. The draft is >> not reasonable for the WG, if it is not discussed on the MANET list. >>=20 >> I got no reasonable reply to all my efforts, the last as: >> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>=20 >> AB >> On 10/9/12, Ulrich Herberg wrote: >>> Hi, >>>=20 >>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon= A. >>> If you intend to present something, please send a request to the chairs= . >>>=20 >>> Best regards >>> Ulrich >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > --- > We cannot solve our problems with the same thinking we used when we creat= ed them.=20 > Albert Einstein >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them.=20 Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Fri Oct 12 06:33:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5F21F84D4 for ; Fri, 12 Oct 2012 06:33: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD2OCwoHZ3Ul for ; Fri, 12 Oct 2012 06:33:59 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DABB21F84DD for ; Fri, 12 Oct 2012 06:33:58 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so251135wib.13 for ; Fri, 12 Oct 2012 06:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8abEtY2029DvIDTsfIrY6EAEnnQPGinkVptsMRIXDdU=; b=HUIvcVgOaF2RplSTp39Dh36iFVL/MqK7Id8VtmpGf4/GqcCzTxciMdi13unFceLNoG vekvhBoaCqSIYmML8A1Tzd/JRS/xZrq4mlFec1y03EtqmbxrVh/fC9sFbypRPdqFZP7W smFMP0k3ibvPVr7+WxRvtykVogGJQrVO8TEkaIBibZPiZMsd8Q7ar4bzJtuqRzkcGloI etg1dFeHdWdIwrCTNrzgsReNI9wrGNk6F8secRSVnawsDJlY8SiodBvv9YxYdidwA62y n286++8PLZb938evQxjsvGa6JNy7a7cci2MGEdgOyxxm0culfsoGXqlj5+GpzG5A1vN3 RFfw== Received: by 10.216.227.133 with SMTP id d5mr2779820weq.194.1350048837618; Fri, 12 Oct 2012 06:33:57 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id b7sm3253990wiz.3.2012.10.12.06.33.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 06:33:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Fri, 12 Oct 2012 15:33:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmPRy3ztK4YqPWdiR3BVooJQDtFZ4/OZt35qU2BklcBhR2m0GY3RMJo9hMHDV7AWqMmv46S Cc: " List" , Bo Berry Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:33:59 -0000 On July 31th, our chair provided guidance on handling LOADng. It shows the way forward. I'm looking forward to an draft-author-manet-loadng-00 draft, submitted = before next Monday. If there is no such draft, and little time to discuss non-wg drafts, we = should not discuss an lln draft in our meeting in Atlanta. I'm OK on discussions on how to fulfill our charter item on a reactive = protocol. Teco=20 Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende = geschreven: > We have often discussed things not yet accepted by the WG, it can be a = step towards getting them accepted. >=20 > That's not a comment for or against LOADng, discussing LOADng, or = adopting LOADng, just an observation on what has happened in the past. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Bo Berry > Sent: 12 October 2012 13:40 > To: Abdussalam Baryun; List; Bo Berry > Subject: Re: [manet] MANET meeting at IETF85 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Looking at the MANET WG Documents page, LOADng is not on the list. So = until LOADng is accepted by the WG, gotta agree with Abdussalam, no need = to discuss it in the little time we have for the work we've already = accepted. >=20 > How does this fit into the WG Charter? >=20 > -Bo >=20 >=20 > Active Internet-Drafts > draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP)=09 > draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the = Neighborhood Discovery Protocol=09 > draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and = Timestamps For Router Admittance in NHDP=09 > draft-ietf-manet-olsrv2-16 The Optimized Link State Routing = Protocol version 2 > draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the = Mobile Ad Hoc Network (MANET) Routing=20 > draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects = for the Optimized Link State Routing Protocol=20 >=20 >=20 >=20 > On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >=20 >> I've seen a number of emails on the alias but not sure LOADng=20 >> has been accepted by the WG. Is LOADng asking to be a MANET WG >> draft? >>=20 >> -Bo >>=20 >>=20 >> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>=20 >>> Please note that I strongly object any including of LOADng draft in = the Agenda. >>> The document is not for MANET, was already presented before, and the >>> authors are not discussing on ietf lists of any progress. The draft = is >>> not reasonable for the WG, if it is not discussed on the MANET list. >>>=20 >>> I got no reasonable reply to all my efforts, the last as: >>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>=20 >>> AB >>> On 10/9/12, Ulrich Herberg wrote: >>>> Hi, >>>>=20 >>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in = Salon A. >>>> If you intend to present something, please send a request to the = chairs. >>>>=20 >>>> Best regards >>>> Ulrich >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we = created them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Fri Oct 12 07:01:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D7321F859E for ; Fri, 12 Oct 2012 07:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0ZmHZ-Rrdjc for ; Fri, 12 Oct 2012 07:01:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CA3B821F8582 for ; Fri, 12 Oct 2012 07:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1543; q=dns/txt; s=iport; t=1350050502; x=1351260102; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9OOV/sEu2ucJqsXmkHm8yNgDUixXfhwnOAx85UyIwZQ=; b=kH+xVfO0va7kaf+uUU8mppnk5mr+NIyygs9/KO6tXIon+xc5QFc8v4uP dHLX1OOC7bdDZRrHDbw9t/6K29FmNqQQ6+qBjY+otl5BPCGnAe62FgfJ7 lg/eaiYv0cR0DhbqkUUSbmpr65Id9RmxGfv0KVz1zknoH7F+T6ZmWNF51 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHcheFCtJV2Y/2dsb2JhbABEv12BCIIgAQEBAwESASc/BQsCAQgiFBAyJQIEDg0TB4dcBposoA2LUoVdYAOkMoFrgm2BWiEc X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130942580" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 12 Oct 2012 14:01:42 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CE1gCJ010500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 14:01:42 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 09:01:42 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4A= Date: Fri, 12 Oct 2012 14:01:41 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> In-Reply-To: <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--35.910400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:01:43 -0000 On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: > Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >=20 >>>> It's hard to insert even generic, "hand-waving" level text > .... >> So, basically what I'm saying is "Tell me what you want this to say. I'l= l cut and paste your text into the document." >=20 >=20 > The UNKNOWN condition does not apply to RLQ only. Resources is somewhat e= quivalent. In fact all TLVs can be unknown, just after Neighbor Up and no o= ptional TLVs, and no info from peer. Also, the protocol is not complete if = there is no way to get back to a previous state of the information base. > I straightforward solution is to have a method to revoke everything that = is send before. That depends on how you define "everything that is sent before". If, for in= stance, this was the 10th metric update, are you talking about rolling back= to the 9th update? If so, I'm opposed. That's a huge burden on the router.= If you're talking about clearing out a metric value and setting it to some= defined value, like the router's defaults, then I'm OK with that.=20 > Length=3D0 or the existing drop indicator. Text would be: >=20 > Length - (the value for TLV with info) > A zero length can be used to revoke previous provided inf= ormation for this Data Item TLV. >=20 > This could also be used to override the peer provided defaults. Overriding the defaults makes no sense to me.=20 Stan >=20 > Teco >=20 >=20 >=20 From sratliff@cisco.com Fri Oct 12 07:11:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3B821F8628 for ; Fri, 12 Oct 2012 07:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRFnSSjRFEBe for ; Fri, 12 Oct 2012 07:11:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA1221F8622 for ; Fri, 12 Oct 2012 07:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5958; q=dns/txt; s=iport; t=1350051117; x=1351260717; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DXXlWsF7MHNDxhCEMZMJa16XF4xH7KWjifGoESukLF0=; b=DKsJW8vTtzjyZ9dEAXpqE5IW+uTkV+AWBDrsZN6/68FPw/30fWJ4JrTv 0cU6raDNlU7YaucSzdow42Okw3F35dayd/EbSSLJIUWpXKoyoPRkjN1W5 GMpeURPBOx4Z/ID+d7Rwl/R02Cd27mtHJQif7rGK01OIhpNdubf5gWrQ/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFYkeFCtJV2a/2dsb2JhbABEv16BCIIgAQEBAwEBAQEPAScbGQMIBQcEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCAEZh1wGC5omoA2LUhQGCIU7YAOkMoFrgm2BWgk0 X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130971089" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 12 Oct 2012 14:11:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9CEBu3l000762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 14:11:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 09:11:56 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg2FcK4A/9t4kSRRp2+Hv2Rm5e1wJcAgAAi0ACAABEHgIAACx2AgAAD6YCAAAqiAA== Date: Fri, 12 Oct 2012 14:11:55 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> In-Reply-To: <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--61.831900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:11:58 -0000 On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: > On July 31th, our chair provided guidance on handling LOADng. > It shows the way forward. >=20 > I'm looking forward to an draft-author-manet-loadng-00 draft, submitted b= efore next Monday. > If there is no such draft, and little time to discuss non-wg drafts, we s= hould not discuss an lln draft in our meeting in Atlanta. One (not too) fine point - we (the MANET WG) will *not* be discussing an LL= N draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols.=20 Stan > I'm OK on discussions on how to fulfill our charter item on a reactive pr= otocol. >=20 > Teco=20 >=20 >=20 > Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende g= eschreven: >=20 >> We have often discussed things not yet accepted by the WG, it can be a s= tep towards getting them accepted. >>=20 >> That's not a comment for or against LOADng, discussing LOADng, or adopti= ng LOADng, just an observation on what has happened in the past. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Bo Berry >> Sent: 12 October 2012 13:40 >> To: Abdussalam Baryun; List; Bo Berry >> Subject: Re: [manet] MANET meeting at IETF85 >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Looking at the MANET WG Documents page, LOADng is not on the list. So un= til LOADng is accepted by the WG, gotta agree with Abdussalam, no need to d= iscuss it in the little time we have for the work we've already accepted. >>=20 >> How does this fit into the WG Charter? >>=20 >> -Bo >>=20 >>=20 >> Active Internet-Drafts >> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP)=09 >> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neigh= borhood Discovery Protocol=09 >> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps= For Router Admittance in NHDP=09 >> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol ver= sion 2 >> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile= Ad Hoc Network (MANET) Routing=20 >> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Opt= imized Link State Routing Protocol=20 >>=20 >>=20 >>=20 >> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>=20 >>> I've seen a number of emails on the alias but not sure LOADng=20 >>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>> draft? >>>=20 >>> -Bo >>>=20 >>>=20 >>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>=20 >>>> Please note that I strongly object any including of LOADng draft in th= e Agenda. >>>> The document is not for MANET, was already presented before, and the >>>> authors are not discussing on ietf lists of any progress. The draft is >>>> not reasonable for the WG, if it is not discussed on the MANET list. >>>>=20 >>>> I got no reasonable reply to all my efforts, the last as: >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>=20 >>>> AB >>>> On 10/9/12, Ulrich Herberg wrote: >>>>> Hi, >>>>>=20 >>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Sal= on A. >>>>> If you intend to present something, please send a request to the chai= rs. >>>>>=20 >>>>> Best regards >>>>> Ulrich >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> --- >>> We cannot solve our problems with the same thinking we used when we cre= ated them.=20 >>> Albert Einstein >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we crea= ted them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Fri Oct 12 07:15:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E309821F8582 for ; Fri, 12 Oct 2012 07:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3YwWD506pSj for ; Fri, 12 Oct 2012 07:15:54 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 903BE21F84DE for ; Fri, 12 Oct 2012 07:15:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,576,1344207600"; d="scan'208";a="277974828" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Oct 2012 15:15:53 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9CEFq5g020719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 15:15:52 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.28]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Fri, 12 Oct 2012 15:15:52 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Teco Boot Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg2l5EwSF9H40GgZ3/Q87Dtwpe1XAIAgAAi0ACAABEHgIAAG2Zg///zoICAAAqegIAAEWGw Date: Fri, 12 Oct 2012 14:15:50 +0000 Message-ID: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:15:55 -0000 I think you are in violent agreement. The current LOADng draft is (IIRC) ai= med at LLNs, so Teco is saying unless there's a new MANET-oriented version = it shouldn't be discussed, and you are saying it won't be discussed. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 12 October 2012 15:12 To: Teco Boot Cc: Dearlove, Christopher (UK); List; Bo Berry (boberry) Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: > On July 31th, our chair provided guidance on handling LOADng. > It shows the way forward. >=20 > I'm looking forward to an draft-author-manet-loadng-00 draft, submitted b= efore next Monday. > If there is no such draft, and little time to discuss non-wg drafts, we s= hould not discuss an lln draft in our meeting in Atlanta. One (not too) fine point - we (the MANET WG) will *not* be discussing an LL= N draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols.=20 Stan > I'm OK on discussions on how to fulfill our charter item on a reactive pr= otocol. >=20 > Teco=20 >=20 >=20 > Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende g= eschreven: >=20 >> We have often discussed things not yet accepted by the WG, it can be a s= tep towards getting them accepted. >>=20 >> That's not a comment for or against LOADng, discussing LOADng, or adopti= ng LOADng, just an observation on what has happened in the past. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Bo Berry >> Sent: 12 October 2012 13:40 >> To: Abdussalam Baryun; List; Bo Berry >> Subject: Re: [manet] MANET meeting at IETF85 >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Looking at the MANET WG Documents page, LOADng is not on the list. So un= til LOADng is accepted by the WG, gotta agree with Abdussalam, no need to d= iscuss it in the little time we have for the work we've already accepted. >>=20 >> How does this fit into the WG Charter? >>=20 >> -Bo >>=20 >>=20 >> Active Internet-Drafts >> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP)=09 >> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neigh= borhood Discovery Protocol=09 >> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps= For Router Admittance in NHDP=09 >> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol ver= sion 2 >> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile= Ad Hoc Network (MANET) Routing=20 >> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Opt= imized Link State Routing Protocol=20 >>=20 >>=20 >>=20 >> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>=20 >>> I've seen a number of emails on the alias but not sure LOADng=20 >>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>> draft? >>>=20 >>> -Bo >>>=20 >>>=20 >>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>=20 >>>> Please note that I strongly object any including of LOADng draft in th= e Agenda. >>>> The document is not for MANET, was already presented before, and the >>>> authors are not discussing on ietf lists of any progress. The draft is >>>> not reasonable for the WG, if it is not discussed on the MANET list. >>>>=20 >>>> I got no reasonable reply to all my efforts, the last as: >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>=20 >>>> AB >>>> On 10/9/12, Ulrich Herberg wrote: >>>>> Hi, >>>>>=20 >>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Sal= on A. >>>>> If you intend to present something, please send a request to the chai= rs. >>>>>=20 >>>>> Best regards >>>>> Ulrich >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> --- >>> We cannot solve our problems with the same thinking we used when we cre= ated them.=20 >>> Albert Einstein >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we crea= ted them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Fri Oct 12 07:20:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD54221F861D for ; Fri, 12 Oct 2012 07:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I18YjEtCk0gh for ; Fri, 12 Oct 2012 07:20:09 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9205621F8582 for ; Fri, 12 Oct 2012 07:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2181; q=dns/txt; s=iport; t=1350051608; x=1351261208; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=t0fCIBRVzCryooLP2uATwGVDZNTMKxGejqvoQPcyWSc=; b=OkTwCDLWoBo3AjUxvViOruHSpDmaL5BKZRXdGz5Kucpux6rP1O4oLf2K XMBrpv6K4r/eLvjgMhgyVPEPiXhK29n6rhFAchMfS0FCQ2x+faZfquoCm OPWAYDpzIcmRMGeqMaUnuED1LnHofqTdEOL2D9b+psYFbOPLjBQ5VU5w9 M=; X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="18840369" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 12 Oct 2012 14:20:06 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9CEK4md009913; Fri, 12 Oct 2012 14:20:05 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> Date: Fri, 12 Oct 2012 10:20:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1085) Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:20:09 -0000 Teco, I'm trying to understand, but having trouble. Are we talking about = rolling back metrics to a previous state? If so, the radio can simply send a new set of metrics. Using metrics = from some time back makes no sense to me and computing/making a routing = change with old data seems dangerous. How much history does the router = keep? =20 Help me understand. -Bo On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >=20 > On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >=20 >> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>>> It's hard to insert even generic, "hand-waving" level text >> .... >>> So, basically what I'm saying is "Tell me what you want this to say. = I'll cut and paste your text into the document." >>=20 >>=20 >> The UNKNOWN condition does not apply to RLQ only. Resources is = somewhat equivalent. In fact all TLVs can be unknown, just after = Neighbor Up and no optional TLVs, and no info from peer. Also, the = protocol is not complete if there is no way to get back to a previous = state of the information base. >> I straightforward solution is to have a method to revoke everything = that is send before. >=20 > That depends on how you define "everything that is sent before". If, = for instance, this was the 10th metric update, are you talking about = rolling back to the 9th update? If so, I'm opposed. That's a huge burden = on the router. If you're talking about clearing out a metric value and = setting it to some defined value, like the router's defaults, then I'm = OK with that.=20 >=20 >=20 >=20 >> Length=3D0 or the existing drop indicator. Text would be: >>=20 >> Length - (the value for TLV with info) >> A zero length can be used to revoke previous provided = information for this Data Item TLV. >>=20 >> This could also be used to override the peer provided defaults. >=20 > Overriding the defaults makes no sense to me.=20 >=20 > Stan >=20 >>=20 >> Teco >>=20 >>=20 >>=20 >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From abdussalambaryun@gmail.com Fri Oct 12 07:27:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6583A21F8616 for ; Fri, 12 Oct 2012 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZWITGV2fHLy for ; Fri, 12 Oct 2012 07:27:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71921F84D5 for ; Fri, 12 Oct 2012 07:27:18 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3459455vbb.31 for ; Fri, 12 Oct 2012 07:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HTajNHuFKMlnpJ/Z5tieuyDpKqZlxAeaZFVDJJGw9uQ=; b=vFmQEIchdrSwIhkRF6LEbapSVR5iyj4gxFLQBFCEaU/tGzd2IoSumJG9MMtwA898Ds m3Wu9D7w7AdJsj3YySnznG3ocWYQiPPndn8VoE69zVxqjlDnUCNZUlKN6Ai9fT5rcNpO uNflDgqvjbQtt7syoY2eC5quM/aHS0Iu4W/JReGiUUjF9fIyyyJIq4TYdcrU5g67fG4A 3h+fnaKNE+vWy1IvI/3VfjlgRAhBsYqFQ8Z51p4fO1ShxB+bPQ4fYuXB5zBhLHgZH6ie C+/kPyLPUDEgQxWCkjGVJDF5vhv2xCYw3qAnToLiN7PyhxK9Q+dQWBnUc3i1HOT/mF2v NKCg== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr2166867vdw.25.1350052038013; Fri, 12 Oct 2012 07:27:18 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 07:27:17 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2C0DD756-036C-4A59-8960-B00F42FD212A@inf-net.nl> Date: Fri, 12 Oct 2012 15:27:17 +0100 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: multipart/alternative; boundary=20cf307abd9327718704cbdd7cc4 Cc: " List" Subject: Re: [manet] Another comment on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:27:19 -0000 --20cf307abd9327718704cbdd7cc4 Content-Type: text/plain; charset=ISO-8859-1 > > Making a suggestion does not mean the suggestion is automatically added > to the draft. The suggestion needs consensus and agreement. > Hi Bo, That is not always true, IF the authors made mistake, THEN there SHOULD be no need for consensus, we are engineers and we need to be reasonable, I suggested before the correct the mistake in page 4 draft-02> *the Data Link Exchange Protocol, or DLEP* To be *Dynamic Link Exchange Protocol, or DLEP* But its still wrong name and was not corrected in draft-03, another participant has repeated my request, and hope the authors follw up. Any suggestion by a participant SHOULD be followed up by all participants, including editors and Chair, if no reply from any, the input SHOULD be respected and taken, otherwise we are waisting time and efforts here. AB > > > > > > AB > > > > On 10/12/12, Teco Boot wrote: > >> Another somewhat old discussion on DLEP (August 11th 2010): > >> > >>>>>>>>>>> Another topic is the choice on which side of a link gets what > >>>>>>>>>>> information. > >>>>>>>>>>> Draft-dearlove-olsrv2-metrics proposes the routing protocol > >>>>>>>>>>> instance gets > >>>>>>>>>>> the L2 metrics for incoming side of links, OLSR/NHDP take care > of > >>>>>>>>>>> metric > >>>>>>>>>>> transfer to TC originator. Other protocols work otherwise (e.g > >>>>>>>>>>> the > >>>>>>>>>>> OSPF-MANET family). There, in case of asymmetric metrics, it is > >>>>>>>>>>> assumed that > >>>>>>>>>>> the radios would run another (L2 or L3) protocol for metric > >>>>>>>>>>> transfer, if > >>>>>>>>>>> needed. Are asymmetric metrics supported, and if so, what > model is > >>>>>>>>>>> proposed? > >>>>>>>> > >>>>>>>> I believe the DLEP draft would support asymmetric links -- at > least > >>>>>>>> links where bi-directional connectivity exists, though > potentially at > >>>>>>>> different speeds. This is analogous to RFC 5778 operation. In RFC > >>>>>>>> 5778, each side of a connection gets metrics that represent the > >>>>>>>> ability of that side to send to the partner. If one side runs at a > >>>>>>>> slower speed than the other, different "send metrics" are > reported to > >>>>>>>> the respective routers. > >>>>>>> > >>>>>>> I think it is important to specify the semantics of the provided > >>>>>>> metrics. For what direction does this data apply? > >>>>>>> OSPF-MANET and OLSR have different requirements here: OSPF requires > >>>>>>> outbound direction, OLSR inbound. > >>>>>>> Maybe DLEP could support both models, and mode is negotiated. > >>>>>>> > >>>>>> > >>>>>> OK, what if we changed the metric packet to include both inbound and > >>>>>> outbound bandwidth? That way, no negotiation would be required, and > the > >>>>>> routing protocol could select the data it needs. > >>>>> If information is available, it can be provided without high costs. > >>>>> If it is optionally available, e.g. it requires transfer over the > radio, > >>>>> it should be made available only if needed. > >>>>> This can be configuration or negotiation. > >>>>> > >>>>> It is not only bandwidth, it applies to other metrics also. Maybe the > >>>>> whole set. > >>>> > >>>> I'm OK with this. Are there other opinions on the list? > >>> > >>> Look in the IEEE 802.16 specification. Table 14 (in Chapter 6 of the > >>> -2004 version I have) contains the roughly four dozen MAC messages that > >>> control the network segment. Many of the variables trafficked here are > >>> reflected one way or another in the MIB. > >>> > >>> Is not what your asking for is some way to reflect some of this data up > >>> to layer 3? > >> > >> I don't think the draft was updated to reflect the outcome of this > >> discussion. > >> @Stan: is there a follow-up? > >> > >> Teco > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > >> > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > --- > We cannot solve our problems with the same thinking we used when we > created them. > Albert Einstein > > > > --20cf307abd9327718704cbdd7cc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Making a suggestion does not mean the suggestion is automatically added
to the draft. =A0The suggestion needs consensus and agreement.
Hi Bo,
=A0
That is not always true,=A0IF= the authors made=A0 mistake, THEN there=A0SHOULD be no need for consensus,=
we are engineers and we need to be reasonable,
=A0
I suggested before the correct the mistake in page 4 draft-02>
*the Data Link Exchange Protocol, or DLEP* To be *Dynamic Link Exchange P= rotocol, or DLEP*
=A0
But its still wrong name and was not corrected in draft-= 03, another participant has repeated my request, and hope the authors follw= up.
Any suggestion by a participant SHOULD be followed up by all= participants, including=A0editors and Chair, if no reply from any, the inp= ut SHOULD be respected and taken, otherwise we are waisting time and effort= s=A0here.
=A0
=A0
AB
=A0
=A0
= =A0


>
> AB
>
> On 10/12/12, Teco Boot <teco@inf= -net.nl> wrote:
>> Another somewhat old discussion on DLEP (August 11th 2010):
>>
>>>>>>>>>>> Another topic is the choice on= which side of a link gets what
>>>>>>>>>>> information.
>>>>>>>>>>> Draft-dearlove-olsrv2-metrics = proposes the routing protocol
>>>>>>>>>>> instance gets
>>>>>>>>>>> the L2 metrics for incoming si= de of links, OLSR/NHDP take care of
>>>>>>>>>>> metric
>>>>>>>>>>> transfer to TC originator. Oth= er protocols work otherwise (e.g
>>>>>>>>>>> the
>>>>>>>>>>> OSPF-MANET family). There, in = case of asymmetric metrics, it is
>>>>>>>>>>> assumed that
>>>>>>>>>>> the radios would run another (= L2 or L3) protocol for metric
>>>>>>>>>>> transfer, if
>>>>>>>>>>> needed. Are asymmetric metrics= supported, and if so, what model is
>>>>>>>>>>> proposed?
>>>>>>>>
>>>>>>>> I believe the DLEP draft would support asy= mmetric links -- at least
>>>>>>>> links where bi-directional connectivity ex= ists, though potentially at
>>>>>>>> different speeds. This is analogous to RFC= 5778 operation. In RFC
>>>>>>>> 5778, each side of a connection gets metri= cs that represent the
>>>>>>>> ability of that side to send to the partne= r. If one side runs at a
>>>>>>>> slower speed than the other, different &qu= ot;send metrics" are reported to
>>>>>>>> the respective routers.
>>>>>>>
>>>>>>> I think it is important to specify the semanti= cs of the provided
>>>>>>> metrics. For what direction does this data app= ly?
>>>>>>> OSPF-MANET and OLSR have different requirement= s here: OSPF requires
>>>>>>> outbound direction, OLSR inbound.
>>>>>>> Maybe DLEP could support both models, and mode= is negotiated.
>>>>>>>
>>>>>>
>>>>>> OK, what if we changed the metric packet to includ= e both inbound and
>>>>>> outbound bandwidth? That way, no negotiation would= be required, and the
>>>>>> routing protocol could select the data it needs. >>>>> If information is available, it can be provided withou= t high costs.
>>>>> If it is optionally available, e.g. it requires transf= er over the radio,
>>>>> it should be made available only if needed.
>>>>> This can be configuration or negotiation.
>>>>>
>>>>> It is not only bandwidth, it applies to other metrics = also. Maybe the
>>>>> whole set.
>>>>
>>>> I'm OK with this. Are there other opinions on the list= ?
>>>
>>> Look in the IEEE 802.16 specification. =A0Table 14 (in Chapter= 6 of the
>>> -2004 version I have) contains the roughly four dozen MAC mess= ages that
>>> control the network segment. =A0Many of the variables traffick= ed here are
>>> reflected one way or another in the MIB.
>>>
>>> Is not what your asking for is some way to reflect some of thi= s data up
>>> to layer 3?
>>
>> I don't think the draft was updated to reflect the outcome of = this
>> discussion.
>> @Stan: is there a follow-up?
>>
>> Teco
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinking we used when we created= them.
Albert Einstein




--20cf307abd9327718704cbdd7cc4-- From abdussalambaryun@gmail.com Fri Oct 12 07:34:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDC921F8582 for ; Fri, 12 Oct 2012 07:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8bVFPcViIsP for ; Fri, 12 Oct 2012 07:34:12 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E949C21F854C for ; Fri, 12 Oct 2012 07:34:11 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3469786vbb.31 for ; Fri, 12 Oct 2012 07:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0gOXbk//1m634EjBAjvk2aDNBeKHluUADS5DeWjnbic=; b=hFwWNlkhsVIobYyXuh+Uout5BS+uqpcVRbYfDxVDfXfXHsB3fiJXWJfCXIU4SM6y4/ oJZMUyJNEUuDvRkBdkp1EM7o0yMVufFW0LkleP11LRT9F8r3UIDfAEd1bZAXZuxYQOwk xrXhZSPcSZDhBYEJhBt05UghPJkhREI9gNBvweJZT7q5zVOseczampadd7EzALVux9qJ yweL5aaPCNU7LAY5fYca3XNMFugjzNQjDuad+YFJzDuf46E7HLvOjH9oXZb6ya/lnsc4 vkiIbGAm9f/Zy9F8xthfWYsCA9Wnp+sRXtJXlMC8ufSl2q/SOZTVzlpIZ3pqtm+4lk2N ibyg== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr2175567vdw.25.1350052451353; Fri, 12 Oct 2012 07:34:11 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 07:34:11 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> Date: Fri, 12 Oct 2012 15:34:11 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=20cf307abd93ca850c04cbdd9428 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:34:13 -0000 --20cf307abd93ca850c04cbdd9428 Content-Type: text/plain; charset=ISO-8859-1 Hi stan, >we (the MANET WG) will *not* be discussing an LLN draft thanks to clarify that, because I remember that you refered in the last meeting, that LOADng SHOULD be discussed, so I followed my efforts. I am interested in the work to be changed quickly because in the last meeting the MANET WG chair has accepted the discussion on the list. Now I understand that we will have no discussion for the latest individual draft (which was proposed for the WG in meeting 84), thanks, AB On Fri, Oct 12, 2012 at 3:11 PM, Stan Ratliff (sratliff) wrote: > > On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: > > > On July 31th, our chair provided guidance on handling LOADng. > > It shows the way forward. > > > > I'm looking forward to an draft-author-manet-loadng-00 draft, submitted > before next Monday. > > If there is no such draft, and little time to discuss non-wg drafts, we > should not discuss an lln draft in our meeting in Atlanta. > > One (not too) fine point - we (the MANET WG) will *not* be discussing an > LLN draft. At any time. That would be a charter violation - LLN's are > defined and worked in ROLL. We are discussing MANET reactive protocols. > > Stan > > > > I'm OK on discussions on how to fulfill our charter item on a reactive > protocol. > > > > Teco > > > > > > Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende > geschreven: > > > >> We have often discussed things not yet accepted by the WG, it can be a > step towards getting them accepted. > >> > >> That's not a comment for or against LOADng, discussing LOADng, or > adopting LOADng, just an observation on what has happened in the past. > >> > >> -- > >> Christopher Dearlove > >> Senior Principal Engineer, Communications Group > >> Communications, Networks and Image Analysis Capability > >> BAE Systems Advanced Technology Centre > >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> chris.dearlove@baesystems.com | http://www.baesystems.com > >> > >> BAE Systems (Operations) Limited > >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > >> Registered in England & Wales No: 1996687 > >> > >> > >> -----Original Message----- > >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Bo Berry > >> Sent: 12 October 2012 13:40 > >> To: Abdussalam Baryun; List; Bo Berry > >> Subject: Re: [manet] MANET meeting at IETF85 > >> > >> ----------------------! WARNING ! ---------------------- > >> This message originates from outside our organisation, > >> either from an external partner or from the internet. > >> Keep this in mind if you answer this message. > >> Follow the 'Report Suspicious Emails' link on IT matters > >> for instructions on reporting suspicious email messages. > >> -------------------------------------------------------- > >> > >> Looking at the MANET WG Documents page, LOADng is not on the list. So > until LOADng is accepted by the WG, gotta agree with Abdussalam, no need to > discuss it in the little time we have for the work we've already accepted. > >> > >> How does this fit into the WG Charter? > >> > >> -Bo > >> > >> > >> Active Internet-Drafts > >> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) > >> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the > Neighborhood Discovery Protocol > >> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and > Timestamps For Router Admittance in NHDP > >> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol > version 2 > >> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the > Mobile Ad Hoc Network (MANET) Routing > >> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for > the Optimized Link State Routing Protocol > >> > >> > >> > >> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: > >> > >>> I've seen a number of emails on the alias but not sure LOADng > >>> has been accepted by the WG. Is LOADng asking to be a MANET WG > >>> draft? > >>> > >>> -Bo > >>> > >>> > >>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: > >>> > >>>> Please note that I strongly object any including of LOADng draft in > the Agenda. > >>>> The document is not for MANET, was already presented before, and the > >>>> authors are not discussing on ietf lists of any progress. The draft is > >>>> not reasonable for the WG, if it is not discussed on the MANET list. > >>>> > >>>> I got no reasonable reply to all my efforts, the last as: > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html > >>>> > >>>> AB > >>>> On 10/9/12, Ulrich Herberg wrote: > >>>>> Hi, > >>>>> > >>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in > Salon A. > >>>>> If you intend to present something, please send a request to the > chairs. > >>>>> > >>>>> Best regards > >>>>> Ulrich > >>>>> > >>>> _______________________________________________ > >>>> manet mailing list > >>>> manet@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/manet > >>> > >>> --- > >>> We cannot solve our problems with the same thinking we used when we > created them. > >>> Albert Einstein > >>> > >>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >> > >> --- > >> We cannot solve our problems with the same thinking we used when we > created them. > >> Albert Einstein > >> > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > >> > >> > >> ******************************************************************** > >> This email and any attachments are confidential to the intended > >> recipient and may also be privileged. If you are not the intended > >> recipient please delete it from your system and notify the sender. > >> You should not copy it or use it for any purpose nor disclose or > >> distribute its contents to any other person. > >> ******************************************************************** > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307abd93ca850c04cbdd9428 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi stan,
=A0
>we (the MANET WG) will *not* be d= iscussing an LLN draft
=A0
thanks to clarify that, beca= use I remember that you refered in the last meeting, that LOADng SHOULD be = discussed, so I followed my efforts. I am interested in the work to be chan= ged quickly because in the last meeting the MANET WG chair has accepted the= discussion on the list. Now I understand that we will have no discussion f= or the latest individual=A0draft (which was proposed for the WG in meeting = 84),
=A0
=A0thanks,
=A0
AB

On Fri, Oct 12, 2012 at 3:11 PM, Stan Ratliff (sratli= ff) <sratliff@cisco.com> wrote:

On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:

> On July 31th, our chair provided guidance on handling LOADng.
> It shows the way forward.
>
> I'm looking forward to an draft-author-manet-loadng-00 draft, subm= itted before next Monday.
> If there is no such draft, and little time to discuss non-wg drafts, w= e should not discuss an lln draft in our meeting in Atlanta.

One (not too) fine point - we (the MANET WG) will *not* be discussing= an LLN draft. At any time. That would be a charter violation - LLN's a= re defined and worked in ROLL. We are discussing MANET reactive protocols.<= br>
Stan


> I'm OK on discussions on how to fulfill our charter item on a reac= tive protocol.
>
> Teco
>
>
> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgend= e geschreven:
>
>> We have often discussed things not yet accepted by the WG, it can = be a step towards getting them accepted.
>>
>> That's not a comment for or against LOADng, discussing LOADng,= or adopting LOADng, just an observation on what has happened in the past.<= br> >>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
>> chris.dearlove@ba= esystems.com | = http://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: manet-bounces@ietf= .org [mailto:manet-bounces@ie= tf.org] On Behalf Of Bo Berry
>> Sent: 12 October 2012 13:40
>> To: Abdussalam Baryun; <manet= @ietf.org> List; Bo Berry
>> Subject: Re: [manet] MANET meeting at IETF85
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> Looking at the MANET WG Documents page, LOADng is not on the list.= So until LOADng is accepted by the WG, gotta agree with Abdussalam, no nee= d to discuss it in the little time we have for the work we've already a= ccepted.
>>
>> How does this fit into the WG Charter?
>>
>> -Bo
>>
>>
>> Active Internet-Drafts
>> draft-ietf-manet-dlep-03 =A0 =A0 Dynamic Link Exchange Protocol (D= LEP)
>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the= Neighborhood Discovery Protocol
>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Time= stamps For Router Admittance in NHDP
>> draft-ietf-manet-olsrv2-16 =A0 The Optimized Link State Routing Pr= otocol version 2
>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the = Mobile Ad Hoc Network (MANET) Routing
>> draft-ietf-manet-olsrv2-mib-04 =A0 =A0 =A0 Definition of Managed O= bjects for the Optimized Link State Routing Protocol
>>
>>
>>
>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:
>>
>>> I've seen a number of emails on the alias but not sure LOA= Dng
>>> has been accepted by the WG. =A0Is LOADng asking to be a MANET= WG
>>> draft?
>>>
>>> -Bo
>>>
>>>
>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote:
>>>
>>>> Please note that I strongly object any including of LOADng= draft in the Agenda.
>>>> The document is not for MANET, was already presented befor= e, and the
>>>> authors are not discussing on ietf lists of any progress. = The draft is
>>>> not reasonable for the WG, if it is not discussed on the M= ANET list.
>>>>
>>>> I got no reasonable reply to all my efforts, the last as:<= br> >>>> http://www.ietf.org/mail-archive/web/m= anet/current/msg13448.html
>>>>
>>>> AB
>>>> On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
>>>>> Hi,
>>>>>
>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm t= o 2.30pm in Salon A.
>>>>> If you intend to present something, please send a requ= est to the chairs.
>>>>>
>>>>> Best regards
>>>>> Ulrich
>>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> ---
>>> We cannot solve our problems with the same thinking we used wh= en we created them.
>>> Albert Einstein
>>>
>>>
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
>> ---
>> We cannot solve our problems with the same thinking we used when w= e created them.
>> Albert Einstein
>>
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> ******************************************************************= **
>> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended<= br> >> recipient please delete it from your system and notify the sender.=
>> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person.
>> ******************************************************************= **
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307abd93ca850c04cbdd9428-- From abdussalambaryun@gmail.com Fri Oct 12 07:41:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2F21F852E for ; Fri, 12 Oct 2012 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QENqMbEv+abo for ; Fri, 12 Oct 2012 07:41:44 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 849EE21F8554 for ; Fri, 12 Oct 2012 07:41:44 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3966061vcb.31 for ; Fri, 12 Oct 2012 07:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I4P3utF9e3dfqfZSjKek8ij3pmEu1PgySvHOJJrxqKg=; b=PyOu0YFAgvsp3mAxhqbhkX+MZzvJrTRvelr3XX6YLQBFKR7lg1D8NRqgqz2LHxEklB bFm6lNOwQU/akx8x3+jMfE9YPdDuVyQLreOUNEzenXIFzRHqzefTYq9LIUbvBPfnVD+U sXedcuNrqxI0jTcyhKq06T1F6DE1RNCqYNTkyOlom9Eucl4h9/t0x9yIENmknyqSq9U7 Vb5gb/YMpM7rwsoXxYsKUYt8GeOs02IThB5GUvtp/A0C4/HVNp0jA7apuLCcRP+1mPjL ApZ2sCiHW3u15xR+SpdeHxbW3ufsQHa/K86D6PVpwI808tzICgSbS7vPIig91nFt1XOh 303Q== MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr2659525vec.51.1350052904010; Fri, 12 Oct 2012 07:41:44 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 07:41:43 -0700 (PDT) In-Reply-To: <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> Date: Fri, 12 Oct 2012 15:41:43 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: multipart/alternative; boundary=047d7b2e5352c5858d04cbddafcc Cc: "Dearlove, Christopher \(UK\)" , " List" , Bo Berry Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:41:45 -0000 --047d7b2e5352c5858d04cbddafcc Content-Type: text/plain; charset=ISO-8859-1 +1 AB On Fri, Oct 12, 2012 at 2:33 PM, Teco Boot wrote: > On July 31th, our chair provided guidance on handling LOADng. > It shows the way forward. > > I'm looking forward to an draft-author-manet-loadng-00 draft, submitted > before next Monday. > If there is no such draft, and little time to discuss non-wg drafts, we > should not discuss an lln draft in our meeting in Atlanta. > I'm OK on discussions on how to fulfill our charter item on a reactive > protocol. > > Teco > > > --047d7b2e5352c5858d04cbddafcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

AB
On Fri, Oct 12= , 2012 at 2:33 PM, Teco Boot <teco@inf-net.nl> wrote:
On July 31th, our chair provided guidance on handling LOADng.
It shows the way forward.

I'm looking forward to an draft-author-manet-loadng-00 draft, submitted= before next Monday.
If there is no such draft, and little time to discuss non-wg drafts, we sho= uld not discuss an lln draft in our meeting in Atlanta.
I'm OK on discussions on how to fulfill our charter item on a reactive = protocol.

Teco

=A0
--047d7b2e5352c5858d04cbddafcc-- From abdussalambaryun@gmail.com Fri Oct 12 07:48:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7838621F84DE for ; Fri, 12 Oct 2012 07:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCgYDHj3SKis for ; Fri, 12 Oct 2012 07:48:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 682DF21F8484 for ; Fri, 12 Oct 2012 07:48:37 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3488643vbb.31 for ; Fri, 12 Oct 2012 07:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eGW48/l9ktIbaF6gwvf+ug8eMFbwm+t0YeaNqKt/OSQ=; b=1C7QUntEiat1wct4xwXhUOWhN1hZemhya4uCuaGW4Sm+uLWm8vU//M0TRj/5+hhG3T pZo+EShtErMT1eBBmorgFO9G2FNEXU507QkVcdcn2mYxOHcLANYjCBvor9rp6VCALru+ EBU0kj0aC5rtq66n3vZqDLx2ZuCZH0Kb+NFNHhmHqPTIO8mpS/N/pjKo8Im2OBaP2UI4 oNBp+M/okyzK/Kza2IRlA8twNqo6PtU1Vip0cRogtnAxRY5iP3k/bNPcs6lFJJwP0QXE wWkUhdeRRWr0W1CzKyUyPzDuMw0sznrg0IhHwXY2BMD00/eUk4oAJfbj0Blw7DFJrE/L 4ecg== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr2147327vdj.99.1350053316668; Fri, 12 Oct 2012 07:48:36 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 07:48:36 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> Date: Fri, 12 Oct 2012 15:48:36 +0100 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: multipart/alternative; boundary=20cf307c9fbe5e2daa04cbddc839 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:48:38 -0000 --20cf307c9fbe5e2daa04cbddc839 Content-Type: text/plain; charset=ISO-8859-1 Hi Bo, It was never on the manet-lists maybe once in last meeting Agenda, but got two times heated discussions in MANET WG previous meetings, I see that it was waisting efforts and time. I RECOMMEND that discussing something not relevant to WG SHOULD not happen again and also to any other routing area WG. AB On Fri, Oct 12, 2012 at 1:40 PM, Bo Berry wrote: > Looking at the MANET WG Documents page, LOADng is not on the list. So > until LOADng is accepted by the WG, gotta agree with Abdussalam, no need to > discuss it in the little time we have for the work we've already accepted. > > How does this fit into the WG Charter? > > -Bo > > > Active Internet-Drafts > draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) > draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the > Neighborhood Discovery Protocol > draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and > Timestamps For Router Admittance in NHDP > draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol > version 2 > draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the > Mobile Ad Hoc Network (MANET) Routing > draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the > Optimized Link State Routing Protocol > > > > On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: > > > I've seen a number of emails on the alias but not sure LOADng > > has been accepted by the WG. Is LOADng asking to be a MANET WG > > draft? > > > > -Bo > > > > > > On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: > > > >> Please note that I strongly object any including of LOADng draft in the > Agenda. > >> The document is not for MANET, was already presented before, and the > >> authors are not discussing on ietf lists of any progress. The draft is > >> not reasonable for the WG, if it is not discussed on the MANET list. > >> > >> I got no reasonable reply to all my efforts, the last as: > >> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html > >> > >> AB > >> On 10/9/12, Ulrich Herberg wrote: > >>> Hi, > >>> > >>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in > Salon A. > >>> If you intend to present something, please send a request to the > chairs. > >>> > >>> Best regards > >>> Ulrich > >>> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > --- > > We cannot solve our problems with the same thinking we used when we > created them. > > Albert Einstein > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > --- > We cannot solve our problems with the same thinking we used when we > created them. > Albert Einstein > > > > --20cf307c9fbe5e2daa04cbddc839 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bo,
=A0
It was never on the manet-lists maybe o= nce in last meeting Agenda, but got two times heated=A0discussions in MANET= WG previous meetings, I see that it was waisting efforts and time.
=A0
=A0I RECOMMEND that discussing something not relevant to WG S= HOULD not happen again and also to=A0any other routing area WG.
= =A0
AB

On Fri, Oct 12, 20= 12 at 1:40 PM, Bo Berry <boberry@cisco.com> wrote:
Looking at the MANET WG Documents page, LOADng is not on t= he list. So until LOADng is accepted by the WG, gotta agree with Abdussalam= , no need to discuss it in the little time we have for the work we've a= lready accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03 =A0 =A0 =A0 =A0Dynamic Link Exchange Protocol (DLE= P)
draft-ietf-manet-nhdp-mib-19 =A0 =A0Definition of Managed Objects for the N= eighborhood Discovery Protocol
draft-ietf-manet-nhdp-sec-02 =A0 =A0Using Integrity Check Values and Timest= amps For Router Admittance in NHDP
draft-ietf-manet-olsrv2-16 =A0 =A0 =A0The Optimized Link State Routing Prot= ocol version 2
draft-ietf-manet-olsrv2-metrics-rationale-01 =A0 =A0Link Metrics for the Mo= bile Ad Hoc Network (MANET) Routing
draft-ietf-manet-olsrv2-mib-04 =A0Definition of Managed Objects for the Opt= imized Link State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:

> I've seen a number of emails on the alias but not sure LOADng
> has been accepted by the WG. =A0Is LOADng asking to be a MANET WG
> draft?
>
> -Bo
>
>
> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote:
>
>> Please note that I strongly object any including of LOADng draft i= n the Agenda.
>> The document is not for MANET, was already presented before, and t= he
>> authors are not discussing on ietf lists of any progress. The draf= t is
>> not reasonable for the WG, if it is not discussed on the MANET lis= t.
>>
>> I got no reasonable reply to all my efforts, the last as:
>> http://www.ietf.org/mail-archive/web/manet/cur= rent/msg13448.html
>>
>> AB
>> On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
>>> Hi,
>>>
>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm= in Salon A.
>>> If you intend to present something, please send a request to t= he chairs.
>>>
>>> Best regards
>>> Ulrich
>>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
> ---
> We cannot solve our problems with the same thinking we used when we cr= eated them.
> Albert Einstein
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinking we used when we created= them.
Albert Einstein




--20cf307c9fbe5e2daa04cbddc839-- From abdussalambaryun@gmail.com Fri Oct 12 08:03:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10921F8687 for ; Fri, 12 Oct 2012 08:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM3dCiucHhpl for ; Fri, 12 Oct 2012 08:03:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66CA621F8685 for ; Fri, 12 Oct 2012 08:03:20 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3508492vbb.31 for ; Fri, 12 Oct 2012 08:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VjGC6LVNUUw5650U0ZbeIZ7NCa45YKmjmksX2IpcNXA=; b=vz6D8zRuXlNlp8ciTVrs7PPdCb26E2Q3Srty//mtV67M+hTpZlux7tZUiZllL67CUj 3/Z6z/Hg7Y5sB3PF0h3vTvY44oETGUeLKGzv3mzAZQozZwCBCwjIykmY3bA1Eau7jjV1 mZ6iA6LcYEzzBOzazJC0gny8HyGBaxgsLeSvTi2woeouO5LeqifUyIo7uNjNHSoRI2rK /nc+x6wH7QJ3mAjUSQUIcdtlvFB7XQjwoLe4hVcnNlGdwcNZ73RplPh1rH9guKtzSKnY T6PS19GW1V+RbE4WwJRezDclQBniL9BKrVRpeBie6sw0JBkZJY3iLGIPWTS7fOcZ169n lrJA== MIME-Version: 1.0 Received: by 10.58.12.231 with SMTP id b7mr2788041vec.28.1350054199854; Fri, 12 Oct 2012 08:03:19 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 12 Oct 2012 08:03:19 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> Date: Fri, 12 Oct 2012 16:03:19 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7b41bf3202853404cbddfdcd Cc: " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:03:21 -0000 --047d7b41bf3202853404cbddfdcd Content-Type: text/plain; charset=ISO-8859-1 > > I think you are in violent agreement. The current LOADng draft is (IIRC) > aimed at LLNs, so Teco is saying unless there's a new MANET-oriented > version it shouldn't be discussed, and you are saying it won't be discussed. > > I agree that it violates charter to discuss in MANET WG that individual draft, because ROLL WG beleive that it is their job to discuss it. This was understood from the last 84 meeting in MANET WG. AB > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > Sent: 12 October 2012 15:12 > To: Teco Boot > Cc: Dearlove, Christopher (UK); List; Bo Berry (boberry) > Subject: Re: [manet] MANET meeting at IETF85 > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > --047d7b41bf3202853404cbddfdcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think you are in violent agre= ement. The current LOADng draft is (IIRC) aimed at LLNs, so Teco is saying = unless there's a new MANET-oriented version it shouldn't be discuss= ed, and you are saying it won't be discussed.

I agree that it=A0viol= ates charter to discuss in MANET WG=A0that individual=A0draft, because=A0RO= LL WG beleive that it is their job to discuss it. This was understood from = the last 84 meeting in MANET WG.
=A0
AB
=A0
--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff)= [mailto:sratliff@cisco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet= @ietf.org> List; Bo Berry (boberry)
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

--047d7b41bf3202853404cbddfdcd-- From teco@inf-net.nl Fri Oct 12 08:31:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C54421F8687 for ; Fri, 12 Oct 2012 08:31:31 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+pG04qTK+86 for ; Fri, 12 Oct 2012 08:31:30 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7B21F866E for ; Fri, 12 Oct 2012 08:31:28 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1958666wey.31 for ; Fri, 12 Oct 2012 08:31:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7yEejIZOmQP65PLxk8PaIuOy+cE2ZTCgwcCoYBXbXMM=; b=Hz7+LHdirmBh0r6DrN2r3dBO+XRjNIFP1ypBBcP9sWg/btSIeC2f4P98v49LVAbgAB rrFglCPWWZe2R3cTbN9XTbQbM++bZG1AaUXdJR+roVCxpjUrQdoXoL8nLucGpRAvj1BJ 4jUPS90J8FypR8tsLvemkOTpGBLXWVUsUBzHH2zmjJ1qY44j0jBHhBvHGKFfCImqCCbX M10J0gGRYrUeF3mzvhAM2V6tlytjmfYWg0Yklch8dUeGW2s+ttPcNqTjkKT62K2jssuH /STZ11iyTCCJL5LNgzC4itLobJZXzvVr7egfmsrKYgJX4Yvh3mZUgi9TWNd/XmBGG9/J 0pww== Received: by 10.180.108.45 with SMTP id hh13mr6907458wib.15.1350055888232; Fri, 12 Oct 2012 08:31:28 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id gm7sm4208241wib.10.2012.10.12.08.31.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 08:31:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 12 Oct 2012 17:31:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkMHUcw5vXwo16FhzN/8AyBN7Nu9PxlQCUz6HVJKHqDTaAcimYmZ6V0wmVkhRmFaVP84F1b Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:31:31 -0000 Op 12 okt. 2012, om 16:20 heeft Bo Berry het volgende geschreven: > Teco, > I'm trying to understand, but having trouble. Are we talking about = rolling back metrics to a previous state? I did not have "roll back to a previous state, please" in mind. > If so, the radio can simply send a new set of metrics. Using metrics = from some time back makes no sense to me and computing/making a routing = change with old data seems dangerous. How much history does the router = keep? =20 None. Radio is responsible to get the information bases on radio and = router in sync. >=20 > Help me understand. Example scenario, with minimal exchanged data: Radio sends Peer Discovery, ID only Router sends Peer Offer, ID only Radio sends Peer Offer Ack, ID and Status =20 Radio sends Neighbor Up, ID and MAC. Router sends Neighbor Up Ack, ID and MAC Now, there is no RLQ for that neighbor in the information base in the = router. Radio sends Neighbor Update, ID, MAC and RLQ. (Router should send Neighbor Update Ack, ID and MAC) Now, we have the RLQ. By some magic, the RLQ becomes invalid. Could be antenna switch, = modulation switch or even an RF engine switch. Assume neighbor does not go into down state. How can the radio send a message to the router that the RLQ is in UNKNOW = state again, just as right after the UP state? This can happen with 802.11 CDR. The routing hello protocol detects = symmetrical connectivity. Until there is some unicast traffic, data rate = is unknown. The DLEP radio may start providing CDR after adaptive rate = selection. It may want to revoke stale information. I do not say an 802.11 radio should behave like this. Teco =20 >=20 > -Bo >=20 >=20 > On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >=20 >>=20 >> On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >>=20 >>> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>>=20 >>>>>> It's hard to insert even generic, "hand-waving" level text >>> .... >>>> So, basically what I'm saying is "Tell me what you want this to = say. I'll cut and paste your text into the document." >>>=20 >>>=20 >>> The UNKNOWN condition does not apply to RLQ only. Resources is = somewhat equivalent. In fact all TLVs can be unknown, just after = Neighbor Up and no optional TLVs, and no info from peer. Also, the = protocol is not complete if there is no way to get back to a previous = state of the information base. >>> I straightforward solution is to have a method to revoke everything = that is send before. >>=20 >> That depends on how you define "everything that is sent before". If, = for instance, this was the 10th metric update, are you talking about = rolling back to the 9th update? If so, I'm opposed. That's a huge burden = on the router. If you're talking about clearing out a metric value and = setting it to some defined value, like the router's defaults, then I'm = OK with that.=20 >>=20 >>=20 >>=20 >>> Length=3D0 or the existing drop indicator. Text would be: >>>=20 >>> Length - (the value for TLV with info) >>> A zero length can be used to revoke previous provided = information for this Data Item TLV. >>>=20 >>> This could also be used to override the peer provided defaults. >>=20 >> Overriding the defaults makes no sense to me.=20 >>=20 >> Stan >>=20 >>>=20 >>> Teco >>>=20 >>>=20 >>>=20 >>=20 >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 From ulrich@herberg.name Fri Oct 12 08:38:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8948F21F8623 for ; Fri, 12 Oct 2012 08:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bisqw1FfyAIC for ; Fri, 12 Oct 2012 08:38:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEDC21F8639 for ; Fri, 12 Oct 2012 08:38:39 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3041769pbb.31 for ; Fri, 12 Oct 2012 08:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=Pjsw+s3KVTzWYzdmuBc+e9/at8O98aVhYTLzPOkj688=; b=1MbUq/+Xyk5j+n5lsqrKle6a0gtOWr2TApn3lmZV/Cy+P2BJlmJn8TamCrRaToysc8 jQb7Xs3kdmU/1VN1A4IoQspvVFO0Ni/no9dbeMwmdkh5oIKdaVi4nEy3n7zM2yx1SQ0d 7nr0cbSRwB1R19QcEsZIbr7ny2U9VUEFBzhK4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=Pjsw+s3KVTzWYzdmuBc+e9/at8O98aVhYTLzPOkj688=; b=TSUrdborqJrDA6O1Gjx4ld235T+2qqxUdN6p9paAHfR0lg2DEY692hrTwKDR9maYnI 9ckTDt+HUHRsF+Qe3+r1/drMrnfZrd10t1vV81AeJgC3KqLvA+qAAswiyaGtr1K1CyiE mYbdMRvxuo1RjQOsVrpmo6tcZ87XBd78WH9oa3TPHGTzHxwFALNu3Z0/LdgrLzhx/Pz8 +7TDYbIcQCO6zPTEP19I5SOQfejqmb7NCeujZDZLiFTfey7kL+8A2XN3yZgp9H9/G0v0 V/CVqbWZb7XCzgcMkwW3WjvMHSeEMm9NDK7JOT6vMWaRbcRRt1Vl5XgElUT/bNgYSshV KvNA== Received: by 10.68.242.231 with SMTP id wt7mr14553104pbc.99.1350056318815; Fri, 12 Oct 2012 08:38:38 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id bn1sm4514376pab.8.2012.10.12.08.38.36 (version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 08:38:37 -0700 (PDT) References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Fri, 12 Oct 2012 08:38:37 -0700 To: "Dearlove, Christopher (UK)" X-Gm-Message-State: ALoCoQlBAY/2cZ1QbDVZlc6m8vvyDX8jY3Uuhmd/1qzTlZ9Ujf2B0V05sokcFMUxLpYw6X63Tsdu Cc: " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:38:40 -0000 Hi, (speaking on my own, not to representing the LOADng authors). As was pointed out before, we often have discussed items that were not WG do= cuments, usually at the end of the meeting, to make sure that there is enoug= h time for WG items. I also agree with what Stan said: MANET should not be s= tandardizing documents that are mainly focused on LLNs; however, a document t= hat is focused on MANETS, and as a matter of fact is also used in LLN deploy= ments should be acceptable, in my opinion. We are currently finalizing some internal discussions between the authors of= LOADng, and I think that there will be an email to the list on that regards= in the next few days. Abdussalam, being against presentation of something t= hat has not even been proposed yet is premature and pointless, in my opinion= .=20 Best regards Ulrich On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" wrote: > I think you are in violent agreement. The current LOADng draft is (IIRC) a= imed at LLNs, so Teco is saying unless there's a new MANET-oriented version i= t shouldn't be discussed, and you are saying it won't be discussed. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: 12 October 2012 15:12 > To: Teco Boot > Cc: Dearlove, Christopher (UK); List; Bo Berry (boberry) > Subject: Re: [manet] MANET meeting at IETF85 >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >=20 >> On July 31th, our chair provided guidance on handling LOADng. >> It shows the way forward. >>=20 >> I'm looking forward to an draft-author-manet-loadng-00 draft, submitted b= efore next Monday. >> If there is no such draft, and little time to discuss non-wg drafts, we s= hould not discuss an lln draft in our meeting in Atlanta. >=20 > One (not too) fine point - we (the MANET WG) will *not* be discussing an L= LN draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols.=20 >=20 > Stan >=20 >=20 >> I'm OK on discussions on how to fulfill our charter item on a reactive pr= otocol. >>=20 >> Teco=20 >>=20 >>=20 >> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende g= eschreven: >>=20 >>> We have often discussed things not yet accepted by the WG, it can be a s= tep towards getting them accepted. >>>=20 >>> That's not a comment for or against LOADng, discussing LOADng, or adopti= ng LOADng, just an observation on what has happened in the past. >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Bo Berry >>> Sent: 12 October 2012 13:40 >>> To: Abdussalam Baryun; List; Bo Berry >>> Subject: Re: [manet] MANET meeting at IETF85 >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Looking at the MANET WG Documents page, LOADng is not on the list. So un= til LOADng is accepted by the WG, gotta agree with Abdussalam, no need to di= scuss it in the little time we have for the work we've already accepted. >>>=20 >>> How does this fit into the WG Charter? >>>=20 >>> -Bo >>>=20 >>>=20 >>> Active Internet-Drafts >>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) =20 >>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Ne= ighborhood Discovery Protocol =20 >>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timesta= mps For Router Admittance in NHDP =20 >>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol v= ersion 2 >>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mob= ile Ad Hoc Network (MANET) Routing=20 >>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the O= ptimized Link State Routing Protocol=20 >>>=20 >>>=20 >>>=20 >>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>=20 >>>> I've seen a number of emails on the alias but not sure LOADng=20 >>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>> draft? >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>=20 >>>>> Please note that I strongly object any including of LOADng draft in th= e Agenda. >>>>> The document is not for MANET, was already presented before, and the >>>>> authors are not discussing on ietf lists of any progress. The draft is= >>>>> not reasonable for the WG, if it is not discussed on the MANET list. >>>>>=20 >>>>> I got no reasonable reply to all my efforts, the last as: >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>=20 >>>>> AB >>>>> On 10/9/12, Ulrich Herberg wrote: >>>>>> Hi, >>>>>>=20 >>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Sal= on A. >>>>>> If you intend to present something, please send a request to the chai= rs. >>>>>>=20 >>>>>> Best regards >>>>>> Ulrich >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --- >>>> We cannot solve our problems with the same thinking we used when we cre= ated them.=20 >>>> Albert Einstein >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> --- >>> We cannot solve our problems with the same thinking we used when we crea= ted them.=20 >>> Albert Einstein >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Fri Oct 12 08:54:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D63921F8690 for ; Fri, 12 Oct 2012 08:54:58 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd5cEKM8-OtE for ; Fri, 12 Oct 2012 08:54:57 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E47C121F86C7 for ; Fri, 12 Oct 2012 08:54:56 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so118489wib.13 for ; Fri, 12 Oct 2012 08:54:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ABmj2CgqRANvcO62vS4uhVdVtAn/vciVrxVj2GemWK4=; b=cNWrQjpuZNK5A7miLSm1rGKD3cqIgX/ENEGX26uiSN7itPyXhGuphDvF26A2JGWAvV W9ku3iJaentS70JiZ0bpDk3x5kDQuYHIgze414aYHavqk/xGX5BWxFsm1Li7o8bnYfpK wclB48XrtyfxQeuHI7/gzyl18QfdWUWe+C/sUn+cb3Dbs412zBouhLQ0tC9akfFyll/E EGnRpMvGNn3YQoiGz5Fxy7/NWsB9mApKWuhWECYHinuU0nkmafRLgYZWE9SyesdF+i2P cW4VS6NLFTgINrUA/BRpoS9HW7QJDy3Lzv+Tqtxh/ry+6o5C3MvjjmP50vf6FMMeUNBT CDag== Received: by 10.216.132.223 with SMTP id o73mr2820423wei.69.1350057295487; Fri, 12 Oct 2012 08:54:55 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id dt9sm3802580wib.1.2012.10.12.08.54.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 08:54:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 12 Oct 2012 17:54:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnLpjN/PdzKHdGw/xEuaclXcQk4o4LsAphNlH5S8/hyVVKsl6oIVfesYo2d80CiyrQaQ+UN Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:54:58 -0000 I assume the authors take the guidance from our chair, posted in: http://www.ietf.org/mail-archive/web/manet/current/msg13305.html If so, I do not see a reason not to discuss LOADng. And yes, I am with Stan we will *not* discuss LLN topics in MANET = meetings. Teco Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: > Hi, >=20 > (speaking on my own, not to representing the LOADng authors). >=20 > As was pointed out before, we often have discussed items that were not = WG documents, usually at the end of the meeting, to make sure that there = is enough time for WG items. I also agree with what Stan said: MANET = should not be standardizing documents that are mainly focused on LLNs; = however, a document that is focused on MANETS, and as a matter of fact = is also used in LLN deployments should be acceptable, in my opinion. >=20 > We are currently finalizing some internal discussions between the = authors of LOADng, and I think that there will be an email to the list = on that regards in the next few days. Abdussalam, being against = presentation of something that has not even been proposed yet is = premature and pointless, in my opinion.=20 >=20 > Best regards > Ulrich >=20 > On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" = wrote: >=20 >> I think you are in violent agreement. The current LOADng draft is = (IIRC) aimed at LLNs, so Teco is saying unless there's a new = MANET-oriented version it shouldn't be discussed, and you are saying it = won't be discussed. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >> Sent: 12 October 2012 15:12 >> To: Teco Boot >> Cc: Dearlove, Christopher (UK); List; Bo Berry = (boberry) >> Subject: Re: [manet] MANET meeting at IETF85 >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >>=20 >>> On July 31th, our chair provided guidance on handling LOADng. >>> It shows the way forward. >>>=20 >>> I'm looking forward to an draft-author-manet-loadng-00 draft, = submitted before next Monday. >>> If there is no such draft, and little time to discuss non-wg drafts, = we should not discuss an lln draft in our meeting in Atlanta. >>=20 >> One (not too) fine point - we (the MANET WG) will *not* be discussing = an LLN draft. At any time. That would be a charter violation - LLN's are = defined and worked in ROLL. We are discussing MANET reactive protocols.=20= >>=20 >> Stan >>=20 >>=20 >>> I'm OK on discussions on how to fulfill our charter item on a = reactive protocol. >>>=20 >>> Teco=20 >>>=20 >>>=20 >>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het = volgende geschreven: >>>=20 >>>> We have often discussed things not yet accepted by the WG, it can = be a step towards getting them accepted. >>>>=20 >>>> That's not a comment for or against LOADng, discussing LOADng, or = adopting LOADng, just an observation on what has happened in the past. >>>>=20 >>>> --=20 >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Bo Berry >>>> Sent: 12 October 2012 13:40 >>>> To: Abdussalam Baryun; List; Bo Berry >>>> Subject: Re: [manet] MANET meeting at IETF85 >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> Looking at the MANET WG Documents page, LOADng is not on the list. = So until LOADng is accepted by the WG, gotta agree with Abdussalam, no = need to discuss it in the little time we have for the work we've already = accepted. >>>>=20 >>>> How does this fit into the WG Charter? >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>> Active Internet-Drafts >>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) = =20 >>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for = the Neighborhood Discovery Protocol =20 >>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and = Timestamps For Router Admittance in NHDP =20 >>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing = Protocol version 2 >>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for = the Mobile Ad Hoc Network (MANET) Routing=20 >>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for = the Optimized Link State Routing Protocol=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>>=20 >>>>> I've seen a number of emails on the alias but not sure LOADng=20 >>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>>> draft? >>>>>=20 >>>>> -Bo >>>>>=20 >>>>>=20 >>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Please note that I strongly object any including of LOADng draft = in the Agenda. >>>>>> The document is not for MANET, was already presented before, and = the >>>>>> authors are not discussing on ietf lists of any progress. The = draft is >>>>>> not reasonable for the WG, if it is not discussed on the MANET = list. >>>>>>=20 >>>>>> I got no reasonable reply to all my efforts, the last as: >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>>=20 >>>>>> AB >>>>>> On 10/9/12, Ulrich Herberg wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm = in Salon A. >>>>>>> If you intend to present something, please send a request to the = chairs. >>>>>>>=20 >>>>>>> Best regards >>>>>>> Ulrich >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when = we created them.=20 >>>>> Albert Einstein >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --- >>>> We cannot solve our problems with the same thinking we used when we = created them.=20 >>>> Albert Einstein >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> = ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> = ******************************************************************** >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Fri Oct 12 10:38:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B6521F87B9 for ; Fri, 12 Oct 2012 10:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRRnfDt37bYS for ; Fri, 12 Oct 2012 10:38:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 10E1521F86C1 for ; Fri, 12 Oct 2012 10:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5635; q=dns/txt; s=iport; t=1350063529; x=1351273129; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=trvDm6h3rbcSqfESsgW64vb7Af252KE9C/iuu0fDd7w=; b=LcwVj79i2fj75EySF8zznKv3v0GMaRwqzPfMm3HzOmvBzpj7TSh4XajV 0Iu3GPKENXxvnCa6BWH1lqfYAAtJuRPCh2OHd0ecsp5TCMsNuk81cAOHB iIFb34fwhCN3c4q/xv9aO1SNlgr8+MtTC+TahpQMe4AmgvO44kZVsWq5z I=; X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="131054326" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Oct 2012 17:38:48 +0000 Received: from dhcp-64-102-54-131.cisco.com (dhcp-64-102-54-131.cisco.com [64.102.54.131]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CHcm35020021; Fri, 12 Oct 2012 17:38:48 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Fri, 12 Oct 2012 13:38:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> To: Teco Boot X-Mailer: Apple Mail (2.1085) Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:38:50 -0000 Hi Teco, thanks for the clarification. Discussion in-line. -Bo On Oct 12, 2012, at 11:31 AM, Teco Boot wrote: >=20 > Op 12 okt. 2012, om 16:20 heeft Bo Berry het volgende geschreven: >=20 >> Teco, >> I'm trying to understand, but having trouble. Are we talking about = rolling back metrics to a previous state? > I did not have "roll back to a previous state, please" in mind. >=20 >> If so, the radio can simply send a new set of metrics. Using metrics = from some time back makes no sense to me and computing/making a routing = change with old data seems dangerous. How much history does the router = keep? =20 > None. Radio is responsible to get the information bases on radio and = router in sync. >=20 >>=20 >> Help me understand. > Example scenario, with minimal exchanged data: > Radio sends Peer Discovery, ID only > Router sends Peer Offer, ID only > Radio sends Peer Offer Ack, ID and Status =20 > Radio sends Neighbor Up, ID and MAC. > Router sends Neighbor Up Ack, ID and MAC > Now, there is no RLQ for that neighbor in the information base in the = router. > Radio sends Neighbor Update, ID, MAC and RLQ. > (Router should send Neighbor Update Ack, ID and MAC) > Now, we have the RLQ. >=20 > By some magic, the RLQ becomes invalid. Could be antenna switch, = modulation switch or even an RF engine switch. > Assume neighbor does not go into down state. > How can the radio send a message to the router that the RLQ is in = UNKNOW state again, just as right after the UP state? No magic here, metrics constantly change. The rate that the radio = reports metrics will depend upon the design, some may report at periodic = intervals some may be event driven. In any case, it is important for = the radio to provide heuristics that dampen the rate of metric updates, = such as crossing thresholds or percent change from previous. For = example, a radio may calculate metrics every 100ms. Each epoch the = metrics are filtered through the heuristics, if conditions merit, the = update is sent.=20 The router calculates an updated route cost upon receiving the metrics. = The effect of the newly computed route cost is run through heuristics so = not to over drive route/link cost updates. Of course the cost = calculation and the heuristics are unique per routing protocol. For = example, the newly calculated link cost could be compared to the = current, if conditions merit, the new link cost is inserted from which = the routing protocol floods/updates. Since the raw data for calculating metrics is in the radio, the radio = should send a new neighbor update with the new calculations. If the RLQ = is no longer valid other parameters will be changing. =20 Similar fashion, the radio heuristics to determine the presence of a new = neighbor from which a neighbor up is generated will be important. So to = the radio heuristics when deciding to generate the neighbor down. Typing this response does help me understand your perspective. Between = sending a new update message to indicate a single metric is no longer = valid and back-up, compared to a new set of metrics, I'd rather have the = most current metrics. > This can happen with 802.11 CDR. The routing hello protocol detects = symmetrical connectivity. Until there is some unicast traffic, data rate = is unknown. The DLEP radio may start providing CDR after adaptive rate = selection. It may want to revoke stale information. > I do not say an 802.11 radio should behave like this. >=20 > Teco >=20 >=20 >>=20 >> -Bo >>=20 >>=20 >> On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >>=20 >>>=20 >>> On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >>>=20 >>>> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>=20 >>>>>>> It's hard to insert even generic, "hand-waving" level text >>>> .... >>>>> So, basically what I'm saying is "Tell me what you want this to = say. I'll cut and paste your text into the document." >>>>=20 >>>>=20 >>>> The UNKNOWN condition does not apply to RLQ only. Resources is = somewhat equivalent. In fact all TLVs can be unknown, just after = Neighbor Up and no optional TLVs, and no info from peer. Also, the = protocol is not complete if there is no way to get back to a previous = state of the information base. >>>> I straightforward solution is to have a method to revoke everything = that is send before. >>>=20 >>> That depends on how you define "everything that is sent before". If, = for instance, this was the 10th metric update, are you talking about = rolling back to the 9th update? If so, I'm opposed. That's a huge burden = on the router. If you're talking about clearing out a metric value and = setting it to some defined value, like the router's defaults, then I'm = OK with that.=20 >>>=20 >>>=20 >>>=20 >>>> Length=3D0 or the existing drop indicator. Text would be: >>>>=20 >>>> Length - (the value for TLV with info) >>>> A zero length can be used to revoke previous provided = information for this Data Item TLV. >>>>=20 >>>> This could also be used to override the peer provided defaults. >>>=20 >>> Overriding the defaults makes no sense to me.=20 >>>=20 >>> Stan >>>=20 >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we = created them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >=20 --- We cannot solve our problems with the same thinking we used when we = created them.=20 Albert Einstein From teco@inf-net.nl Fri Oct 12 10:58:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B171A21F87A2 for ; Fri, 12 Oct 2012 10:58:20 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzl58QshwL0R for ; Fri, 12 Oct 2012 10:58:20 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55B21F8782 for ; Fri, 12 Oct 2012 10:58:18 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1709924wgb.13 for ; Fri, 12 Oct 2012 10:58:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=aRdd+hz89pvihwsXn9M05mrdTy06VfntKurtI2CgKgA=; b=MFFtSwqVrlC7cq4c1fXKfXvOjYV30voVe0uU8+2tdEKaJK2Sqe/KcavVG4oPpZBECJ Ol0I7GSkOmIJ+jWlrXS1b5BOimfdrfS6uFmQQJkPC4HK5S3AYv9/WRSTRc35oA8GUv3a XADhkVtclA4YDwZuyHuIq9pzhyx+JylNHBTwRPqSXqAwJl15TpmBMkx3b+oXTQs/1m+g oEUEdAzdCoKUcWQYt3o9Vjj+M4XKLQOkJduEW1eYjPr/U+/c54dRTj8KMejbrfinVObm huUrj9eqw4rEP0cJ5hJNr4UV5Gny/QQWLCIxrbkzpspzBwwZaFJQK8ZKRUH+//EGFFLt jSwg== Received: by 10.216.140.11 with SMTP id d11mr2917977wej.29.1350064697735; Fri, 12 Oct 2012 10:58:17 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id cn6sm4873507wib.9.2012.10.12.10.58.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 10:58:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 12 Oct 2012 19:58:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkH3IGfhKSljwxkyqfeRN4KoQV47XqG0CVj8J+Df0Erwo8v9e8U4wXehVMeMV7BXHfU1/zn Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:58:20 -0000 Op 12 okt. 2012, om 19:38 heeft Bo Berry het volgende geschreven: > Hi Teco, thanks for the clarification. Discussion in-line. > -Bo >=20 >=20 > On Oct 12, 2012, at 11:31 AM, Teco Boot wrote: >=20 >>=20 >> Op 12 okt. 2012, om 16:20 heeft Bo Berry het volgende geschreven: >>=20 >>> Teco, >>> I'm trying to understand, but having trouble. Are we talking about = rolling back metrics to a previous state? >> I did not have "roll back to a previous state, please" in mind. >>=20 >>> If so, the radio can simply send a new set of metrics. Using = metrics from some time back makes no sense to me and computing/making a = routing change with old data seems dangerous. How much history does the = router keep? =20 >> None. Radio is responsible to get the information bases on radio and = router in sync. >>=20 >>>=20 >>> Help me understand. >> Example scenario, with minimal exchanged data: >> Radio sends Peer Discovery, ID only >> Router sends Peer Offer, ID only >> Radio sends Peer Offer Ack, ID and Status =20 >> Radio sends Neighbor Up, ID and MAC. >> Router sends Neighbor Up Ack, ID and MAC >> Now, there is no RLQ for that neighbor in the information base in the = router. >> Radio sends Neighbor Update, ID, MAC and RLQ. >> (Router should send Neighbor Update Ack, ID and MAC) >> Now, we have the RLQ. >>=20 >> By some magic, the RLQ becomes invalid. Could be antenna switch, = modulation switch or even an RF engine switch. >> Assume neighbor does not go into down state. >> How can the radio send a message to the router that the RLQ is in = UNKNOW state again, just as right after the UP state? >=20 > No magic here, metrics constantly change. The rate that the radio = reports metrics will depend upon the design, some may report at periodic = intervals some may be event driven. In any case, it is important for = the radio to provide heuristics that dampen the rate of metric updates, = such as crossing thresholds or percent change from previous. For = example, a radio may calculate metrics every 100ms. Each epoch the = metrics are filtered through the heuristics, if conditions merit, the = update is sent.=20 >=20 > The router calculates an updated route cost upon receiving the = metrics. The effect of the newly computed route cost is run through = heuristics so not to over drive route/link cost updates. Of course the = cost calculation and the heuristics are unique per routing protocol. = For example, the newly calculated link cost could be compared to the = current, if conditions merit, the new link cost is inserted from which = the routing protocol floods/updates. >=20 > Since the raw data for calculating metrics is in the radio, the radio = should send a new neighbor update with the new calculations. If the RLQ = is no longer valid other parameters will be changing. =20 >=20 > Similar fashion, the radio heuristics to determine the presence of a = new neighbor from which a neighbor up is generated will be important. = So to the radio heuristics when deciding to generate the neighbor down. >=20 > Typing this response does help me understand your perspective. = Between sending a new update message to indicate a single metric is no = longer valid and back-up, compared to a new set of metrics, I'd rather = have the most current metrics. I don't follow. Do you suggest the router should keep using the now = outdated metrics, for as long as the radio cannot provide an information = element? State_1: router calculated metric_1, RLQ was not available State_2: router calculated metric_2, RLQ was available State_3: RLQ is not available, router cannot calculate a metric My opinion: in state_3, router has to be able to calculate a metric_3 = which would be equal to metric_1. Keep using metric_2 is wrong. Teco >=20 >=20 >> This can happen with 802.11 CDR. The routing hello protocol detects = symmetrical connectivity. Until there is some unicast traffic, data rate = is unknown. The DLEP radio may start providing CDR after adaptive rate = selection. It may want to revoke stale information. >> I do not say an 802.11 radio should behave like this. >>=20 >> Teco >>=20 >>=20 >>>=20 >>> -Bo >>>=20 >>>=20 >>> On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >>>=20 >>>>=20 >>>> On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >>>>=20 >>>>> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>=20 >>>>>>>> It's hard to insert even generic, "hand-waving" level text >>>>> .... >>>>>> So, basically what I'm saying is "Tell me what you want this to = say. I'll cut and paste your text into the document." >>>>>=20 >>>>>=20 >>>>> The UNKNOWN condition does not apply to RLQ only. Resources is = somewhat equivalent. In fact all TLVs can be unknown, just after = Neighbor Up and no optional TLVs, and no info from peer. Also, the = protocol is not complete if there is no way to get back to a previous = state of the information base. >>>>> I straightforward solution is to have a method to revoke = everything that is send before. >>>>=20 >>>> That depends on how you define "everything that is sent before". = If, for instance, this was the 10th metric update, are you talking about = rolling back to the 9th update? If so, I'm opposed. That's a huge burden = on the router. If you're talking about clearing out a metric value and = setting it to some defined value, like the router's defaults, then I'm = OK with that.=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Length=3D0 or the existing drop indicator. Text would be: >>>>>=20 >>>>> Length - (the value for TLV with info) >>>>> A zero length can be used to revoke previous provided = information for this Data Item TLV. >>>>>=20 >>>>> This could also be used to override the peer provided defaults. >>>>=20 >>>> Overriding the defaults makes no sense to me.=20 >>>>=20 >>>> Stan >>>>=20 >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> --- >>> We cannot solve our problems with the same thinking we used when we = created them.=20 >>> Albert Einstein >>>=20 >>>=20 >>>=20 >>=20 >=20 > --- > We cannot solve our problems with the same thinking we used when we = created them.=20 > Albert Einstein >=20 >=20 >=20 From sratliff@cisco.com Fri Oct 12 11:02:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7274E21F8445 for ; Fri, 12 Oct 2012 11:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX0U+qeI3G2h for ; Fri, 12 Oct 2012 11:02:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5B74D21F843F for ; Fri, 12 Oct 2012 11:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6716; q=dns/txt; s=iport; t=1350064945; x=1351274545; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H6ghYtbVktOBpHo03zubpt1x3XNqJn4xt2PYWGhbi14=; b=e2eBj0Yv8leaj9bWKxrFR8soiYSVI9yB0GtUVqG1FI8Fe4Ow4nPXDjZC R5fnMPs1ItGjNfS2yyWPwYOmGSxGNUEnpJy5o1ChZ2KUzCR6Hx14Wo8mB MmSIh34CpGaC51bLia7KGziLHJVblDtzmpGmoniFPrXQAh2lq1rGJ8lvd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMtaeFCtJXG8/2dsb2JhbABFv2WBCIIgAQEBAwESASc/EAIBCBgKFBAyJQIEDg0TB4dcBppjoA6LUoVdYAOSApIwgWuCbYFaIRw X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="131061705" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2012 18:02:24 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CI2Ode014990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 18:02:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 13:02:24 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4CAAAUlAIAAE+oAgAAjnQCAAAVpAIAAASmA Date: Fri, 12 Oct 2012 18:02:23 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> In-Reply-To: <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--53.112700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <2736AEF526F92C4DB8EEAF00394BDF6B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:02:26 -0000 On Oct 12, 2012, at 1:58 PM, Teco Boot wrote: >=20 > Op 12 okt. 2012, om 19:38 heeft Bo Berry het volgende geschreven: >=20 >> Hi Teco, thanks for the clarification. Discussion in-line. >> -Bo >>=20 >>=20 >> On Oct 12, 2012, at 11:31 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 12 okt. 2012, om 16:20 heeft Bo Berry het volgende geschreven: >>>=20 >>>> Teco, >>>> I'm trying to understand, but having trouble. Are we talking about rol= ling back metrics to a previous state? >>> I did not have "roll back to a previous state, please" in mind. >>>=20 >>>> If so, the radio can simply send a new set of metrics. Using metrics = from some time back makes no sense to me and computing/making a routing cha= nge with old data seems dangerous. How much history does the router keep? = =20 >>> None. Radio is responsible to get the information bases on radio and ro= uter in sync. >>>=20 >>>>=20 >>>> Help me understand. >>> Example scenario, with minimal exchanged data: >>> Radio sends Peer Discovery, ID only >>> Router sends Peer Offer, ID only >>> Radio sends Peer Offer Ack, ID and Status =20 >>> Radio sends Neighbor Up, ID and MAC. >>> Router sends Neighbor Up Ack, ID and MAC >>> Now, there is no RLQ for that neighbor in the information base in the r= outer. >>> Radio sends Neighbor Update, ID, MAC and RLQ. >>> (Router should send Neighbor Update Ack, ID and MAC) >>> Now, we have the RLQ. >>>=20 >>> By some magic, the RLQ becomes invalid. Could be antenna switch, modula= tion switch or even an RF engine switch. >>> Assume neighbor does not go into down state. >>> How can the radio send a message to the router that the RLQ is in UNKNO= W state again, just as right after the UP state? >>=20 >> No magic here, metrics constantly change. The rate that the radio report= s metrics will depend upon the design, some may report at periodic interval= s some may be event driven. In any case, it is important for the radio to = provide heuristics that dampen the rate of metric updates, such as crossing= thresholds or percent change from previous. For example, a radio may calc= ulate metrics every 100ms. Each epoch the metrics are filtered through the= heuristics, if conditions merit, the update is sent.=20 >>=20 >> The router calculates an updated route cost upon receiving the metrics. = The effect of the newly computed route cost is run through heuristics so n= ot to over drive route/link cost updates. Of course the cost calculation a= nd the heuristics are unique per routing protocol. For example, the newly = calculated link cost could be compared to the current, if conditions merit,= the new link cost is inserted from which the routing protocol floods/updat= es. >>=20 >> Since the raw data for calculating metrics is in the radio, the radio sh= ould send a new neighbor update with the new calculations. If the RLQ is n= o longer valid other parameters will be changing. =20 >>=20 >> Similar fashion, the radio heuristics to determine the presence of a new= neighbor from which a neighbor up is generated will be important. So to t= he radio heuristics when deciding to generate the neighbor down. >>=20 >> Typing this response does help me understand your perspective. Between = sending a new update message to indicate a single metric is no longer valid= and back-up, compared to a new set of metrics, I'd rather have the most cu= rrent metrics. >=20 > I don't follow. Do you suggest the router should keep using the now outda= ted metrics, for as long as the radio cannot provide an information element= ? >=20 > State_1: router calculated metric_1, RLQ was not available > State_2: router calculated metric_2, RLQ was available > State_3: RLQ is not available, router cannot calculate a metric >=20 > My opinion: in state_3, router has to be able to calculate a metric_3 whi= ch would be equal to metric_1. Keep using metric_2 is wrong. Specifically for the case of RLQ, do you expect the router's metric for "RL= Q not available" to be different from "RLQ =3D 0"? If so, why?=20 Stan >=20 > Teco >=20 >=20 >>=20 >>=20 >>> This can happen with 802.11 CDR. The routing hello protocol detects sym= metrical connectivity. Until there is some unicast traffic, data rate is un= known. The DLEP radio may start providing CDR after adaptive rate selection= . It may want to revoke stale information. >>> I do not say an 802.11 radio should behave like this. >>>=20 >>> Teco >>>=20 >>>=20 >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>> On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >>>>=20 >>>>>=20 >>>>> On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >>>>>=20 >>>>>> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het volgende= geschreven: >>>>>>=20 >>>>>>>>> It's hard to insert even generic, "hand-waving" level text >>>>>> .... >>>>>>> So, basically what I'm saying is "Tell me what you want this to say= . I'll cut and paste your text into the document." >>>>>>=20 >>>>>>=20 >>>>>> The UNKNOWN condition does not apply to RLQ only. Resources is somew= hat equivalent. In fact all TLVs can be unknown, just after Neighbor Up and= no optional TLVs, and no info from peer. Also, the protocol is not complet= e if there is no way to get back to a previous state of the information bas= e. >>>>>> I straightforward solution is to have a method to revoke everything = that is send before. >>>>>=20 >>>>> That depends on how you define "everything that is sent before". If, = for instance, this was the 10th metric update, are you talking about rollin= g back to the 9th update? If so, I'm opposed. That's a huge burden on the r= outer. If you're talking about clearing out a metric value and setting it t= o some defined value, like the router's defaults, then I'm OK with that.=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Length=3D0 or the existing drop indicator. Text would be: >>>>>>=20 >>>>>> Length - (the value for TLV with info) >>>>>> A zero length can be used to revoke previous provided inf= ormation for this Data Item TLV. >>>>>>=20 >>>>>> This could also be used to override the peer provided defaults. >>>>>=20 >>>>> Overriding the defaults makes no sense to me.=20 >>>>>=20 >>>>> Stan >>>>>=20 >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> --- >>>> We cannot solve our problems with the same thinking we used when we cr= eated them.=20 >>>> Albert Einstein >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> --- >> We cannot solve our problems with the same thinking we used when we crea= ted them.=20 >> Albert Einstein >>=20 >>=20 >>=20 >=20 From teco@inf-net.nl Sat Oct 13 01:03:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7269D21F867C for ; Sat, 13 Oct 2012 01:03:03 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iEYJoxszD72 for ; Sat, 13 Oct 2012 01:03:02 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3381E21F865F for ; Sat, 13 Oct 2012 01:03:01 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2328237wey.31 for ; Sat, 13 Oct 2012 01:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=RdOobGk1AApZBnqfeXCqsvIPAv4XTXzh4ecC10L7Fl4=; b=KS3vlXIxScTIl2dDV/9V/l+W0Zhw1O2KRgi7GgTegZnfmwAidZq+bV65EgnCq6C1Kl NDzHfnv7xi9F3JlUocHeVRoh0FCZX7LHeSXCG2NN7Wudn0lU2+0Q3aouj2U8y4j5p+iT y35N42yMTwtNIK+TxyUQZMtyiqwth17JK5CczhrlTbZiFIMhTT5IxrMLdIVAZ0K9Htmg UZvre4GOeVgJpR5+xf9LgM4dapT7cFp1FfGKbNuvOQbamgbVuEJoYkAamZiNc+kfmuz2 cKLxUfoHyQ1JkSbDFHLXQV61+avwb2cPG1gim5f3vWz0cF4MLYNPIq/5ISD3UCxjJRlh cuJg== Received: by 10.180.83.101 with SMTP id p5mr11150612wiy.2.1350115380745; Sat, 13 Oct 2012 01:03:00 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id cu1sm1690886wib.6.2012.10.13.01.02.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 01:02:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> Date: Sat, 13 Oct 2012 10:02:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQn2yCiZwIPXZl0k8ga/VEwzk6YbkmwlAMxVW5MGR+LOQn96L+Y42Vs+nWdJ520En5bD02M2 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 08:03:03 -0000 Op 12 okt. 2012, om 20:02 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Oct 12, 2012, at 1:58 PM, Teco Boot wrote: >=20 >>=20 >> Op 12 okt. 2012, om 19:38 heeft Bo Berry het volgende geschreven: >>=20 >>> Hi Teco, thanks for the clarification. Discussion in-line. >>> -Bo >>>=20 >>>=20 >>> On Oct 12, 2012, at 11:31 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 12 okt. 2012, om 16:20 heeft Bo Berry het volgende geschreven: >>>>=20 >>>>> Teco, >>>>> I'm trying to understand, but having trouble. Are we talking about = rolling back metrics to a previous state? >>>> I did not have "roll back to a previous state, please" in mind. >>>>=20 >>>>> If so, the radio can simply send a new set of metrics. Using = metrics from some time back makes no sense to me and computing/making a = routing change with old data seems dangerous. How much history does the = router keep? =20 >>>> None. Radio is responsible to get the information bases on radio = and router in sync. >>>>=20 >>>>>=20 >>>>> Help me understand. >>>> Example scenario, with minimal exchanged data: >>>> Radio sends Peer Discovery, ID only >>>> Router sends Peer Offer, ID only >>>> Radio sends Peer Offer Ack, ID and Status =20 >>>> Radio sends Neighbor Up, ID and MAC. >>>> Router sends Neighbor Up Ack, ID and MAC >>>> Now, there is no RLQ for that neighbor in the information base in = the router. >>>> Radio sends Neighbor Update, ID, MAC and RLQ. >>>> (Router should send Neighbor Update Ack, ID and MAC) >>>> Now, we have the RLQ. >>>>=20 >>>> By some magic, the RLQ becomes invalid. Could be antenna switch, = modulation switch or even an RF engine switch. >>>> Assume neighbor does not go into down state. >>>> How can the radio send a message to the router that the RLQ is in = UNKNOW state again, just as right after the UP state? >>>=20 >>> No magic here, metrics constantly change. The rate that the radio = reports metrics will depend upon the design, some may report at periodic = intervals some may be event driven. In any case, it is important for = the radio to provide heuristics that dampen the rate of metric updates, = such as crossing thresholds or percent change from previous. For = example, a radio may calculate metrics every 100ms. Each epoch the = metrics are filtered through the heuristics, if conditions merit, the = update is sent.=20 >>>=20 >>> The router calculates an updated route cost upon receiving the = metrics. The effect of the newly computed route cost is run through = heuristics so not to over drive route/link cost updates. Of course the = cost calculation and the heuristics are unique per routing protocol. = For example, the newly calculated link cost could be compared to the = current, if conditions merit, the new link cost is inserted from which = the routing protocol floods/updates. >>>=20 >>> Since the raw data for calculating metrics is in the radio, the = radio should send a new neighbor update with the new calculations. If = the RLQ is no longer valid other parameters will be changing. =20 >>>=20 >>> Similar fashion, the radio heuristics to determine the presence of a = new neighbor from which a neighbor up is generated will be important. = So to the radio heuristics when deciding to generate the neighbor down. >>>=20 >>> Typing this response does help me understand your perspective. = Between sending a new update message to indicate a single metric is no = longer valid and back-up, compared to a new set of metrics, I'd rather = have the most current metrics. >>=20 >> I don't follow. Do you suggest the router should keep using the now = outdated metrics, for as long as the radio cannot provide an information = element? >>=20 >> State_1: router calculated metric_1, RLQ was not available >> State_2: router calculated metric_2, RLQ was available >> State_3: RLQ is not available, router cannot calculate a metric >>=20 >> My opinion: in state_3, router has to be able to calculate a metric_3 = which would be equal to metric_1. Keep using metric_2 is wrong. >=20 > Specifically for the case of RLQ, do you expect the router's metric = for "RLQ not available" to be different from "RLQ =3D 0"? If so, why?=20 My point is that the DLEP protocol should be "complete", in that the = radio is able to get the router in a certain state, in another state and = get back in the earlier state. RLQ is just an example. If you think this makes no sense with the radios you have seen up to = now, you could be right. Tomorrow, you could have a different opinion. I = saw on this mailing list some of us see already the requirement the = protocol shall be "complete". Teco > Stan >=20 >=20 >>=20 >> Teco >>=20 >>=20 >>>=20 >>>=20 >>>> This can happen with 802.11 CDR. The routing hello protocol detects = symmetrical connectivity. Until there is some unicast traffic, data rate = is unknown. The DLEP radio may start providing CDR after adaptive rate = selection. It may want to revoke stale information. >>>> I do not say an 802.11 radio should behave like this. >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>>>=20 >>>>> -Bo >>>>>=20 >>>>>=20 >>>>> On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >>>>>=20 >>>>>>=20 >>>>>> On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >>>>>>=20 >>>>>>> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>>=20 >>>>>>>>>> It's hard to insert even generic, "hand-waving" level text >>>>>>> .... >>>>>>>> So, basically what I'm saying is "Tell me what you want this to = say. I'll cut and paste your text into the document." >>>>>>>=20 >>>>>>>=20 >>>>>>> The UNKNOWN condition does not apply to RLQ only. Resources is = somewhat equivalent. In fact all TLVs can be unknown, just after = Neighbor Up and no optional TLVs, and no info from peer. Also, the = protocol is not complete if there is no way to get back to a previous = state of the information base. >>>>>>> I straightforward solution is to have a method to revoke = everything that is send before. >>>>>>=20 >>>>>> That depends on how you define "everything that is sent before". = If, for instance, this was the 10th metric update, are you talking about = rolling back to the 9th update? If so, I'm opposed. That's a huge burden = on the router. If you're talking about clearing out a metric value and = setting it to some defined value, like the router's defaults, then I'm = OK with that.=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Length=3D0 or the existing drop indicator. Text would be: >>>>>>>=20 >>>>>>> Length - (the value for TLV with info) >>>>>>> A zero length can be used to revoke previous provided = information for this Data Item TLV. >>>>>>>=20 >>>>>>> This could also be used to override the peer provided defaults. >>>>>>=20 >>>>>> Overriding the defaults makes no sense to me.=20 >>>>>>=20 >>>>>> Stan >>>>>>=20 >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when = we created them.=20 >>>>> Albert Einstein >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> --- >>> We cannot solve our problems with the same thinking we used when we = created them.=20 >>> Albert Einstein >>>=20 >>>=20 >>>=20 >>=20 >=20 From jvasseur@cisco.com Sat Oct 13 02:21:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BC921F8534 for ; Sat, 13 Oct 2012 02:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.111 X-Spam-Level: X-Spam-Status: No, score=-10.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNXslXKXf+mI for ; Sat, 13 Oct 2012 02:21:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0681D21F845E for ; Sat, 13 Oct 2012 02:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9409; q=dns/txt; s=iport; t=1350120098; x=1351329698; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ibZQLYnoaj1lqXDJnnylLvL2zHFwS5+5TdbzGJ7hjHU=; b=Wo6RBxFupum7rCRTyEqmd8cGCg9E3BjRLly+AMu4Egc/K2Xre5ydVTJx 19mko99NNnsMMj5xEIViGFgmzEHXNrrVzBBuNU8Xj16H8YSHCAkAkXoZB yM/tM5Un6eHxLa4IpvkrVuuCINw9M3WCfyoS1KpFpV3/VugMc82X3ocBH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB4yeVCtJV2b/2dsb2JhbABFv2yBCIIgAQEBAwEBAQEPAUIZAwgFBwQCAQgRBAEBAQodBycLFAkIAgQOBQgBGYdcBgubcJ9fi1kUBgiFO2ADpDGBa4JtgVoJNA X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="130994544" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 13 Oct 2012 09:21:37 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9D9LbZG028897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 09:21:37 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 04:21:36 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqSQkw3/yOa6DPEOFC3k+zMdjAA== Date: Sat, 13 Oct 2012 09:21:35 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--67.729600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <9B2D896D8D7EFF43BD4225BA022E1698@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 09:21:40 -0000 Hi Ulrich, On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote: > Hi, >=20 > (speaking on my own, not to representing the LOADng authors). >=20 > As was pointed out before, we often have discussed items that were not WG= documents, usually at the end of the meeting, to make sure that there is e= nough time for WG items. I also agree with what Stan said: MANET should not= be standardizing documents that are mainly focused on LLNs; Just to make sure that we do not play with words =85. As agreed between the= chairs, it should read "MANET is standardizing documents that are not deal= ing with LLNs/IoT". This is much stronger that "mainly on LLNs" Thanks. JP.=20 > however, a document that is focused on MANETS, and as a matter of fact is= also used in LLN deployments should be acceptable, in my opinion. >=20 > We are currently finalizing some internal discussions between the authors= of LOADng, and I think that there will be an email to the list on that reg= ards in the next few days. Abdussalam, being against presentation of someth= ing that has not even been proposed yet is premature and pointless, in my o= pinion.=20 >=20 > Best regards > Ulrich >=20 > On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" wrote: >=20 >> I think you are in violent agreement. The current LOADng draft is (IIRC)= aimed at LLNs, so Teco is saying unless there's a new MANET-oriented versi= on it shouldn't be discussed, and you are saying it won't be discussed. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >> Sent: 12 October 2012 15:12 >> To: Teco Boot >> Cc: Dearlove, Christopher (UK); List; Bo Berry (boberry= ) >> Subject: Re: [manet] MANET meeting at IETF85 >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >>=20 >>> On July 31th, our chair provided guidance on handling LOADng. >>> It shows the way forward. >>>=20 >>> I'm looking forward to an draft-author-manet-loadng-00 draft, submitted= before next Monday. >>> If there is no such draft, and little time to discuss non-wg drafts, we= should not discuss an lln draft in our meeting in Atlanta. >>=20 >> One (not too) fine point - we (the MANET WG) will *not* be discussing an= LLN draft. At any time. That would be a charter violation - LLN's are defi= ned and worked in ROLL. We are discussing MANET reactive protocols.=20 >>=20 >> Stan >>=20 >>=20 >>> I'm OK on discussions on how to fulfill our charter item on a reactive = protocol. >>>=20 >>> Teco=20 >>>=20 >>>=20 >>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende= geschreven: >>>=20 >>>> We have often discussed things not yet accepted by the WG, it can be a= step towards getting them accepted. >>>>=20 >>>> That's not a comment for or against LOADng, discussing LOADng, or adop= ting LOADng, just an observation on what has happened in the past. >>>>=20 >>>> --=20 >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf= Of Bo Berry >>>> Sent: 12 October 2012 13:40 >>>> To: Abdussalam Baryun; List; Bo Berry >>>> Subject: Re: [manet] MANET meeting at IETF85 >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> Looking at the MANET WG Documents page, LOADng is not on the list. So = until LOADng is accepted by the WG, gotta agree with Abdussalam, no need to= discuss it in the little time we have for the work we've already accepted. >>>>=20 >>>> How does this fit into the WG Charter? >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>> Active Internet-Drafts >>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) =20 >>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the = Neighborhood Discovery Protocol =20 >>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Times= tamps For Router Admittance in NHDP =20 >>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protoco= l version 2 >>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the M= obile Ad Hoc Network (MANET) Routing=20 >>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for th= e Optimized Link State Routing Protocol=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>>=20 >>>>> I've seen a number of emails on the alias but not sure LOADng=20 >>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>>> draft? >>>>>=20 >>>>> -Bo >>>>>=20 >>>>>=20 >>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Please note that I strongly object any including of LOADng draft in = the Agenda. >>>>>> The document is not for MANET, was already presented before, and the >>>>>> authors are not discussing on ietf lists of any progress. The draft = is >>>>>> not reasonable for the WG, if it is not discussed on the MANET list. >>>>>>=20 >>>>>> I got no reasonable reply to all my efforts, the last as: >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>>=20 >>>>>> AB >>>>>> On 10/9/12, Ulrich Herberg wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in S= alon A. >>>>>>> If you intend to present something, please send a request to the ch= airs. >>>>>>>=20 >>>>>>> Best regards >>>>>>> Ulrich >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when we c= reated them.=20 >>>>> Albert Einstein >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --- >>>> We cannot solve our problems with the same thinking we used when we cr= eated them.=20 >>>> Albert Einstein >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> ******************************************************************** >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Sat Oct 13 02:22:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40921F855D for ; Sat, 13 Oct 2012 02:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96GncJWX3jUy for ; Sat, 13 Oct 2012 02:22:12 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2990D21F8554 for ; Sat, 13 Oct 2012 02:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9767; q=dns/txt; s=iport; t=1350120132; x=1351329732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+8MDD0n8e6H+TWRU4q0N9cUBr+3OuT/3DhVGj3B68io=; b=m1LOZ5/GCpswYL2NzlU/Hf2dyiVwlUK6N4SKUL6QkWcuZD3Pl1E86UGp zfYiGzSxgmSPbqgqYmPgUnjIBrtOOO00eN2a97LPCdU5ZVJzXvddID679 3sYdUoS16S9AUYmd3g4CBMbq06kYiEz9xxm4QiqbnaJ+p9EzlFw5DxOWS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAB4yeVCtJV2c/2dsb2JhbABFv2yBCIIgAQEBAwEBAQEPAScbGQMIBQcEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCAEZh1wGC5twn1+LWRQGCIU7YAOkMYFrgm2BWgk0 X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131253647" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 13 Oct 2012 09:22:10 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9D9MA4S002294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 09:22:10 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 04:22:10 -0500 From: "JP Vasseur (jvasseur)" To: Teco Boot Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqSQ4w3/yOa6DPEOFC3k+zMdjAA== Date: Sat, 13 Oct 2012 09:22:09 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD33AC@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--70.731800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0FF6FED0956F9444839AE02AEDC0106F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 09:22:13 -0000 On Oct 12, 2012, at 5:54 PM, Teco Boot wrote: > I assume the authors take the guidance from our chair, posted in: > http://www.ietf.org/mail-archive/web/manet/current/msg13305.html >=20 > If so, I do not see a reason not to discuss LOADng. > And yes, I am with Stan we will *not* discuss LLN topics in MANET meeting= s. Agreed. Thanks. JP. >=20 > Teco >=20 > Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: >=20 >> Hi, >>=20 >> (speaking on my own, not to representing the LOADng authors). >>=20 >> As was pointed out before, we often have discussed items that were not W= G documents, usually at the end of the meeting, to make sure that there is = enough time for WG items. I also agree with what Stan said: MANET should no= t be standardizing documents that are mainly focused on LLNs; however, a do= cument that is focused on MANETS, and as a matter of fact is also used in L= LN deployments should be acceptable, in my opinion. >>=20 >> We are currently finalizing some internal discussions between the author= s of LOADng, and I think that there will be an email to the list on that re= gards in the next few days. Abdussalam, being against presentation of somet= hing that has not even been proposed yet is premature and pointless, in my = opinion.=20 >>=20 >> Best regards >> Ulrich >>=20 >> On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" wrote: >>=20 >>> I think you are in violent agreement. The current LOADng draft is (IIRC= ) aimed at LLNs, so Teco is saying unless there's a new MANET-oriented vers= ion it shouldn't be discussed, and you are saying it won't be discussed. >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>> Sent: 12 October 2012 15:12 >>> To: Teco Boot >>> Cc: Dearlove, Christopher (UK); List; Bo Berry (boberr= y) >>> Subject: Re: [manet] MANET meeting at IETF85 >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >>>=20 >>>> On July 31th, our chair provided guidance on handling LOADng. >>>> It shows the way forward. >>>>=20 >>>> I'm looking forward to an draft-author-manet-loadng-00 draft, submitte= d before next Monday. >>>> If there is no such draft, and little time to discuss non-wg drafts, w= e should not discuss an lln draft in our meeting in Atlanta. >>>=20 >>> One (not too) fine point - we (the MANET WG) will *not* be discussing a= n LLN draft. At any time. That would be a charter violation - LLN's are def= ined and worked in ROLL. We are discussing MANET reactive protocols.=20 >>>=20 >>> Stan >>>=20 >>>=20 >>>> I'm OK on discussions on how to fulfill our charter item on a reactive= protocol. >>>>=20 >>>> Teco=20 >>>>=20 >>>>=20 >>>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgend= e geschreven: >>>>=20 >>>>> We have often discussed things not yet accepted by the WG, it can be = a step towards getting them accepted. >>>>>=20 >>>>> That's not a comment for or against LOADng, discussing LOADng, or ado= pting LOADng, just an observation on what has happened in the past. >>>>>=20 >>>>> --=20 >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>=20 >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Ce= ntre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f Of Bo Berry >>>>> Sent: 12 October 2012 13:40 >>>>> To: Abdussalam Baryun; List; Bo Berry >>>>> Subject: Re: [manet] MANET meeting at IETF85 >>>>>=20 >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>>=20 >>>>> Looking at the MANET WG Documents page, LOADng is not on the list. So= until LOADng is accepted by the WG, gotta agree with Abdussalam, no need t= o discuss it in the little time we have for the work we've already accepted= . >>>>>=20 >>>>> How does this fit into the WG Charter? >>>>>=20 >>>>> -Bo >>>>>=20 >>>>>=20 >>>>> Active Internet-Drafts >>>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) = =20 >>>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the= Neighborhood Discovery Protocol =20 >>>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Time= stamps For Router Admittance in NHDP =20 >>>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protoc= ol version 2 >>>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the = Mobile Ad Hoc Network (MANET) Routing=20 >>>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for t= he Optimized Link State Routing Protocol=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>>>=20 >>>>>> I've seen a number of emails on the alias but not sure LOADng=20 >>>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>>>> draft? >>>>>>=20 >>>>>> -Bo >>>>>>=20 >>>>>>=20 >>>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>>>=20 >>>>>>> Please note that I strongly object any including of LOADng draft in= the Agenda. >>>>>>> The document is not for MANET, was already presented before, and th= e >>>>>>> authors are not discussing on ietf lists of any progress. The draft= is >>>>>>> not reasonable for the WG, if it is not discussed on the MANET list= . >>>>>>>=20 >>>>>>> I got no reasonable reply to all my efforts, the last as: >>>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>>>=20 >>>>>>> AB >>>>>>> On 10/9/12, Ulrich Herberg wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in = Salon A. >>>>>>>> If you intend to present something, please send a request to the c= hairs. >>>>>>>>=20 >>>>>>>> Best regards >>>>>>>> Ulrich >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> --- >>>>>> We cannot solve our problems with the same thinking we used when we = created them.=20 >>>>>> Albert Einstein >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when we c= reated them.=20 >>>>> Albert Einstein >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> ******************************************************************** >>>>> This email and any attachments are confidential to the intended >>>>> recipient and may also be privileged. If you are not the intended >>>>> recipient please delete it from your system and notify the sender. >>>>> You should not copy it or use it for any purpose nor disclose or >>>>> distribute its contents to any other person. >>>>> ******************************************************************** >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Sat Oct 13 04:29:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371A221F844C for ; Sat, 13 Oct 2012 04:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj9Fz5Yl+roH for ; Sat, 13 Oct 2012 04:29:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 11BC421F8438 for ; Sat, 13 Oct 2012 04:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8021; q=dns/txt; s=iport; t=1350127758; x=1351337358; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UHCQHPyxEaz1oGcFjyUECWPpKOAhRxhqf5Eul3H7uKQ=; b=E0NxwMzXP3wErc/4yGT4ISC+vG0mU8tZ6cviV55hqhBNdAShzEPvfs+U 45/yFr6ngG1zjR4+/XpgN/8K6AhrVU/43TuP+P83zYOPJ7LTEEyPE2P/0 Vr6/8BF2o46UXMaIJ+OODttQFXgDjgTkZ1N90rBib5Rec4J3XtYMGD7Jx k=; X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131234982" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 13 Oct 2012 11:29:17 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-18.cisco.com [10.81.230.18]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9DBTGDX002780; Sat, 13 Oct 2012 11:29:17 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Sat, 13 Oct 2012 07:29:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49C83F60-E702-4777-8B6A-7AB8BC73F313@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> To: Teco Boot X-Mailer: Apple Mail (2.1085) Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 11:29:19 -0000 On Oct 13, 2012, at 4:02 AM, Teco Boot wrote: >=20 > Op 12 okt. 2012, om 20:02 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 >>=20 >> On Oct 12, 2012, at 1:58 PM, Teco Boot wrote: >>=20 >>>=20 >>> Op 12 okt. 2012, om 19:38 heeft Bo Berry het volgende geschreven: >>>=20 >>>> Hi Teco, thanks for the clarification. Discussion in-line. >>>> -Bo >>>>=20 >>>>=20 >>>> On Oct 12, 2012, at 11:31 AM, Teco Boot wrote: >>>>=20 >>>>>=20 >>>>> Op 12 okt. 2012, om 16:20 heeft Bo Berry het volgende geschreven: >>>>>=20 >>>>>> Teco, >>>>>> I'm trying to understand, but having trouble. Are we talking = about rolling back metrics to a previous state? >>>>> I did not have "roll back to a previous state, please" in mind. >>>>>=20 >>>>>> If so, the radio can simply send a new set of metrics. Using = metrics from some time back makes no sense to me and computing/making a = routing change with old data seems dangerous. How much history does the = router keep? =20 >>>>> None. Radio is responsible to get the information bases on radio = and router in sync. >>>>>=20 >>>>>>=20 >>>>>> Help me understand. >>>>> Example scenario, with minimal exchanged data: >>>>> Radio sends Peer Discovery, ID only >>>>> Router sends Peer Offer, ID only >>>>> Radio sends Peer Offer Ack, ID and Status =20 >>>>> Radio sends Neighbor Up, ID and MAC. >>>>> Router sends Neighbor Up Ack, ID and MAC >>>>> Now, there is no RLQ for that neighbor in the information base in = the router. >>>>> Radio sends Neighbor Update, ID, MAC and RLQ. >>>>> (Router should send Neighbor Update Ack, ID and MAC) >>>>> Now, we have the RLQ. >>>>>=20 >>>>> By some magic, the RLQ becomes invalid. Could be antenna switch, = modulation switch or even an RF engine switch. >>>>> Assume neighbor does not go into down state. >>>>> How can the radio send a message to the router that the RLQ is in = UNKNOW state again, just as right after the UP state? >>>>=20 >>>> No magic here, metrics constantly change. The rate that the radio = reports metrics will depend upon the design, some may report at periodic = intervals some may be event driven. In any case, it is important for = the radio to provide heuristics that dampen the rate of metric updates, = such as crossing thresholds or percent change from previous. For = example, a radio may calculate metrics every 100ms. Each epoch the = metrics are filtered through the heuristics, if conditions merit, the = update is sent.=20 >>>>=20 >>>> The router calculates an updated route cost upon receiving the = metrics. The effect of the newly computed route cost is run through = heuristics so not to over drive route/link cost updates. Of course the = cost calculation and the heuristics are unique per routing protocol. = For example, the newly calculated link cost could be compared to the = current, if conditions merit, the new link cost is inserted from which = the routing protocol floods/updates. >>>>=20 >>>> Since the raw data for calculating metrics is in the radio, the = radio should send a new neighbor update with the new calculations. If = the RLQ is no longer valid other parameters will be changing. =20 >>>>=20 >>>> Similar fashion, the radio heuristics to determine the presence of = a new neighbor from which a neighbor up is generated will be important. = So to the radio heuristics when deciding to generate the neighbor down. >>>>=20 >>>> Typing this response does help me understand your perspective. = Between sending a new update message to indicate a single metric is no = longer valid and back-up, compared to a new set of metrics, I'd rather = have the most current metrics. >>>=20 >>> I don't follow. Do you suggest the router should keep using the now = outdated metrics, for as long as the radio cannot provide an information = element? >>>=20 >>> State_1: router calculated metric_1, RLQ was not available >>> State_2: router calculated metric_2, RLQ was available >>> State_3: RLQ is not available, router cannot calculate a metric >>>=20 >>> My opinion: in state_3, router has to be able to calculate a = metric_3 which would be equal to metric_1. Keep using metric_2 is wrong. >>=20 >> Specifically for the case of RLQ, do you expect the router's metric = for "RLQ not available" to be different from "RLQ =3D 0"? If so, why?=20 >=20 > My point is that the DLEP protocol should be "complete", in that the = radio is able to get the router in a certain state, in another state and = get back in the earlier state. RLQ is just an example. >=20 > If you think this makes no sense with the radios you have seen up to = now, you could be right. Tomorrow, you could have a different opinion. I = saw on this mailing list some of us see already the requirement the = protocol shall be "complete". >=20 This makes no sense to me, and I do not agree that the radio should be = able to get the router into a certain state. If we talking metrics, the = radio should send the latest metrics as routers probably do not maintain = a cache of previous metrics. If there becomes a new requirement, we can = extend the protocol once we understand the details.=20 > Teco >=20 >=20 >> Stan >>=20 >>=20 >>>=20 >>> Teco >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>> This can happen with 802.11 CDR. The routing hello protocol = detects symmetrical connectivity. Until there is some unicast traffic, = data rate is unknown. The DLEP radio may start providing CDR after = adaptive rate selection. It may want to revoke stale information. >>>>> I do not say an 802.11 radio should behave like this. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> -Bo >>>>>>=20 >>>>>>=20 >>>>>> On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >>>>>>>=20 >>>>>>>> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>>>=20 >>>>>>>>>>> It's hard to insert even generic, "hand-waving" level text >>>>>>>> .... >>>>>>>>> So, basically what I'm saying is "Tell me what you want this = to say. I'll cut and paste your text into the document." >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The UNKNOWN condition does not apply to RLQ only. Resources is = somewhat equivalent. In fact all TLVs can be unknown, just after = Neighbor Up and no optional TLVs, and no info from peer. Also, the = protocol is not complete if there is no way to get back to a previous = state of the information base. >>>>>>>> I straightforward solution is to have a method to revoke = everything that is send before. >>>>>>>=20 >>>>>>> That depends on how you define "everything that is sent before". = If, for instance, this was the 10th metric update, are you talking about = rolling back to the 9th update? If so, I'm opposed. That's a huge burden = on the router. If you're talking about clearing out a metric value and = setting it to some defined value, like the router's defaults, then I'm = OK with that.=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Length=3D0 or the existing drop indicator. Text would be: >>>>>>>>=20 >>>>>>>> Length - (the value for TLV with info) >>>>>>>> A zero length can be used to revoke previous provided = information for this Data Item TLV. >>>>>>>>=20 >>>>>>>> This could also be used to override the peer provided defaults. >>>>>>>=20 >>>>>>> Overriding the defaults makes no sense to me.=20 >>>>>>>=20 >>>>>>> Stan >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> --- >>>>>> We cannot solve our problems with the same thinking we used when = we created them.=20 >>>>>> Albert Einstein >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> --- >>>> We cannot solve our problems with the same thinking we used when we = created them.=20 >>>> Albert Einstein >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >=20 From teco@inf-net.nl Sat Oct 13 04:47:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7C21F8512 for ; Sat, 13 Oct 2012 04:47:56 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJUTvfhN4wUs for ; Sat, 13 Oct 2012 04:47:55 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C13BD21F84EF for ; Sat, 13 Oct 2012 04:47:54 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2045999wgb.13 for ; Sat, 13 Oct 2012 04:47:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CbSIVATUT0uttbuJowWLP9z4PA4c22vwZqO/XoJ0ZDw=; b=BEE8sxIXPttBnnx/Pa8Te6kLzqoYegL9B9IjlwEVexjI/8S7A23rXa9vM/f9Hl2G4s Nue9On5lqBpUuBfO31LLYaDDeB2iM0TBsZZw4QOGx6p31g9S+nEpWvMsQMsm/4IlYSJE 33O65AT2Z3gJjNrmdTjBv4OiVV4c3EQPIsTlyinWB3Nw7/xr6wwf/U3SMdX//aOWt1N1 tsl1Z0pnzG13AVkru1okNALc4EAv82+HsYkWwvqVPl5ausOmHPplgr0uM6jKs7gmWHbj XuK0BkDr1CVtKgVQbKeMdvnm4GGICR8R9nQaW3PuCqW65g/TS29SkzpmKLTNlNksE5sl q2tQ== Received: by 10.216.227.101 with SMTP id c79mr4497042weq.31.1350128872980; Sat, 13 Oct 2012 04:47:52 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id cl8sm2640341wib.10.2012.10.13.04.47.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 04:47:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <49C83F60-E702-4777-8B6A-7AB8BC73F313@cisco.com> Date: Sat, 13 Oct 2012 13:47:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <5076BB8D.4000705@fkie .fraunhofer.de> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> <49C83F60-E702-4777-8B6A-7AB8BC73F313@cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmM4rJCBs01ieCDZA38jmuIu6AgFwYL/dJYZi+l14rZ5R5s0hlf7vPgaA4Huchv/Rm+ZJnu Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 11:47:56 -0000 Op 13 okt. 2012, om 13:29 heeft Bo Berry het volgende geschreven: >=20 > On Oct 13, 2012, at 4:02 AM, Teco Boot wrote: >=20 >>=20 >> Op 12 okt. 2012, om 20:02 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Oct 12, 2012, at 1:58 PM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 12 okt. 2012, om 19:38 heeft Bo Berry het volgende geschreven: >>>>=20 >>>>> Hi Teco, thanks for the clarification. Discussion in-line. >>>>> -Bo >>>>>=20 >>>>>=20 >>>>> On Oct 12, 2012, at 11:31 AM, Teco Boot wrote: >>>>>=20 >>>>>>=20 >>>>>> Op 12 okt. 2012, om 16:20 heeft Bo Berry het volgende geschreven: >>>>>>=20 >>>>>>> Teco, >>>>>>> I'm trying to understand, but having trouble. Are we talking = about rolling back metrics to a previous state? >>>>>> I did not have "roll back to a previous state, please" in mind. >>>>>>=20 >>>>>>> If so, the radio can simply send a new set of metrics. Using = metrics from some time back makes no sense to me and computing/making a = routing change with old data seems dangerous. How much history does the = router keep? =20 >>>>>> None. Radio is responsible to get the information bases on radio = and router in sync. >>>>>>=20 >>>>>>>=20 >>>>>>> Help me understand. >>>>>> Example scenario, with minimal exchanged data: >>>>>> Radio sends Peer Discovery, ID only >>>>>> Router sends Peer Offer, ID only >>>>>> Radio sends Peer Offer Ack, ID and Status =20 >>>>>> Radio sends Neighbor Up, ID and MAC. >>>>>> Router sends Neighbor Up Ack, ID and MAC >>>>>> Now, there is no RLQ for that neighbor in the information base in = the router. >>>>>> Radio sends Neighbor Update, ID, MAC and RLQ. >>>>>> (Router should send Neighbor Update Ack, ID and MAC) >>>>>> Now, we have the RLQ. >>>>>>=20 >>>>>> By some magic, the RLQ becomes invalid. Could be antenna switch, = modulation switch or even an RF engine switch. >>>>>> Assume neighbor does not go into down state. >>>>>> How can the radio send a message to the router that the RLQ is in = UNKNOW state again, just as right after the UP state? >>>>>=20 >>>>> No magic here, metrics constantly change. The rate that the radio = reports metrics will depend upon the design, some may report at periodic = intervals some may be event driven. In any case, it is important for = the radio to provide heuristics that dampen the rate of metric updates, = such as crossing thresholds or percent change from previous. For = example, a radio may calculate metrics every 100ms. Each epoch the = metrics are filtered through the heuristics, if conditions merit, the = update is sent.=20 >>>>>=20 >>>>> The router calculates an updated route cost upon receiving the = metrics. The effect of the newly computed route cost is run through = heuristics so not to over drive route/link cost updates. Of course the = cost calculation and the heuristics are unique per routing protocol. = For example, the newly calculated link cost could be compared to the = current, if conditions merit, the new link cost is inserted from which = the routing protocol floods/updates. >>>>>=20 >>>>> Since the raw data for calculating metrics is in the radio, the = radio should send a new neighbor update with the new calculations. If = the RLQ is no longer valid other parameters will be changing. =20 >>>>>=20 >>>>> Similar fashion, the radio heuristics to determine the presence of = a new neighbor from which a neighbor up is generated will be important. = So to the radio heuristics when deciding to generate the neighbor down. >>>>>=20 >>>>> Typing this response does help me understand your perspective. = Between sending a new update message to indicate a single metric is no = longer valid and back-up, compared to a new set of metrics, I'd rather = have the most current metrics. >>>>=20 >>>> I don't follow. Do you suggest the router should keep using the now = outdated metrics, for as long as the radio cannot provide an information = element? >>>>=20 >>>> State_1: router calculated metric_1, RLQ was not available >>>> State_2: router calculated metric_2, RLQ was available >>>> State_3: RLQ is not available, router cannot calculate a metric >>>>=20 >>>> My opinion: in state_3, router has to be able to calculate a = metric_3 which would be equal to metric_1. Keep using metric_2 is wrong. >>>=20 >>> Specifically for the case of RLQ, do you expect the router's metric = for "RLQ not available" to be different from "RLQ =3D 0"? If so, why?=20 >>=20 >> My point is that the DLEP protocol should be "complete", in that the = radio is able to get the router in a certain state, in another state and = get back in the earlier state. RLQ is just an example. >>=20 >> If you think this makes no sense with the radios you have seen up to = now, you could be right. Tomorrow, you could have a different opinion. I = saw on this mailing list some of us see already the requirement the = protocol shall be "complete". >>=20 >=20 > This makes no sense to me, and I do not agree that the radio should be = able to get the router into a certain state. If we talking metrics, the = radio should send the latest metrics as routers probably do not maintain = a cache of previous metrics. Did you read my clarification? I don't think so. I never suggested a = router would have such a cache. > If there becomes a new requirement, we can extend the protocol once = we understand the details.=20 It is not new. Others came with it and I do support this *current* = requirement. I made it more general, as I say optional Data Item TLVs = are truly optional. They can come and they can go. The discussion is on = how they go. Teco >=20 >=20 >=20 >=20 >> Teco >>=20 >>=20 >>> Stan >>>=20 >>>=20 >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>> This can happen with 802.11 CDR. The routing hello protocol = detects symmetrical connectivity. Until there is some unicast traffic, = data rate is unknown. The DLEP radio may start providing CDR after = adaptive rate selection. It may want to revoke stale information. >>>>>> I do not say an 802.11 radio should behave like this. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> -Bo >>>>>>>=20 >>>>>>>=20 >>>>>>> On Oct 12, 2012, at 10:01 AM, Stan Ratliff (sratliff) wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Oct 12, 2012, at 3:20 AM, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>> Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>>>>=20 >>>>>>>>>>>> It's hard to insert even generic, "hand-waving" level text >>>>>>>>> .... >>>>>>>>>> So, basically what I'm saying is "Tell me what you want this = to say. I'll cut and paste your text into the document." >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The UNKNOWN condition does not apply to RLQ only. Resources is = somewhat equivalent. In fact all TLVs can be unknown, just after = Neighbor Up and no optional TLVs, and no info from peer. Also, the = protocol is not complete if there is no way to get back to a previous = state of the information base. >>>>>>>>> I straightforward solution is to have a method to revoke = everything that is send before. >>>>>>>>=20 >>>>>>>> That depends on how you define "everything that is sent = before". If, for instance, this was the 10th metric update, are you = talking about rolling back to the 9th update? If so, I'm opposed. That's = a huge burden on the router. If you're talking about clearing out a = metric value and setting it to some defined value, like the router's = defaults, then I'm OK with that.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Length=3D0 or the existing drop indicator. Text would be: >>>>>>>>>=20 >>>>>>>>> Length - (the value for TLV with info) >>>>>>>>> A zero length can be used to revoke previous provided = information for this Data Item TLV. >>>>>>>>>=20 >>>>>>>>> This could also be used to override the peer provided = defaults. >>>>>>>>=20 >>>>>>>> Overriding the defaults makes no sense to me.=20 >>>>>>>>=20 >>>>>>>> Stan >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> --- >>>>>>> We cannot solve our problems with the same thinking we used when = we created them.=20 >>>>>>> Albert Einstein >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when = we created them.=20 >>>>> Albert Einstein >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From abdussalambaryun@gmail.com Sat Oct 13 05:02:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A92521F8510 for ; Sat, 13 Oct 2012 05:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sq02DQL8G5H for ; Sat, 13 Oct 2012 05:02:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDAC721F850B for ; Sat, 13 Oct 2012 05:02:07 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4326715vbb.31 for ; Sat, 13 Oct 2012 05:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sp3+D4rT7wNr21p6tfl4BmH26H3xAfd+VruFD92cPTs=; b=0TBT6ywYowy7gt1GnCgorjxha/wYQ/UAMGJQ8k9P4zqfKCTqriJckrVcM1aHcVEsys 2C3DQVbU3oscbRRz363dCl5MaWoxSl75LxwoTZDwNppKbstT8r1wCnNfBFZE+6vzRbTt tULvAPPZksdnC1oQboQJTVmbYmw60a5qFObLqv8IGv2JofJddxMVND6UFt7yui/k7Ln6 Pt99PKNa1OL63c19FiIUHEb+YPeKLtRqzkwSOFDL7PMF8AXZO4UnrX7fK87WxvO8cVSv IzoABOS6HiS8fXchzrivMvvFO1SCSR3m0mBkUe2DD3JIdhQ6qd9WkvOvCaj9fmJ107xP 4IoQ== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr3298684vdv.20.1350129727191; Sat, 13 Oct 2012 05:02:07 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sat, 13 Oct 2012 05:02:06 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> Date: Sat, 13 Oct 2012 14:02:06 +0200 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 12:02:08 -0000 I agree we should design for the present MANET technologies and future, for the protocol completion. Do you mean router-state as the DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don't understand why we need to consider router states. DLEP considers the session between server and client states, other states are not inscope. For simplicity, DLEP should be abstract from MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an optional future interaction may be useful but complicated (will need RFC5444). AB On 10/13/12, Teco Boot wrote: > My point is that the DLEP protocol should be "complete", in that the radio is able to get the router in a certain state, in another state and get back in the earlier state. RLQ is just an example. If you think this makes no sense with the radios you have seen up to now, you could be right. Tomorrow, you could have a different opinion. I saw on this mailing list some of us see already the requirement the protocol shall be "complete". From abdussalambaryun@gmail.com Sat Oct 13 05:41:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6FB21F8512 for ; Sat, 13 Oct 2012 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hI-16Nxj-tEC for ; Sat, 13 Oct 2012 05:41:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3270A21F851B for ; Sat, 13 Oct 2012 05:41:14 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4347117vbb.31 for ; Sat, 13 Oct 2012 05:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KqthmnFj8Ii6oTb7qWGAJsA1KdKTeVjke1+omrsP4aw=; b=A3BySD3hlE9YtoweKKGCY9r2i9MwzQAtMEOOpfzZYK/TCi/2vEbaKQ0KYukPsUoBuO 6XTEUZqoKaqBhMhygNQ3cmsJwF2kGp2wFhhglgUEBcmAAB7obgcqF+CU2RHETsE4J87H TL1gLWopVK8qAWwK0GhdisaO8YYIiD6QyPugXlcD0a6R7jSzTmrCk+PJrmhO59+OlmcR VAQc9wE3zWfFVAGMPUvkjQsxASF0K6QezsTt+3ROkD7msGqSVQwnfBtR4y9nXPlvsVTs qDUS0fi2d6ZLWDeGNFT4HBMGUcNy3AGYmZOl3MVzDo+DCL9yolGC+cVADP4j9n4CDmXl D09A== MIME-Version: 1.0 Received: by 10.220.240.135 with SMTP id la7mr3975393vcb.44.1350132073510; Sat, 13 Oct 2012 05:41:13 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sat, 13 Oct 2012 05:41:13 -0700 (PDT) Date: Sat, 13 Oct 2012 14:41:13 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 12:41:14 -0000 I think some people in WG are interested also in Funkfeuer routing metric [1], it was mentioned in MANET meeting 84. I hope we will see the draft [2] to be accepted as a MANET WG draft shortly for informational about Funkfeuer. AB>suggest for title> Packet Sequence Number based ETX Metric for Funkfeuer Networking. AB> suggest the Abstract> This document specifies the ETX metric and its usage in Funkfeuer's OLSRv2 Routers. I recommend to include this draft [2] or a renewal in the Agenda 85, if the authors are welling to present it. [1] http://www.ietf.org/mail-archive/web/manet/current/msg12077.html [2] http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 AB ++ On 10/12/12, Henning Rogge wrote: > On 10/12/2012 09:53 AM, Abdussalam Baryun wrote: >> +1 >> >> It is an excellent draft/work, I support the draft and your process. >> Thanks to all: authors, you and the WG, > > The document will be a great help as a pointer for people who still > arguing the use of link metrics. Good to see it here. > > Henning Rogge > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From teco@inf-net.nl Sat Oct 13 06:14:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F5F21F84E7 for ; Sat, 13 Oct 2012 06:14:19 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNCMWm6HBKGD for ; Sat, 13 Oct 2012 06:14:19 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E10E621F8459 for ; Sat, 13 Oct 2012 06:14:18 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so365875wib.13 for ; Sat, 13 Oct 2012 06:14:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5wSr9szesCrzZAuY2xS5JMWxdy6U5/+ifX2erLSii7I=; b=Qd4tIoQ2fujOHuU9FUNyp+7hhuCBRv5BCoTCBBKOWI516HQZJ4VPjV2qaee3wkPRhY aOjz9zwDxJQRPLN/SBR+HJoM4CY1qJlrilQmxFGyfDVfjBPCt+OeP3i6KFAaTGv+/gf5 V+m4toLtqGrDld8bH+Jrr6ezcFx2H8Dlspt89muYaS5BePmbNEG0Cx5kpK5QSvT+7HY4 pzOI1HfHuoPkdp0ET1cNcBafpSAbhGNS+LnDwxYG+Gfe3Z9Bv5kHM46eEX0GHipo9Plx LsAkYiAjYhaGX3tYvz1ls1gjtMtnMfenKbt/yMCyzVBugFUVh1okAAYZ4pfkJUuQlJO6 P7+w== Received: by 10.216.135.85 with SMTP id t63mr4156751wei.93.1350134057947; Sat, 13 Oct 2012 06:14:17 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id dm3sm3470288wib.3.2012.10.13.06.14.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 06:14:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sat, 13 Oct 2012 15:14:16 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6ADE64B6-D14D-422D-9F1F-3C58A5E3FD46@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9 D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkiRmpmAJgM7K7mEOcVfZ8va6ObuAj8HREfK2AkmSWDy+hbICgcSA10ymMpI5DAoVOM8pHj Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 13:14:20 -0000 DLEP is (mainly) getting the neighbor information base from radio to router, as accurate as possible. It is up to the router to use this for route calculation. This discussion is not about using RFC 5444. It is about transfer of "hey there, I don't have this info anymore". Bo and Stan say, this is not needed. Others say, there is a need for it. I agree with the others, because I cannot see a reason a radio is only allowed *once* during neighbor_up state to miss data items. We better prepare for data items that can fall back to unknown. I say: let's allow this for all optional data items. Teco Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende geschreven: > I agree we should design for the present MANET technologies and > future, for the protocol completion. Do you mean router-state as the > DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don't > understand why we need to consider router states. > > DLEP considers the session between server and client states, other > states are not inscope. For simplicity, DLEP should be abstract from > MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an > optional future interaction may be useful but complicated (will need > RFC5444). > > AB > > On 10/13/12, Teco Boot wrote: >> > My point is that the DLEP protocol should be "complete", in that the > radio is able to get the router in a certain state, in another state > and get back in the earlier state. RLQ is just an example. > > If you think this makes no sense with the radios you have seen up to > now, you could be right. Tomorrow, you could have a different opinion. > I saw on this mailing list some of us see already the requirement the > protocol shall be "complete". From c.chauvenet@watteco.com Sat Oct 13 07:03:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED521F847A for ; Sat, 13 Oct 2012 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLxjMqKdDpF9 for ; Sat, 13 Oct 2012 07:03:28 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 98CC421F8467 for ; Sat, 13 Oct 2012 07:03:26 -0700 (PDT) Received: from mail173-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Sat, 13 Oct 2012 14:03:25 +0000 Received: from mail173-va3 (localhost [127.0.0.1]) by mail173-va3-R.bigfish.com (Postfix) with ESMTP id 2AD2AC0113; Sat, 13 Oct 2012 14:03:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371Ic89bhd6eahc85eh542M1418I14ffIzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh84d07hz2dh54h2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail173-va3 (localhost.localdomain [127.0.0.1]) by mail173-va3 (MessageSwitch) id 1350137001438924_22353; Sat, 13 Oct 2012 14:03:21 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.243]) by mail173-va3.bigfish.com (Postfix) with ESMTP id 66324160043; Sat, 13 Oct 2012 14:03:21 +0000 (UTC) Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 13 Oct 2012 14:03:21 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.67.167]) with mapi id 14.16.0207.009; Sat, 13 Oct 2012 14:03:19 +0000 From: C Chauvenet To: Teco Boot Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySA Date: Sat, 13 Oct 2012 14:03:18 +0000 Message-ID: <29959252-16D7-470C-96A5-05E70D218849@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/related; boundary="_005_2995925216D7470C96A505E70D218849wattecocom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 14:03:32 -0000 --_005_2995925216D7470C96A505E70D218849wattecocom_ Content-Type: multipart/alternative; boundary="_000_2995925216D7470C96A505E70D218849wattecocom_" --_000_2995925216D7470C96A505E70D218849wattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I agree with Teco that the message from the chair (http://www.ietf.org/mail= -archive/web/manet/current/msg13305.html) is a good move. In particular that "the LLN needs to be deemphasized as the primary purpose= if adopted as manet". However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 says in its = introduction that : The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) is a routing protocol, derived from AODV [RFC3561] and extended for use in Lo= w power and Lossy Networks (LLNs). So, removing LLNs' related material on this draft could get back to AODV wh= ich is already RFC 3561. So what is the improvement ? >From what I understand, the LOADng purpose should be a new version of AODV = addressing some of the points suggested by the MANET chair such as "improve= ments in heterogeneity support, simplification where sensible, improved con= trol plane flooding, better IPv6 support, and a eventually clear border gat= eway specification". In short : LLNs constraints and challenges should not be adressed by LOADng= , but LOADng could improve the AODV original specification for MANET networ= ks. Is my understanding correct ? Best, C=E9dric. Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit : I assume the authors take the guidance from our chair, posted in: http://www.ietf.org/mail-archive/web/manet/current/msg13305.html If so, I do not see a reason not to discuss LOADng. And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings. Teco Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: Hi, (speaking on my own, not to representing the LOADng authors). As was pointed out before, we often have discussed items that were not WG d= ocuments, usually at the end of the meeting, to make sure that there is eno= ugh time for WG items. I also agree with what Stan said: MANET should not b= e standardizing documents that are mainly focused on LLNs; however, a docum= ent that is focused on MANETS, and as a matter of fact is also used in LLN = deployments should be acceptable, in my opinion. We are currently finalizing some internal discussions between the authors o= f LOADng, and I think that there will be an email to the list on that regar= ds in the next few days. Abdussalam, being against presentation of somethin= g that has not even been proposed yet is premature and pointless, in my opi= nion. Best regards Ulrich On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" wrote: I think you are in violent agreement. The current LOADng draft is (IIRC) ai= med at LLNs, so Teco is saying unless there's a new MANET-oriented version = it shouldn't be discussed, and you are saying it won't be discussed. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 12 October 2012 15:12 To: Teco Boot Cc: Dearlove, Christopher (UK); List; Bo Berry (boberry) Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: On July 31th, our chair provided guidance on handling LOADng. It shows the way forward. I'm looking forward to an draft-author-manet-loadng-00 draft, submitted bef= ore next Monday. If there is no such draft, and little time to discuss non-wg drafts, we sho= uld not discuss an lln draft in our meeting in Atlanta. One (not too) fine point - we (the MANET WG) will *not* be discussing an LL= N draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols. Stan I'm OK on discussions on how to fulfill our charter item on a reactive prot= ocol. Teco Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende ges= chreven: We have often discussed things not yet accepted by the WG, it can be a step= towards getting them accepted. That's not a comment for or against LOADng, discussing LOADng, or adopting = LOADng, just an observation on what has happened in the past. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry Sent: 12 October 2012 13:40 To: Abdussalam Baryun; List; Bo Berry Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Looking at the MANET WG Documents page, LOADng is not on the list. So until= LOADng is accepted by the WG, gotta agree with Abdussalam, no need to disc= uss it in the little time we have for the work we've already accepted. How does this fit into the WG Charter? -Bo Active Internet-Drafts draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neigh= borhood Discovery Protocol draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps= For Router Admittance in NHDP draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol ver= sion 2 draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile= Ad Hoc Network (MANET) Routing draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Opt= imized Link State Routing Protocol On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: I've seen a number of emails on the alias but not sure LOADng has been accepted by the WG. Is LOADng asking to be a MANET WG draft? -Bo On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: Please note that I strongly object any including of LOADng draft in the Age= nda. The document is not for MANET, was already presented before, and the authors are not discussing on ietf lists of any progress. The draft is not reasonable for the WG, if it is not discussed on the MANET list. I got no reasonable reply to all my efforts, the last as: http://www.ietf.org/mail-archive/web/manet/current/msg13448.html AB On 10/9/12, Ulrich Herberg wrote: Hi, the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. If you intend to present something, please send a request to the chairs. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet [cid:image001.jpg@01CD44D4.8A473390] C=E9dric CHAUVENET Ph.D Student c.chauvenet@watteco.com Direct Line : +33(0)4 98 01 35 81 Mobile : +33(0)6 30 21 14 91 Standard : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE =96 France www.watteco.com [cid:image002.gif@01CD44D4.8A473390] Before printing think about environment and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. --_000_2995925216D7470C96A505E70D218849wattecocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1CC0F5035443A04F9003F9553AEA3AED@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi all, 

I agree with Teco that the message from the chair (http://www.ietf.o= rg/mail-archive/web/manet/current/msg13305.html) is a good move. <= /div>
In particular that "the LLN needs to be deemphasized as the primary purpose if adopted as manet&qu= ot;.

However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 s= ays in its introduction that :

The LLN On-demand Ad hoc Distance-vector R=
outing Protocol - Next
   Generation (LOADng) is a routing protocol, derived from AODV
   [RFC3561] and extended fo=
r use in Low power and Lossy Networks
   (LLNs).

So, remov=
ing LLNs' related material on this draft could get back to AODV which is al=
ready RFC 3561. So what is the improvement ?

From what=
 I understand, the LOADng purpose should be a new version of AODV addressin=
g some of the points suggested by the MANET chair such as "improvements in heterogeneity support, simplificat=
ion where sensible, improved control plane flooding, better IPv6 support, a=
nd a eventually clear border gateway specification".  

In short : LLNs constraints and challenges should not be adressed by LOADng, b=
ut LOADng could improve the AODV original specification for MANET networks.=


Is my understanding correct ?

Best,

C=E9dric.=

Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit :

I assume the authors take the guidance from our chair, posted in:
http://www.ietf.org/mail-archive/web/manet/current/msg13305.html

If so, I do not see a reason not to discuss LOADng.
And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings.=

Teco

Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven:

Hi,

(speaking on my own, not to representing the LOAD= ng authors).

As was pointed out before, we often have discusse= d items that were not WG documents, usually at the end of the meeting, to m= ake sure that there is enough time for WG items. I also agree with what Sta= n said: MANET should not be standardizing documents that are mainly focused on LLNs; however, a document that is foc= used on MANETS, and as a matter of fact is also used in LLN deployments sho= uld be acceptable, in my opinion.

We are currently finalizing some internal discuss= ions between the authors of LOADng, and I think that there will be an email= to the list on that regards in the next few days. Abdussalam, being agains= t presentation of something that has not even been proposed yet is premature and pointless, in my opinion.

Best regards
Ulrich

On Oct 12, 2012, at 7:15, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:

I think you are in violent agreement. The current= LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless there's a n= ew MANET-oriented version it shouldn't be discussed, and you are saying it = won't be discussed.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 124= 5 242124
chris.dearlove@baesystems.com | http://www.baesys= tems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:sratliff@ci= sco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet@ietf.or= g> List; Bo Berry (boberry)
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:

On July 31th, our chair provided guidance on hand= ling LOADng.
It shows the way forward.

I'm looking forward to an draft-author-manet-load= ng-00 draft, submitted before next Monday.
If there is no such draft, and little time to dis= cuss non-wg drafts, we should not discuss an lln draft in our meeting in At= lanta.

One (not too) fine point - we (the MANET WG) will= *not* be discussing an LLN draft. At any time. That would be a charter vio= lation - LLN's are defined and worked in ROLL. We are discussing MANET reac= tive protocols.

Stan


I'm OK on discussions on how to fulfill our chart= er item on a reactive protocol.

Teco


Op 12 okt. 2012, om 15:19 heeft Dearlove, Christo= pher (UK) het volgende geschreven:

We have often discussed things not yet accepted b= y the WG, it can be a step towards getting them accepted.

That's not a comment for or against LOADng, discu= ssing LOADng, or adopting LOADng, just an observation on what has happened = in the past.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 124= 5 242124
chris.dearlove@baesystems.com | http://www.baesys= tems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounce= s@ietf.org] On Behalf Of Bo Berry
Sent: 12 October 2012 13:40
To: Abdussalam Baryun; <manet@ietf.org> Lis= t; Bo Berry
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

Looking at the MANET WG Documents page, LOADng is= not on the list. So until LOADng is accepted by the WG, gotta agree with A= bdussalam, no need to discuss it in the little time we have for the work we= 've already accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03    Dynami= c Link Exchange Protocol (DLEP)    
draft-ietf-manet-nhdp-mib-19    De= finition of Managed Objects for the Neighborhood Discovery Protocol  &= nbsp; 
draft-ietf-manet-nhdp-sec-02    Us= ing Integrity Check Values and Timestamps For Router Admittance in NHDP &nb= sp;  
draft-ietf-manet-olsrv2-16    The = Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-metrics-rationale-01 &nbs= p;  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
draft-ietf-manet-olsrv2-mib-04    = Definition of Managed Objects for the Optimized Link State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:

I've seen a number of emails on the alias but not= sure LOADng
has been accepted by the WG.  Is LOADng aski= ng to be a MANET WG
draft?

-Bo


On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wr= ote:

Please note that I strongly object any including = of LOADng draft in the Agenda.
The document is not for MANET, was already presen= ted before, and the
authors are not discussing on ietf lists of any p= rogress. The draft is
not reasonable for the WG, if it is not discussed= on the MANET list.

I got no reasonable reply to all my efforts, the = last as:
http://www.ietf.org/mail-archive/web/manet/curren= t/msg13448.html

AB
On 10/9/12, Ulrich Herberg <ulrich@herberg.nam= e> wrote:
Hi,

the MANET WG will meet on Wednesday, Nov. 7 from = 1pm to 2.30pm in Salon A.
If you intend to present something, please send a= request to the chairs.

Best regards
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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


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

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

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


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

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



C= =E9dric CHAUVENET

Ph.D Student

c.chau= venet@watteco.com

Direct Line :   +33(0)4 98 01 35 81=
Mobile :&= nbsp;         +33(0)6 30 21 14 9= 1

Standard : &nbs= p; +33(0)4 98 01 60 05

Fax :  &nb= sp;          +33(0)4 = 94 14 10 80
 =
1766 Chemin de la= Planquette
83130 LA GARDE = =96 France


=  Before printing think about environment and = costs<= /o:p>


--_000_2995925216D7470C96A505E70D218849wattecocom_-- --_005_2995925216D7470C96A505E70D218849wattecocom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2206; creation-date="Sat, 13 Oct 2012 14:03:18 GMT"; modification-date="Sat, 13 Oct 2012 14:03:18 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAB2AJUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0H7NB /wA8I/8AvgUfZoP+eEf/AHwKmxRivH5pdxkP2aD/AJ4R/wDfAo+zQf8APCP/AL4FTYoxRzS7gQ/Z oP8AnhH/AN8Cj7NB/wA8I/8AvgVNRijml3Ah+zQf88I/++BR9mg/54R/98CpqMUc0u4EP2aD/nhH /wB8Cj7NB/zwj/74FTYoxRzS7gQ/ZoP+eEf/AHwKPs0H/PCP/vgVNijFHNLuBb06xtXgYvawsd3U xg1b/s+y/wCfOD/v2P8ACk09dtqPck1Z7V6lK/IhGUbO13n/AEaHr/zzFOFna/8APtF/3wKk6kmn DrWl2AwWlt/z7Rf98CnC0tv+feL/AL4FSCnCi4DBa2//ADwi/wC+BRUoop3AyMUYp2KMV41gG4qK 5uYLOEy3EgRM4Hck+gHc1JLKsKgtkljtVVGWY+gFc1fC7GqSjUECToAUQNuVEPTafXg5PqK3o0HU fkBam1u5kYi3gSBOzTfMx/4COB+dQ/2lqGci8H08lcVTMg+Y4YqjBWcKSqsegJ6A1d0rTW1fUvsx Z44Il3zshwefuqD2zyfoK9NYejFbFFuy1ljMLe+VFZhlJY87T/vD+H69K1sUkllZaDpU0KFp7i6B Rd+C8pPAH0A/xpY0KRIhOSqhSfXArzcRTjGXukhijFOxRiuewDcUYp2KfDH5kyL6nmmo3dgNW3TZ Ai+gpZDtjY+1PqG4OI8epr1krKwFYU4UgpwFMBwFKKBSigBaKWigDLxRinYoIODjg44PpXlWATSo Rc3ct8wysZMMHtj7zfiePoKyfGUMi6hYSwrmS4VrdfduCv8AWnXEmo/2MlrHE9otqN8kgcZl2nOF x2Pcn6V0j29vei3nkjDmJhLET/CcdfyNelSaStHoBVh0S2h0I6So/dtGVdj1Zj1Y++eaqaFZyaJo c9xeqFuDulmwc8AYHP0Gfxq+2qwJqw01lcOUDB8fISc/Ln1wCah11/MtY7FfvXThW9kHLH8uPxqn KyYFCygJjS7nLSXUqAySOckZ52j0A9BVrFOx7UYrzHdu7AbijFOxRilYBuKuWEXLSH6CqwUswUDk 1qRII41QdhW9CF5XAfVWdt0mPSrDNtUn0qr1OT3ruAQU8CkFOxQACnUgp2KACilooAzsUYp+KMV5 1gI2QOjIwyrAg/Q07SrtYdGP2mQD7EGjlJ7be/5YNU7nVrS0uTbyl/MxuwFzx1/ln8jWfLqOlXEq ymSYLMQGQDCylem4d8ZH6VrTlyMCWaWNdLkvb9HT7XJ5jFThov7nPqAB+NVrfXYWkhuLiSSaWdlg VmUJs4BPH1IBPrV+61XTWeWzuFMhTl0ZeDggj+lUxf6MQ3+hgI4OCFHzZO48dsnmpu2BbXVZGRG+ xN89x5GPNHDZxn6cUkGsC4CCK1dnkdkRC2M7epJ7UiXmmt5arGdpfzF6dScbuvqahkbR4w0Zt22B 2bIY8EfeI5yOvbrUWAtw6pHNPHH5TKsrvGjkj5mX7wx26H8qvYrPsP7PnuzJBbFJSCd7Dr0zjnvk Vrww+Y3+yOppqLbsBJaQ/wDLQj6VaoAwMDgUjttXNdsI8qsBFM2TtH41GBS9Tk0uKsBMU4CgUooA BThSYpRQAtFFFAFLFGKdijFcVgI2ijY5ZFJ6ZI5pv2eHAHlR8f7IqbFGKLAQm2gbIMMZzwcqOab9 jtsY+zxY/wBwVYxRiiwEH2W33bvIj3ZznYM59aX7Lb5z5Eecg52DrU2KkjhL8ngU1G+wEUNspf5E VfUgVeRQigDoKFUKMAYFLXRCCiAE4GTUDMXOe3anO2447U3FaAGKMUuKXFACYpRRS0AFLRS0AFFF FAFbFGKdijFc1gG4oxTgPanCJj2xT5QI8UoUscAZqYQjvzUgAA4GKpU+4ESQActz7VLS00sBWqSQ Ck4HNRsxbjtQSTRimAmKMUuKXFACYoxS4ooAKMUtFAAKWkpaACilooAb5a+lLtUdhS0ZFKyAKWky KTd7UwHUhIFNyTRigALE9KTFLijFACYoxS0UAJilxS4oxQAlFLRQAlLRRQAUUtFABRRRQAlFFFAB RRRQAUUUUAFFFFABRRRQAYoxRRQAtFFFABRRRQAUUUUAFFFFAH//2Q== --_005_2995925216D7470C96A505E70D218849wattecocom_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=490; creation-date="Sat, 13 Oct 2012 14:03:18 GMT"; modification-date="Sat, 13 Oct 2012 14:03:18 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== --_005_2995925216D7470C96A505E70D218849wattecocom_-- From boberry@cisco.com Sat Oct 13 07:26:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4460A21F84CE for ; Sat, 13 Oct 2012 07:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+GDmQJ3G3gc for ; Sat, 13 Oct 2012 07:26:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A526021F8532 for ; Sat, 13 Oct 2012 07:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2438; q=dns/txt; s=iport; t=1350138382; x=1351347982; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ukQG3gy27mdpi2efxNzl3q86aYX/2Rj/8WwcuU6XJhM=; b=PegJ8Sl/a5owieWl4gNcb3uL0TLShZ4VpEvp7oAsWXMT5vePmwsgGEtt fcBI2v7q8VItTxsr66NFY9CtwtNG9RZm+dAo8oUXve3hBYi8zSBO2L38k x7DL90xUsv6hvjndVChkNm/0mmexhJheHTanU24JBOG0WuZFrM4unfhC1 Q=; X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131290965" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 13 Oct 2012 14:26:22 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-18.cisco.com [10.81.230.18]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9DEQLXf022869; Sat, 13 Oct 2012 14:26:21 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <6ADE64B6-D14D-422D-9F1F-3C58A5E3FD46@inf-net.nl> Date: Sat, 13 Oct 2012 10:26:26 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6D3A0272-0072-4F8A-9F50-17399CA76AED@cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9 D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> <6ADE64B6-D14D-422D-9F1F-3C58A5E3FD46@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1085) Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 14:26:23 -0000 Teco, I do not understand it and it's not been described in a manner that I can. But if we can not understand it, we will not be successful describing it such that it can be useful. If you can provide meaningful, descriptive text, that would help. At this time, "prepare for data items that can fall back to unknown" does not help me. What do you propose as optional data items and how do you propose, by what mechanism, they fall back? Do they fall back in the radio or router, or both? -Bo On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: > DLEP is (mainly) getting the neighbor information base from radio to > router, as accurate as possible. It is up to the router to use this for > route calculation. > > This discussion is not about using RFC 5444. > > It is about transfer of "hey there, I don't have this info anymore". > Bo and Stan say, this is not needed. Others say, there is a need for it. > I agree with the others, because I cannot see a reason a radio is only > allowed *once* during neighbor_up state to miss data items. We better > prepare for data items that can fall back to unknown. I say: let's allow > this for all optional data items. > > Teco > > > Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende geschreven: > >> I agree we should design for the present MANET technologies and >> future, for the protocol completion. Do you mean router-state as the >> DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don't >> understand why we need to consider router states. >> >> DLEP considers the session between server and client states, other >> states are not inscope. For simplicity, DLEP should be abstract from >> MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an >> optional future interaction may be useful but complicated (will need >> RFC5444). >> >> AB >> >> On 10/13/12, Teco Boot wrote: >>> >> My point is that the DLEP protocol should be "complete", in that the >> radio is able to get the router in a certain state, in another state >> and get back in the earlier state. RLQ is just an example. >> >> If you think this makes no sense with the radios you have seen up to >> now, you could be right. Tomorrow, you could have a different opinion. >> I saw on this mailing list some of us see already the requirement the >> protocol shall be "complete". > From teco@inf-net.nl Sat Oct 13 07:50:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3263721F84FE for ; Sat, 13 Oct 2012 07:50:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-J7vxtR1Gpk for ; Sat, 13 Oct 2012 07:50:57 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABF421F84F1 for ; Sat, 13 Oct 2012 07:50:56 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2472699wey.31 for ; Sat, 13 Oct 2012 07:50:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=nt4Yy/IK6CSuIZwNdP/A/7XPYxtQcbj+k4QzhAU1MvM=; b=KD5PBeU68ePYCo6i8kDsezXHfdAGsIsXUfgIjkSGKVZE5dFh1eOKOK18KJJ4RZOq5N rw9nrGS5QimLbk5Q+8BCSLQeXYKfnjhqhJ04lXYTXlur7vtAEPzFIXPyYC+uGnxvMOpI rmfpD2c/aLXbZEm12cpFxweAzqIsO+lGXxLX04mmynLXEukO8eqpmIKRXtXXJPil1qlj ewmtjHegAvSF/i80wIBpiwWFSyDutr3vrU4Ynf6iN89ketpmapNYtkwcyEf2D9buAWLk 1vTNkpqupzZXfxlTRZO8EIuSrYjwqfJDINtIXUCrP8OIYfvOI44INpiE8okv2c/g3EB1 wDvA== Received: by 10.216.141.14 with SMTP id f14mr4441056wej.208.1350139854533; Sat, 13 Oct 2012 07:50:54 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:c400:f24e:609b:990c? ([2001:470:7a9b:1:c400:f24e:609b:990c]) by mx.google.com with ESMTPS id cn6sm3921928wib.9.2012.10.13.07.50.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 07:50:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <6D3A0272-0072-4F8A-9F50-17399CA76AED@cisco.com> Date: Sat, 13 Oct 2012 16:50:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <99CD3D34-84B8-43B5-9F68-122B397E3BD9@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9 D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> <6ADE64B6-D14D-422D-9F1F-3C58A5E3FD46@inf-net.nl> <6D3A0272-0072-4F8A-9F50-17 399CA76AED@cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQk+mpz2QwQH+ZkuatfqIxRB9S8LQBDIdi1Hgs7q6GCtIQn3vvXOHkW+ETG6DFMHZm6sRmDt Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 14:50:58 -0000 Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: > Teco, > I do not understand it and it's not been described in a manner > that I can. But if we can not understand it, we will not be > successful describing it such that it can be useful. > > If you can provide meaningful, descriptive text, that would help. > At this time, "prepare for data items that can fall back to unknown" > does not help me. What do you propose as optional data items > and how do you propose, by what mechanism, they fall back? Do > they fall back in the radio or router, or both? The optional Data Item TLVs for Neighbor Up are in the draft: - IPv4 Address - IPv6 Address - Maximum Data Rate - Current Data Rate - Latency - Expected Forwarding Time - Resources - Relative Link Factor - Credit Window Status Neighbor Up messages would be send by router, although the draft mentions the router can send it also. Relative Link Factor should be Relative Link Quality (posted before, I think). In Neighbor Update, Expected Forwarding Time is missing. My comment is on the protocol. Optional data item TLVs can be present, or not. There was a proposal for TLV with an UNKNOWN codepoint, for RLQ. I don't see much difference in UNKNOWN and not sending the TLV. Then, this UNKNOWN applies to all optional Data Item TLVs. So if we just add a mechanism that enables sending UNKNOWN for all optional Data Item TLVs, we are done. Addresses have the drop already. The other TLVs can have the length=0. That's all. I provided the text already. I can't be more clear. Sorry. Teco > > > -Bo > > > > On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: > >> DLEP is (mainly) getting the neighbor information base from radio to >> router, as accurate as possible. It is up to the router to use this for >> route calculation. >> >> This discussion is not about using RFC 5444. >> >> It is about transfer of "hey there, I don't have this info anymore". >> Bo and Stan say, this is not needed. Others say, there is a need for it. >> I agree with the others, because I cannot see a reason a radio is only >> allowed *once* during neighbor_up state to miss data items. We better >> prepare for data items that can fall back to unknown. I say: let's allow >> this for all optional data items. >> >> Teco >> >> >> Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende geschreven: >> >>> I agree we should design for the present MANET technologies and >>> future, for the protocol completion. Do you mean router-state as the >>> DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don't >>> understand why we need to consider router states. >>> >>> DLEP considers the session between server and client states, other >>> states are not inscope. For simplicity, DLEP should be abstract from >>> MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an >>> optional future interaction may be useful but complicated (will need >>> RFC5444). >>> >>> AB >>> >>> On 10/13/12, Teco Boot wrote: >>>> >>> My point is that the DLEP protocol should be "complete", in that the >>> radio is able to get the router in a certain state, in another state >>> and get back in the earlier state. RLQ is just an example. >>> >>> If you think this makes no sense with the radios you have seen up to >>> now, you could be right. Tomorrow, you could have a different opinion. >>> I saw on this mailing list some of us see already the requirement the >>> protocol shall be "complete". >> > From boberry@cisco.com Sat Oct 13 08:06:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526A721F84E4 for ; Sat, 13 Oct 2012 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuIX55w-+NQ8 for ; Sat, 13 Oct 2012 08:06:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 46E5921F84DE for ; Sat, 13 Oct 2012 08:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4144; q=dns/txt; s=iport; t=1350140812; x=1351350412; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uBI80niC+w/zQ7uOg0SPjMnwXPnIxfmbuEe78vKLIG8=; b=OGJWQd7JrH5d/6lQkAgbW3/Hp0vTum989ztmjNLrDUZKQWX8+QBlhaWu bHHRs4ZyJ3aUl6nEKLYk8K6c547Q/6oZsE+Pc1AiZvrQkr2NK+42rGSHI FvwjYYSTI1Blv33pzMNv0VuYruURtEMU12R1pkYx6wyMpnJijPmrPH5ry k=; X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131294569" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 13 Oct 2012 15:06:52 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-18.cisco.com [10.81.230.18]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9DF6pbV000353; Sat, 13 Oct 2012 15:06:51 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <99CD3D34-84B8-43B5-9F68-122B397E3BD9@inf-net.nl> Date: Sat, 13 Oct 2012 11:06:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9 D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> <6ADE64B6-D14D-422D-9F1F-3C58A5E3FD46@inf-net.nl> <6D3A0272-0072-4F8A-9F50-17 399CA76AED@cisco.com> <99CD3D34-84B8-43B5-9F68-122B397E3BD9@! inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1085) Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:06:53 -0000 Teco Thanks, this helps. So let's see what others think. =20 Have a great wkend. -Bo On Oct 13, 2012, at 10:50 AM, Teco Boot wrote: >=20 > Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: >=20 >> Teco, >> I do not understand it and it's not been described in a manner >> that I can. But if we can not understand it, we will not be=20 >> successful describing it such that it can be useful.=20 >>=20 >> If you can provide meaningful, descriptive text, that would help. =20 >> At this time, "prepare for data items that can fall back to unknown" >> does not help me. What do you propose as optional data items >> and how do you propose, by what mechanism, they fall back? Do >> they fall back in the radio or router, or both? >=20 > The optional Data Item TLVs for Neighbor Up are in the draft: > - IPv4 Address > - IPv6 Address > - Maximum Data Rate > - Current Data Rate > - Latency > - Expected Forwarding Time > - Resources=20 > - Relative Link Factor > - Credit Window Status > Neighbor Up messages would be send by router, although the draft > mentions the router can send it also. > Relative Link Factor should be Relative Link Quality (posted before,=20= > I think). In Neighbor Update, Expected Forwarding Time is missing. >=20 > My comment is on the protocol. Optional data item TLVs can be present, > or not. There was a proposal for TLV with an UNKNOWN codepoint, for = RLQ. > I don't see much difference in UNKNOWN and not sending the TLV. Then, > this UNKNOWN applies to all optional Data Item TLVs. So if we just > add a mechanism that enables sending UNKNOWN for all optional Data=20 > Item TLVs, we are done. Addresses have the drop already. The other > TLVs can have the length=3D0. That's all. I provided the text already. >=20 > I can't be more clear. Sorry. >=20 > Teco >=20 >>=20 >>=20 >> -Bo >>=20 >>=20 >>=20 >> On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: >>=20 >>> DLEP is (mainly) getting the neighbor information base from radio to=20= >>> router, as accurate as possible. It is up to the router to use this = for >>> route calculation. >>>=20 >>> This discussion is not about using RFC 5444.=20 >>>=20 >>> It is about transfer of "hey there, I don't have this info anymore".=20= >>> Bo and Stan say, this is not needed. Others say, there is a need for = it.=20 >>> I agree with the others, because I cannot see a reason a radio is = only=20 >>> allowed *once* during neighbor_up state to miss data items. We = better=20 >>> prepare for data items that can fall back to unknown. I say: let's = allow >>> this for all optional data items. >>>=20 >>> Teco >>>=20 >>>=20 >>> Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende = geschreven: >>>=20 >>>> I agree we should design for the present MANET technologies and >>>> future, for the protocol completion. Do you mean router-state as = the >>>> DLEP-server state? IF yes THEN I agree with you. IF not THEN, I = Don't >>>> understand why we need to consider router states. >>>>=20 >>>> DLEP considers the session between server and client states, other >>>> states are not inscope. For simplicity, DLEP should be abstract = from >>>> MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, = an >>>> optional future interaction may be useful but complicated (will = need >>>> RFC5444). >>>>=20 >>>> AB >>>>=20 >>>> On 10/13/12, Teco Boot wrote: >>>>>=20 >>>> My point is that the DLEP protocol should be "complete", in that = the >>>> radio is able to get the router in a certain state, in another = state >>>> and get back in the earlier state. RLQ is just an example. >>>>=20 >>>> If you think this makes no sense with the radios you have seen up = to >>>> now, you could be right. Tomorrow, you could have a different = opinion. >>>> I saw on this mailing list some of us see already the requirement = the >>>> protocol shall be "complete". >>>=20 >>=20 >=20 From yuichi.igarashi.hb@hitachi.com Sat Oct 13 08:08:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F342721F8522 for ; Sat, 13 Oct 2012 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhfWMidTk4FT for ; Sat, 13 Oct 2012 08:08:11 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34AB021F84DE for ; Sat, 13 Oct 2012 08:08:11 -0700 (PDT) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id AD3EA37C82; Sun, 14 Oct 2012 00:08:03 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id q9DF83LM023266; Sun, 14 Oct 2012 00:08:03 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q9DF82IZ007676; Sun, 14 Oct 2012 00:08:03 +0900 Received: from vshuts3.hitachi.co.jp (unknown [10.201.6.72]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 4AEB7490041; Sun, 14 Oct 2012 00:08:02 +0900 (JST) X-AuditID: b753bd60-99054ba000002f78-e1-507983d283b3 Received: from hsdlmain.sdl.hitachi.co.jp (unknown [133.144.14.194]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id F0F867741ED; Sun, 14 Oct 2012 00:08:01 +0900 (JST) Received: from hsdlvgate2.sdl.hitachi.co.jp by hsdlmain.sdl.hitachi.co.jp (8.13.8/3.7W11021512) id q9DF81Ow009565; Sun, 14 Oct 2012 00:08:01 +0900 X-AuditID: b753bd60-99054ba000002f78-e1-507983d283b3 Received: from sdl99w.sdl.hitachi.co.jp (sdl99w.sdl.hitachi.co.jp [133.144.14.250]) by hsdlvgate2.sdl.hitachi.co.jp (Symantec Mail Security) with ESMTP id 9C2AC236561; Sun, 14 Oct 2012 00:08:01 +0900 (JST) Received: from maila.sdl.hitachi.co.jp (sdl99a.sdl.hitachi.co.jp [133.144.14.196]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id A67F053C158; Sun, 14 Oct 2012 00:08:03 +0900 (JST) Received: from [10.198.212.176] (unknown [10.198.212.176]) by maila.sdl.hitachi.co.jp (Postfix) with ESMTP id 66ED1495BA5; Sun, 14 Oct 2012 00:08:01 +0900 (JST) Message-ID: <507983D0.1040508@hitachi.com> Date: Sun, 14 Oct 2012 00:08:00 +0900 From: Yuichi IGARASHI User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "JP Vasseur (jvasseur)" References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:08:13 -0000 Hi JP, > Just to make sure that we do not play with words …. As agreed between the chairs, it should read " I'm not sure why you suddenly mentioned about "IoT". We discuss about MANET and just LLN. Regarding IoT, there are some IoT applications(for example, livestock, dairy husbandry,etc) that most sensors are not fixed but mobile ones. I think we should not add such a new word to this discussion, not to make it complex. Best regards, Yuichi (2012/10/13 18:21), JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote: > >> Hi, >> >> (speaking on my own, not to representing the LOADng authors). >> >> As was pointed out before, we often have discussed items that were not WG documents, usually at the end of the meeting, to make sure that there is enough time for WG items. I also agree with what Stan said: MANET should not be standardizing documents that are mainly focused on LLNs; > > Just to make sure that we do not play with words …. As agreed between the chairs, it should read "MANET is standardizing documents that are not dealing with LLNs/IoT". > This is much stronger that "mainly on LLNs" > > Thanks. > > JP. > >> however, a document that is focused on MANETS, and as a matter of fact is also used in LLN deployments should be acceptable, in my opinion. >> >> We are currently finalizing some internal discussions between the authors of LOADng, and I think that there will be an email to the list on that regards in the next few days. Abdussalam, being against presentation of something that has not even been proposed yet is premature and pointless, in my opinion. >> >> Best regards >> Ulrich >> >> On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" wrote: >> >>> I think you are in violent agreement. The current LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless there's a new MANET-oriented version it shouldn't be discussed, and you are saying it won't be discussed. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England& Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >>> Sent: 12 October 2012 15:12 >>> To: Teco Boot >>> Cc: Dearlove, Christopher (UK); List; Bo Berry (boberry) >>> Subject: Re: [manet] MANET meeting at IETF85 >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >>> >>>> On July 31th, our chair provided guidance on handling LOADng. >>>> It shows the way forward. >>>> >>>> I'm looking forward to an draft-author-manet-loadng-00 draft, submitted before next Monday. >>>> If there is no such draft, and little time to discuss non-wg drafts, we should not discuss an lln draft in our meeting in Atlanta. >>> >>> One (not too) fine point - we (the MANET WG) will *not* be discussing an LLN draft. At any time. That would be a charter violation - LLN's are defined and worked in ROLL. We are discussing MANET reactive protocols. >>> >>> Stan >>> >>> >>>> I'm OK on discussions on how to fulfill our charter item on a reactive protocol. >>>> >>>> Teco >>>> >>>> >>>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende geschreven: >>>> >>>>> We have often discussed things not yet accepted by the WG, it can be a step towards getting them accepted. >>>>> >>>>> That's not a comment for or against LOADng, discussing LOADng, or adopting LOADng, just an observation on what has happened in the past. >>>>> >>>>> -- >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>> >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England& Wales No: 1996687 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Bo Berry >>>>> Sent: 12 October 2012 13:40 >>>>> To: Abdussalam Baryun; List; Bo Berry >>>>> Subject: Re: [manet] MANET meeting at IETF85 >>>>> >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>> >>>>> Looking at the MANET WG Documents page, LOADng is not on the list. So until LOADng is accepted by the WG, gotta agree with Abdussalam, no need to discuss it in the little time we have for the work we've already accepted. >>>>> >>>>> How does this fit into the WG Charter? >>>>> >>>>> -Bo >>>>> >>>>> >>>>> Active Internet-Drafts >>>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) >>>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neighborhood Discovery Protocol >>>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps For Router Admittance in NHDP >>>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol version 2 >>>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing >>>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Optimized Link State Routing Protocol >>>>> >>>>> >>>>> >>>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>>> >>>>>> I've seen a number of emails on the alias but not sure LOADng >>>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>>>> draft? >>>>>> >>>>>> -Bo >>>>>> >>>>>> >>>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>>> >>>>>>> Please note that I strongly object any including of LOADng draft in the Agenda. >>>>>>> The document is not for MANET, was already presented before, and the >>>>>>> authors are not discussing on ietf lists of any progress. The draft is >>>>>>> not reasonable for the WG, if it is not discussed on the MANET list. >>>>>>> >>>>>>> I got no reasonable reply to all my efforts, the last as: >>>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>>> >>>>>>> AB >>>>>>> On 10/9/12, Ulrich Herberg wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. >>>>>>>> If you intend to present something, please send a request to the chairs. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Ulrich >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> --- >>>>>> We cannot solve our problems with the same thinking we used when we created them. >>>>>> Albert Einstein >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when we created them. >>>>> Albert Einstein >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> >>>>> ******************************************************************** >>>>> This email and any attachments are confidential to the intended >>>>> recipient and may also be privileged. If you are not the intended >>>>> recipient please delete it from your system and notify the sender. >>>>> You should not copy it or use it for any purpose nor disclose or >>>>> distribute its contents to any other person. >>>>> ******************************************************************** >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Hitachi, Ltd., Yokohama Research Laboratory IGARASHI Yuichi Mail： yuichi.igarashi.hb@hitachi.com Tel ： +81-(0)45-860-3083 FAX ： +81-(0)45-860-1673 From jvasseur@cisco.com Sat Oct 13 08:13:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B021F8526 for ; Sat, 13 Oct 2012 08:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wef7E4DxvWMv for ; Sat, 13 Oct 2012 08:13:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DB28E21F851C for ; Sat, 13 Oct 2012 08:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14596; q=dns/txt; s=iport; t=1350141225; x=1351350825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2EVWq+4bLTaC5jsYNxMR/K4AUH/S8/gkoTvewSUKdt0=; b=jI4Gl9Romna1ljIzt9MeIyCKppnSzpSUQZ/CVKCd9wi9GCwMw/ByFoUt 6MiIdkzMcCeR1hMT6nCLtp6Esl4us4UwHcQxnG2kQF5Rq9kFhve7450TK budm1/QMj1JYyXjD3Q29Q78+ropef5L18CLRjuLVeT/GncKPQgYZrdAUa I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAOEeVCtJXHB/2dsb2JhbABFhhK4ZHWBCIIgAQEBAwEBAQEPARARIRkDCAUHBAIBCBEEAQEBAgIGHQMCAgIlCxQBCAgCBA4FCAEZh1wGC5wVjR+SM4EhijgUBgiFCTJgA6QxgWuCbYFaCTQ X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131267340" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 13 Oct 2012 15:13:44 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9DFDibb031257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 15:13:44 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 10:13:43 -0500 From: "JP Vasseur (jvasseur)" To: Yuichi IGARASHI Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqVVVxQdayxYbx0aw5eRdXfbe8w== Date: Sat, 13 Oct 2012 15:13:43 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD56A1@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <507983D0.1040508@hitachi.com> In-Reply-To: <507983D0.1040508@hitachi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--65.674100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:13:46 -0000 U3VyZSBZaXVjaGktc2FuLCBhZ3JlZWQsIHRvIHN0aWNrIHRvIExMTnMuDQoNCk9uIE9jdCAxMywg MjAxMiwgYXQgNTowOCBQTSwgWXVpY2hpIElHQVJBU0hJIHdyb3RlOg0KDQo+IEhpIEpQLA0KPiAN Cj4+IEp1c3QgdG8gbWFrZSBzdXJlIHRoYXQgd2UgZG8gbm90IHBsYXkgd2l0aCB3b3JkcyDigKYu IEFzIGFncmVlZCBiZXR3ZWVuIHRoZSBjaGFpcnMsIGl0IHNob3VsZCByZWFkICINCj4gSSdtIG5v dCBzdXJlIHdoeSB5b3Ugc3VkZGVubHkgbWVudGlvbmVkIGFib3V0ICJJb1QiLg0KPiBXZSBkaXNj dXNzIGFib3V0IE1BTkVUIGFuZCBqdXN0IExMTi4NCj4gDQo+IFJlZ2FyZGluZyBJb1QsIHRoZXJl IGFyZSBzb21lIElvVCBhcHBsaWNhdGlvbnMoZm9yIGV4YW1wbGUsIGxpdmVzdG9jaywgZGFpcnkg aHVzYmFuZHJ5LGV0YykgdGhhdCBtb3N0IHNlbnNvcnMgYXJlIG5vdCBmaXhlZCBidXQgbW9iaWxl IG9uZXMuDQo+IA0KPiBJIHRoaW5rIHdlIHNob3VsZCBub3QgYWRkIHN1Y2ggYSBuZXcgd29yZCB0 byB0aGlzIGRpc2N1c3Npb24sIG5vdCB0byBtYWtlIGl0IGNvbXBsZXguDQo+IA0KPiBCZXN0IHJl Z2FyZHMsDQo+IFl1aWNoaQ0KPiAoMjAxMi8xMC8xMyAxODoyMSksIEpQIFZhc3NldXIgKGp2YXNz ZXVyKSB3cm90ZToNCj4+IEhpIFVscmljaCwNCj4+IA0KPj4gT24gT2N0IDEyLCAyMDEyLCBhdCA1 OjM4IFBNLCBVbHJpY2ggSGVyYmVyZyB3cm90ZToNCj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+IChz cGVha2luZyBvbiBteSBvd24sIG5vdCB0byByZXByZXNlbnRpbmcgdGhlIExPQURuZyBhdXRob3Jz KS4NCj4+PiANCj4+PiBBcyB3YXMgcG9pbnRlZCBvdXQgYmVmb3JlLCB3ZSBvZnRlbiBoYXZlIGRp c2N1c3NlZCBpdGVtcyB0aGF0IHdlcmUgbm90IFdHIGRvY3VtZW50cywgdXN1YWxseSBhdCB0aGUg ZW5kIG9mIHRoZSBtZWV0aW5nLCB0byBtYWtlIHN1cmUgdGhhdCB0aGVyZSBpcyBlbm91Z2ggdGlt ZSBmb3IgV0cgaXRlbXMuIEkgYWxzbyBhZ3JlZSB3aXRoIHdoYXQgU3RhbiBzYWlkOiBNQU5FVCBz aG91bGQgbm90IGJlIHN0YW5kYXJkaXppbmcgZG9jdW1lbnRzIHRoYXQgYXJlIG1haW5seSBmb2N1 c2VkIG9uIExMTnM7DQo+PiANCj4+IEp1c3QgdG8gbWFrZSBzdXJlIHRoYXQgd2UgZG8gbm90IHBs YXkgd2l0aCB3b3JkcyDigKYuIEFzIGFncmVlZCBiZXR3ZWVuIHRoZSBjaGFpcnMsIGl0IHNob3Vs ZCByZWFkICJNQU5FVCBpcyBzdGFuZGFyZGl6aW5nIGRvY3VtZW50cyB0aGF0IGFyZSBub3QgZGVh bGluZyB3aXRoIExMTnMvSW9UIi4NCj4+IFRoaXMgaXMgbXVjaCBzdHJvbmdlciB0aGF0ICJtYWlu bHkgb24gTExOcyINCj4+IA0KPj4gVGhhbmtzLg0KPj4gDQo+PiBKUC4NCj4+IA0KPj4+IGhvd2V2 ZXIsIGEgZG9jdW1lbnQgdGhhdCBpcyBmb2N1c2VkIG9uIE1BTkVUUywgYW5kIGFzIGEgbWF0dGVy IG9mIGZhY3QgaXMgYWxzbyB1c2VkIGluIExMTiBkZXBsb3ltZW50cyBzaG91bGQgYmUgYWNjZXB0 YWJsZSwgaW4gbXkgb3Bpbmlvbi4NCj4+PiANCj4+PiBXZSBhcmUgY3VycmVudGx5IGZpbmFsaXpp bmcgc29tZSBpbnRlcm5hbCBkaXNjdXNzaW9ucyBiZXR3ZWVuIHRoZSBhdXRob3JzIG9mIExPQURu ZywgYW5kIEkgdGhpbmsgdGhhdCB0aGVyZSB3aWxsIGJlIGFuIGVtYWlsIHRvIHRoZSBsaXN0IG9u IHRoYXQgcmVnYXJkcyBpbiB0aGUgbmV4dCBmZXcgZGF5cy4gQWJkdXNzYWxhbSwgYmVpbmcgYWdh aW5zdCBwcmVzZW50YXRpb24gb2Ygc29tZXRoaW5nIHRoYXQgaGFzIG5vdCBldmVuIGJlZW4gcHJv cG9zZWQgeWV0IGlzIHByZW1hdHVyZSBhbmQgcG9pbnRsZXNzLCBpbiBteSBvcGluaW9uLg0KPj4+ IA0KPj4+IEJlc3QgcmVnYXJkcw0KPj4+IFVscmljaA0KPj4+IA0KPj4+IE9uIE9jdCAxMiwgMjAx MiwgYXQgNzoxNSwgIkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIjxDaHJpcy5EZWFybG92ZUBi YWVzeXN0ZW1zLmNvbT4gIHdyb3RlOg0KPj4+IA0KPj4+PiBJIHRoaW5rIHlvdSBhcmUgaW4gdmlv bGVudCBhZ3JlZW1lbnQuIFRoZSBjdXJyZW50IExPQURuZyBkcmFmdCBpcyAoSUlSQykgYWltZWQg YXQgTExOcywgc28gVGVjbyBpcyBzYXlpbmcgdW5sZXNzIHRoZXJlJ3MgYSBuZXcgTUFORVQtb3Jp ZW50ZWQgdmVyc2lvbiBpdCBzaG91bGRuJ3QgYmUgZGlzY3Vzc2VkLCBhbmQgeW91IGFyZSBzYXlp bmcgaXQgd29uJ3QgYmUgZGlzY3Vzc2VkLg0KPj4+PiANCj4+Pj4gLS0NCj4+Pj4gQ2hyaXN0b3Bo ZXIgRGVhcmxvdmUNCj4+Pj4gU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgQ29tbXVuaWNhdGlv bnMgR3JvdXANCj4+Pj4gQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNp cyBDYXBhYmlsaXR5DQo+Pj4+IEJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJl DQo+Pj4+IFdlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwg Q00yIDhITiwgVUsNCj4+Pj4gVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAy NDIxMjQNCj4+Pj4gY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJh ZXN5c3RlbXMuY29tDQo+Pj4+IA0KPj4+PiBCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRl ZA0KPj4+PiBSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJu Ym9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBV Sw0KPj4+PiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQmICBXYWxlcyBObzogMTk5NjY4Nw0KPj4+PiAN Cj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFN0YW4g UmF0bGlmZiAoc3JhdGxpZmYpIFttYWlsdG86c3JhdGxpZmZAY2lzY28uY29tXQ0KPj4+PiBTZW50 OiAxMiBPY3RvYmVyIDIwMTIgMTU6MTINCj4+Pj4gVG86IFRlY28gQm9vdA0KPj4+PiBDYzogRGVh cmxvdmUsIENocmlzdG9waGVyIChVSyk7PG1hbmV0QGlldGYub3JnPiAgTGlzdDsgQm8gQmVycnkg KGJvYmVycnkpDQo+Pj4+IFN1YmplY3Q6IFJlOiBbbWFuZXRdIE1BTkVUIG1lZXRpbmcgYXQgSUVU Rjg1DQo+Pj4+IA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXNhdGlvbiwNCj4+Pj4gZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5l ciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCj4+Pj4gS2VlcCB0aGlzIGluIG1pbmQgaWYgeW91IGFu c3dlciB0aGlzIG1lc3NhZ2UuDQo+Pj4+IEZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVt YWlscycgbGluayBvbiBJVCBtYXR0ZXJzDQo+Pj4+IGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0 aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IA0KPj4+PiBPbiBPY3Qg MTIsIDIwMTIsIGF0IDk6MzMgQU0sIFRlY28gQm9vdCB3cm90ZToNCj4+Pj4gDQo+Pj4+PiBPbiBK dWx5IDMxdGgsIG91ciBjaGFpciBwcm92aWRlZCBndWlkYW5jZSBvbiBoYW5kbGluZyBMT0FEbmcu DQo+Pj4+PiBJdCBzaG93cyB0aGUgd2F5IGZvcndhcmQuDQo+Pj4+PiANCj4+Pj4+IEknbSBsb29r aW5nIGZvcndhcmQgdG8gYW4gZHJhZnQtYXV0aG9yLW1hbmV0LWxvYWRuZy0wMCBkcmFmdCwgc3Vi bWl0dGVkIGJlZm9yZSBuZXh0IE1vbmRheS4NCj4+Pj4+IElmIHRoZXJlIGlzIG5vIHN1Y2ggZHJh ZnQsIGFuZCBsaXR0bGUgdGltZSB0byBkaXNjdXNzIG5vbi13ZyBkcmFmdHMsIHdlIHNob3VsZCBu b3QgZGlzY3VzcyBhbiBsbG4gZHJhZnQgaW4gb3VyIG1lZXRpbmcgaW4gQXRsYW50YS4NCj4+Pj4g DQo+Pj4+IE9uZSAobm90IHRvbykgZmluZSBwb2ludCAtIHdlICh0aGUgTUFORVQgV0cpIHdpbGwg Km5vdCogYmUgZGlzY3Vzc2luZyBhbiBMTE4gZHJhZnQuIEF0IGFueSB0aW1lLiBUaGF0IHdvdWxk IGJlIGEgY2hhcnRlciB2aW9sYXRpb24gLSBMTE4ncyBhcmUgZGVmaW5lZCBhbmQgd29ya2VkIGlu IFJPTEwuIFdlIGFyZSBkaXNjdXNzaW5nIE1BTkVUIHJlYWN0aXZlIHByb3RvY29scy4NCj4+Pj4g DQo+Pj4+IFN0YW4NCj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gSSdtIE9LIG9uIGRpc2N1c3Npb25zIG9u IGhvdyB0byBmdWxmaWxsIG91ciBjaGFydGVyIGl0ZW0gb24gYSByZWFjdGl2ZSBwcm90b2NvbC4N Cj4+Pj4+IA0KPj4+Pj4gVGVjbw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9wIDEyIG9rdC4gMjAx Miwgb20gMTU6MTkgaGVlZnQgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgaGV0IHZvbGdlbmRl IGdlc2NocmV2ZW46DQo+Pj4+PiANCj4+Pj4+PiBXZSBoYXZlIG9mdGVuIGRpc2N1c3NlZCB0aGlu Z3Mgbm90IHlldCBhY2NlcHRlZCBieSB0aGUgV0csIGl0IGNhbiBiZSBhIHN0ZXAgdG93YXJkcyBn ZXR0aW5nIHRoZW0gYWNjZXB0ZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhhdCdzIG5vdCBhIGNvbW1l bnQgZm9yIG9yIGFnYWluc3QgTE9BRG5nLCBkaXNjdXNzaW5nIExPQURuZywgb3IgYWRvcHRpbmcg TE9BRG5nLCBqdXN0IGFuIG9ic2VydmF0aW9uIG9uIHdoYXQgaGFzIGhhcHBlbmVkIGluIHRoZSBw YXN0Lg0KPj4+Pj4+IA0KPj4+Pj4+IC0tDQo+Pj4+Pj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4+ Pj4+PiBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBDb21tdW5pY2F0aW9ucyBHcm91cA0KPj4+ Pj4+IENvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0 eQ0KPj4+Pj4+IEJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQo+Pj4+Pj4g V2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhO LCBVSw0KPj4+Pj4+IFRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0 DQo+Pj4+Pj4gY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5 c3RlbXMuY29tDQo+Pj4+Pj4gDQo+Pj4+Pj4gQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0 ZWQNCj4+Pj4+PiBSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBG YXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllV LCBVSw0KPj4+Pj4+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCYgIFdhbGVzIE5vOiAxOTk2Njg3DQo+ Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ PiBGcm9tOiBtYW5ldC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJvIEJlcnJ5DQo+Pj4+Pj4gU2VudDogMTIgT2N0b2JlciAyMDEy IDEzOjQwDQo+Pj4+Pj4gVG86IEFiZHVzc2FsYW0gQmFyeXVuOzxtYW5ldEBpZXRmLm9yZz4gIExp c3Q7IEJvIEJlcnJ5DQo+Pj4+Pj4gU3ViamVjdDogUmU6IFttYW5ldF0gTUFORVQgbWVldGluZyBh dCBJRVRGODUNCj4+Pj4+PiANCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5H ICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+IFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLA0KPj4+Pj4+IGVpdGhlciBmcm9tIGFuIGV4 dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQo+Pj4+Pj4gS2VlcCB0aGlzIGlu IG1pbmQgaWYgeW91IGFuc3dlciB0aGlzIG1lc3NhZ2UuDQo+Pj4+Pj4gRm9sbG93IHRoZSAnUmVw b3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMNCj4+Pj4+PiBmb3IgaW5z dHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KPj4+Pj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4+Pj4gDQo+Pj4+Pj4gTG9va2luZyBhdCB0aGUgTUFORVQgV0cgRG9jdW1lbnRzIHBhZ2Us IExPQURuZyBpcyBub3Qgb24gdGhlIGxpc3QuIFNvIHVudGlsIExPQURuZyBpcyBhY2NlcHRlZCBi eSB0aGUgV0csIGdvdHRhIGFncmVlIHdpdGggQWJkdXNzYWxhbSwgbm8gbmVlZCB0byBkaXNjdXNz IGl0IGluIHRoZSBsaXR0bGUgdGltZSB3ZSBoYXZlIGZvciB0aGUgd29yayB3ZSd2ZSBhbHJlYWR5 IGFjY2VwdGVkLg0KPj4+Pj4+IA0KPj4+Pj4+IEhvdyBkb2VzIHRoaXMgZml0IGludG8gdGhlIFdH IENoYXJ0ZXI/DQo+Pj4+Pj4gDQo+Pj4+Pj4gLUJvDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g QWN0aXZlIEludGVybmV0LURyYWZ0cw0KPj4+Pj4+IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0wMyAg ICBEeW5hbWljIExpbmsgRXhjaGFuZ2UgUHJvdG9jb2wgKERMRVApDQo+Pj4+Pj4gZHJhZnQtaWV0 Zi1tYW5ldC1uaGRwLW1pYi0xOSAgICBEZWZpbml0aW9uIG9mIE1hbmFnZWQgT2JqZWN0cyBmb3Ig dGhlIE5laWdoYm9yaG9vZCBEaXNjb3ZlcnkgUHJvdG9jb2wNCj4+Pj4+PiBkcmFmdC1pZXRmLW1h bmV0LW5oZHAtc2VjLTAyICAgIFVzaW5nIEludGVncml0eSBDaGVjayBWYWx1ZXMgYW5kIFRpbWVz dGFtcHMgRm9yIFJvdXRlciBBZG1pdHRhbmNlIGluIE5IRFANCj4+Pj4+PiBkcmFmdC1pZXRmLW1h bmV0LW9sc3J2Mi0xNiAgICBUaGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2Nv bCB2ZXJzaW9uIDINCj4+Pj4+PiBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tZXRyaWNzLXJhdGlv bmFsZS0wMSAgICBMaW5rIE1ldHJpY3MgZm9yIHRoZSBNb2JpbGUgQWQgSG9jIE5ldHdvcmsgKE1B TkVUKSBSb3V0aW5nDQo+Pj4+Pj4gZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbWliLTA0ICAgIERl ZmluaXRpb24gb2YgTWFuYWdlZCBPYmplY3RzIGZvciB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUg Um91dGluZyBQcm90b2NvbA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IE9uIE9j dCAxMiwgMjAxMiwgYXQgNzozOSBBTSwgQm8gQmVycnkgd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4+ IEkndmUgc2VlbiBhIG51bWJlciBvZiBlbWFpbHMgb24gdGhlIGFsaWFzIGJ1dCBub3Qgc3VyZSBM T0FEbmcNCj4+Pj4+Pj4gaGFzIGJlZW4gYWNjZXB0ZWQgYnkgdGhlIFdHLiAgSXMgTE9BRG5nIGFz a2luZyB0byBiZSBhIE1BTkVUIFdHDQo+Pj4+Pj4+IGRyYWZ0Pw0KPj4+Pj4+PiANCj4+Pj4+Pj4g LUJvDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gT2N0IDEyLCAyMDEyLCBhdCA1OjM0 IEFNLCBBYmR1c3NhbGFtIEJhcnl1biB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBQbGVhc2Ug bm90ZSB0aGF0IEkgc3Ryb25nbHkgb2JqZWN0IGFueSBpbmNsdWRpbmcgb2YgTE9BRG5nIGRyYWZ0 IGluIHRoZSBBZ2VuZGEuDQo+Pj4+Pj4+PiBUaGUgZG9jdW1lbnQgaXMgbm90IGZvciBNQU5FVCwg d2FzIGFscmVhZHkgcHJlc2VudGVkIGJlZm9yZSwgYW5kIHRoZQ0KPj4+Pj4+Pj4gYXV0aG9ycyBh cmUgbm90IGRpc2N1c3Npbmcgb24gaWV0ZiBsaXN0cyBvZiBhbnkgcHJvZ3Jlc3MuIFRoZSBkcmFm dCBpcw0KPj4+Pj4+Pj4gbm90IHJlYXNvbmFibGUgZm9yIHRoZSBXRywgaWYgaXQgaXMgbm90IGRp c2N1c3NlZCBvbiB0aGUgTUFORVQgbGlzdC4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSSBnb3Qgbm8g cmVhc29uYWJsZSByZXBseSB0byBhbGwgbXkgZWZmb3J0cywgdGhlIGxhc3QgYXM6DQo+Pj4+Pj4+ PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cx MzQ0OC5odG1sDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEFCDQo+Pj4+Pj4+PiBPbiAxMC85LzEyLCBV bHJpY2ggSGVyYmVyZzx1bHJpY2hAaGVyYmVyZy5uYW1lPiAgd3JvdGU6DQo+Pj4+Pj4+Pj4gSGks DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gdGhlIE1BTkVUIFdHIHdpbGwgbWVldCBvbiBXZWRuZXNk YXksIE5vdi4gNyBmcm9tIDFwbSB0byAyLjMwcG0gaW4gU2Fsb24gQS4NCj4+Pj4+Pj4+PiBJZiB5 b3UgaW50ZW5kIHRvIHByZXNlbnQgc29tZXRoaW5nLCBwbGVhc2Ugc2VuZCBhIHJlcXVlc3QgdG8g dGhlIGNoYWlycy4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBCZXN0IHJlZ2FyZHMNCj4+Pj4+Pj4+ PiBVbHJpY2gNCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4+PiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IG1hbmV0QGll dGYub3JnDQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h bmV0DQo+Pj4+Pj4+IA0KPj4+Pj4+PiAtLS0NCj4+Pj4+Pj4gV2UgY2Fubm90IHNvbHZlIG91ciBw cm9ibGVtcyB3aXRoIHRoZSBzYW1lIHRoaW5raW5nIHdlIHVzZWQgd2hlbiB3ZSBjcmVhdGVkIHRo ZW0uDQo+Pj4+Pj4+IEFsYmVydCBFaW5zdGVpbg0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+PiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gbWFuZXRAaWV0Zi5vcmcNCj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPj4+Pj4+ IA0KPj4+Pj4+IC0tLQ0KPj4+Pj4+IFdlIGNhbm5vdCBzb2x2ZSBvdXIgcHJvYmxlbXMgd2l0aCB0 aGUgc2FtZSB0aGlua2luZyB3ZSB1c2VkIHdoZW4gd2UgY3JlYXRlZCB0aGVtLg0KPj4+Pj4+IEFs YmVydCBFaW5zdGVpbg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbWFuZXQgbWFp bGluZyBsaXN0DQo+Pj4+Pj4gbWFuZXRAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCj4+Pj4+PiBUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCj4+Pj4+PiByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4+Pj4+IHJlY2lwaWVu dCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVy Lg0KPj4+Pj4+IFlvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSBub3IgZGlzY2xvc2Ugb3INCj4+Pj4+PiBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLg0KPj4+Pj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pj4+Pj4gDQo+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBtYW5ldCBt YWlsaW5nIGxpc3QNCj4+Pj4+PiBtYW5ldEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG1hbmV0IG1haWxpbmcg bGlzdA0KPj4+Pj4gbWFuZXRAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQNCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBtYW5ldCBtYWlsaW5nIGxpc3QN Cj4+Pj4gbWFuZXRAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tYW5ldA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gbWFuZXQgbWFpbGluZyBsaXN0DQo+Pj4gbWFuZXRAaWV0Zi5vcmcNCj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+PiANCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtYW5ldCBt YWlsaW5nIGxpc3QNCj4+IG1hbmV0QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+PiANCj4gDQo+IC0tIA0KPiBIaXRhY2hpLCBMdGQuLCBZ b2tvaGFtYSBSZXNlYXJjaCBMYWJvcmF0b3J5DQo+IElHQVJBU0hJIFl1aWNoaQ0KPiBNYWls77ya IHl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNvbQ0KPiBUZWwg77yaICs4MS0oMCk0NS04NjAt MzA4Mw0KPiBGQVgg77yaICs4MS0oMCk0NS04NjAtMTY3Mw0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFu ZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5l dA0KDQo= From ulrich@herberg.name Sat Oct 13 08:26:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5D21F84FA for ; Sat, 13 Oct 2012 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4Jd9lMk4Oxk for ; Sat, 13 Oct 2012 08:26:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF7221F84F3 for ; Sat, 13 Oct 2012 08:26:37 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4937894vcb.31 for ; Sat, 13 Oct 2012 08:26:37 -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=VaLDVCqEZrFFm31bkKlW0L6w7Itd6mKBw+EZNb/IuX8=; b=20ohUeD3B/4Yrr6StqISq9Zo9lihi+GJ1KmkOznMZSCiHqfgvQccBRmiBvYthcZZI/ fmNjLbDsyDTQL3vWWMsGfHEe462Oc7t0zQzKTeFLKLQwNoVdBSI6zlaw2ORCmYXL6pbY /HDRLV93dIHAAYC/krrygnT884ZuMlMKLb+vw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VaLDVCqEZrFFm31bkKlW0L6w7Itd6mKBw+EZNb/IuX8=; b=KXIq4+UXXu5CQTQ9CQFwxk1XQjDJtMyg8p4zf59q3rAP27GgMIsNkQg2jqU8/Q9PLX GvdQdTMZcRzAPMPR3vx1qkM2aN9BZTXtVEpxdGHQsa46lSMnjgIizT3YlZTzrGSFdnY6 ZJ10LZwqLVeF9CoS3wEUh6sX06J4L7NrM5/sHFAbeW8cwtIAePk8VpoV7abtUwY3W6hp rK2wHxqZwKGouXHbM44OnB+JPHyLND+udtKqgcJ+LMEH7HTLZoxMQMrPqyp1o+vwm8e/ 3XZZ7nv06rrgzHEFjU7QjKYCLQThGVb9opLa8KyapoxNcjJT2uxeGgwAjCMYBpen/R+d wTuw== MIME-Version: 1.0 Received: by 10.221.0.74 with SMTP id nl10mr4123683vcb.47.1350141996622; Sat, 13 Oct 2012 08:26:36 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Sat, 13 Oct 2012 08:26:36 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> Date: Sat, 13 Oct 2012 08:26:36 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=bcaec54fb0c21ae44704cbf26edc X-Gm-Message-State: ALoCoQm1802XO43GNCad4tXKLfX5K/PoSa9h/NNaqI9zGxNQGfmvyLer5cQNANALcGhdJ53o53cT Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:26:39 -0000 --bcaec54fb0c21ae44704cbf26edc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP, On Sat, Oct 13, 2012 at 2:21 AM, JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote: > > > Hi, > > > > (speaking on my own, not to representing the LOADng authors). > > > > As was pointed out before, we often have discussed items that were not > WG documents, usually at the end of the meeting, to make sure that there = is > enough time for WG items. I also agree with what Stan said: MANET should > not be standardizing documents that are mainly focused on LLNs; > > Just to make sure that we do not play with words =85. As agreed between t= he > chairs, it should read "MANET is standardizing documents that are not > dealing with LLNs/IoT". > This is much stronger that "mainly on LLNs" > I think (as MANET participant, not LOADng author) that the reactive protocol in the MANET WG should be a *MANET protocol*. I also think that a Standards Track document can (or maybe should) mention where it is used in deployments and implementations. As a matter of fact, LOADng is used in LLN deployments, and I think this is important to mention. This is just one use case of LOADng, not the only one. As Adrian said at the last IETF "some if not all LLNs are MANET, but not all MANETs are LLNs"; as such, I think it is fair to mention use cases of LOADng and deployments (and clearly there should be many more use cases that those) I think this would be fully in charter of MANET, and would not coincide with any other WG. Regards Ulrich > > Thanks. > > JP. > > > however, a document that is focused on MANETS, and as a matter of fact > is also used in LLN deployments should be acceptable, in my opinion. > > > > We are currently finalizing some internal discussions between the > authors of LOADng, and I think that there will be an email to the list on > that regards in the next few days. Abdussalam, being against presentation > of something that has not even been proposed yet is premature and > pointless, in my opinion. > > > > Best regards > > Ulrich > > > > On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > > >> I think you are in violent agreement. The current LOADng draft is > (IIRC) aimed at LLNs, so Teco is saying unless there's a new MANET-orient= ed > version it shouldn't be discussed, and you are saying it won't be discuss= ed. > >> > >> -- > >> Christopher Dearlove > >> Senior Principal Engineer, Communications Group > >> Communications, Networks and Image Analysis Capability > >> BAE Systems Advanced Technology Centre > >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> chris.dearlove@baesystems.com | http://www.baesystems.com > >> > >> BAE Systems (Operations) Limited > >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > >> Registered in England & Wales No: 1996687 > >> > >> > >> -----Original Message----- > >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > >> Sent: 12 October 2012 15:12 > >> To: Teco Boot > >> Cc: Dearlove, Christopher (UK); List; Bo Berry > (boberry) > >> Subject: Re: [manet] MANET meeting at IETF85 > >> > >> ----------------------! WARNING ! ---------------------- > >> This message originates from outside our organisation, > >> either from an external partner or from the internet. > >> Keep this in mind if you answer this message. > >> Follow the 'Report Suspicious Emails' link on IT matters > >> for instructions on reporting suspicious email messages. > >> -------------------------------------------------------- > >> > >> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: > >> > >>> On July 31th, our chair provided guidance on handling LOADng. > >>> It shows the way forward. > >>> > >>> I'm looking forward to an draft-author-manet-loadng-00 draft, > submitted before next Monday. > >>> If there is no such draft, and little time to discuss non-wg drafts, > we should not discuss an lln draft in our meeting in Atlanta. > >> > >> One (not too) fine point - we (the MANET WG) will *not* be discussing > an LLN draft. At any time. That would be a charter violation - LLN's are > defined and worked in ROLL. We are discussing MANET reactive protocols. > >> > >> Stan > >> > >> > >>> I'm OK on discussions on how to fulfill our charter item on a reactiv= e > protocol. > >>> > >>> Teco > >>> > >>> > >>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het > volgende geschreven: > >>> > >>>> We have often discussed things not yet accepted by the WG, it can be > a step towards getting them accepted. > >>>> > >>>> That's not a comment for or against LOADng, discussing LOADng, or > adopting LOADng, just an observation on what has happened in the past. > >>>> > >>>> -- > >>>> Christopher Dearlove > >>>> Senior Principal Engineer, Communications Group > >>>> Communications, Networks and Image Analysis Capability > >>>> BAE Systems Advanced Technology Centre > >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>>> > >>>> BAE Systems (Operations) Limited > >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > >>>> Registered in England & Wales No: 1996687 > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > Behalf Of Bo Berry > >>>> Sent: 12 October 2012 13:40 > >>>> To: Abdussalam Baryun; List; Bo Berry > >>>> Subject: Re: [manet] MANET meeting at IETF85 > >>>> > >>>> ----------------------! WARNING ! ---------------------- > >>>> This message originates from outside our organisation, > >>>> either from an external partner or from the internet. > >>>> Keep this in mind if you answer this message. > >>>> Follow the 'Report Suspicious Emails' link on IT matters > >>>> for instructions on reporting suspicious email messages. > >>>> -------------------------------------------------------- > >>>> > >>>> Looking at the MANET WG Documents page, LOADng is not on the list. S= o > until LOADng is accepted by the WG, gotta agree with Abdussalam, no need = to > discuss it in the little time we have for the work we've already accepted= . > >>>> > >>>> How does this fit into the WG Charter? > >>>> > >>>> -Bo > >>>> > >>>> > >>>> Active Internet-Drafts > >>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) > >>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for th= e > Neighborhood Discovery Protocol > >>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and > Timestamps For Router Admittance in NHDP > >>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing > Protocol version 2 > >>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the > Mobile Ad Hoc Network (MANET) Routing > >>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for > the Optimized Link State Routing Protocol > >>>> > >>>> > >>>> > >>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: > >>>> > >>>>> I've seen a number of emails on the alias but not sure LOADng > >>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG > >>>>> draft? > >>>>> > >>>>> -Bo > >>>>> > >>>>> > >>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: > >>>>> > >>>>>> Please note that I strongly object any including of LOADng draft i= n > the Agenda. > >>>>>> The document is not for MANET, was already presented before, and t= he > >>>>>> authors are not discussing on ietf lists of any progress. The draf= t > is > >>>>>> not reasonable for the WG, if it is not discussed on the MANET lis= t. > >>>>>> > >>>>>> I got no reasonable reply to all my efforts, the last as: > >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html > >>>>>> > >>>>>> AB > >>>>>> On 10/9/12, Ulrich Herberg wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in > Salon A. > >>>>>>> If you intend to present something, please send a request to the > chairs. > >>>>>>> > >>>>>>> Best regards > >>>>>>> Ulrich > >>>>>> _______________________________________________ > >>>>>> manet mailing list > >>>>>> manet@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>> > >>>>> --- > >>>>> We cannot solve our problems with the same thinking we used when we > created them. > >>>>> Albert Einstein > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> manet mailing list > >>>>> manet@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/manet > >>>> > >>>> --- > >>>> We cannot solve our problems with the same thinking we used when we > created them. > >>>> Albert Einstein > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> manet mailing list > >>>> manet@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/manet > >>>> > >>>> > >>>> ******************************************************************** > >>>> This email and any attachments are confidential to the intended > >>>> recipient and may also be privileged. If you are not the intended > >>>> recipient please delete it from your system and notify the sender. > >>>> You should not copy it or use it for any purpose nor disclose or > >>>> distribute its contents to any other person. > >>>> ******************************************************************** > >>>> > >>>> _______________________________________________ > >>>> manet mailing list > >>>> manet@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/manet > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > --bcaec54fb0c21ae44704cbf26edc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP,

On Sat, Oct 13, 2012 at 2:21 AM, J= P Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
Hi Ulrich,

On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote:

> Hi,
>
> (speaking on my own, not to representing the LOADng authors).
>
> As was pointed out before, we often have discussed items that were not= WG documents, usually at the end of the meeting, to make sure that there i= s enough time for WG items. I also agree with what Stan said: MANET should = not be standardizing documents that are mainly focused on LLNs;

Just to make sure that we do not play with words =85. As agreed betwe= en the chairs, it should read "MANET is standardizing documents that a= re not dealing with LLNs/IoT".
This is much stronger that "mainly on LLNs"
=

I think (as MANET participant, not LOADng aut= hor) that the reactive protocol in the MANET WG should be a *MANET protocol= *. I also think that a Standards Track document can (or maybe should) menti= on where it is used in deployments and implementations. As a matter of fact= , LOADng is used in LLN deployments, and I think this is important to menti= on. This is just one use case of LOADng, not the only one. As Adrian said a= t the last IETF "some if not all = LLNs are MANET, but not all MANETs are LLNs"; as such, I think = it is fair to mention use cases of LOADng and deployments (and clearly ther= e should be many more use cases that those)
I think this would be fully in charter of MANET, and would not coincid= e with any other WG.

Regards
Ulrich

=A0

Thanks.

JP.

> however, a document that is focused on MANETS, and as a matter of fact= is also used in LLN deployments should be acceptable, in my opinion.
>
> We are currently finalizing some internal discussions between the auth= ors of LOADng, and I think that there will be an email to the list on that = regards in the next few days. Abdussalam, being against presentation of som= ething that has not even been proposed yet is premature and pointless, in m= y opinion.
>
> Best regards
> Ulrich
>
> On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" <<= a href=3D"mailto:Chris.Dearlove@baesystems.com">Chris.Dearlove@baesystems.c= om> wrote:
>
>> I think you are in violent agreement. The current LOADng draft is = (IIRC) aimed at LLNs, so Teco is saying unless there's a new MANET-orie= nted version it shouldn't be discussed, and you are saying it won't= be discussed.
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
>> chris.dearlove@ba= esystems.com | = http://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
>> Sent: 12 October 2012 15:12
>> To: Teco Boot
>> Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berry (boberry)
>> Subject: Re: [manet] MANET meeting at IETF85
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:
>>
>>> On July 31th, our chair provided guidance on handling LOADng.<= br> >>> It shows the way forward.
>>>
>>> I'm looking forward to an draft-author-manet-loadng-00 dra= ft, submitted before next Monday.
>>> If there is no such draft, and little time to discuss non-wg d= rafts, we should not discuss an lln draft in our meeting in Atlanta.
>>
>> One (not too) fine point - we (the MANET WG) will *not* be discuss= ing an LLN draft. At any time. That would be a charter violation - LLN'= s are defined and worked in ROLL. We are discussing MANET reactive protocol= s.
>>
>> Stan
>>
>>
>>> I'm OK on discussions on how to fulfill our charter item o= n a reactive protocol.
>>>
>>> Teco
>>>
>>>
>>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het= volgende geschreven:
>>>
>>>> We have often discussed things not yet accepted by the WG,= it can be a step towards getting them accepted.
>>>>
>>>> That's not a comment for or against LOADng, discussing= LOADng, or adopting LOADng, just an observation on what has happened in th= e past.
>>>>
>>>> --
>>>> Christopher Dearlove
>>>> Senior Principal Engineer, Communications Group
>>>> Communications, Networks and Image Analysis Capability
>>>> BAE Systems Advanced Technology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,= UK
>>>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
>>>> chris.dea= rlove@baesystems.com | http://www.baesystems.com
>>>>
>>>> BAE Systems (Operations) Limited
>>>> Registered Office: Warwick House, PO Box 87, Farnborough A= erospace Centre, Farnborough, Hants, GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: manet-boun= ces@ietf.org [mailto:manet-bo= unces@ietf.org] On Behalf Of Bo Berry
>>>> Sent: 12 October 2012 13:40
>>>> To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
>>>> Subject: Re: [manet] MANET meeting at IETF85
>>>>
>>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation,
>>>> either from an external partner or from the internet.
>>>> Keep this in mind if you answer this message.
>>>> Follow the 'Report Suspicious Emails' link on IT m= atters
>>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>
>>>> Looking at the MANET WG Documents page, LOADng is not on t= he list. So until LOADng is accepted by the WG, gotta agree with Abdussalam= , no need to discuss it in the little time we have for the work we've a= lready accepted.
>>>>
>>>> How does this fit into the WG Charter?
>>>>
>>>> -Bo
>>>>
>>>>
>>>> Active Internet-Drafts
>>>> draft-ietf-manet-dlep-03 =A0 =A0Dynamic Link Exchange Prot= ocol (DLEP)
>>>> draft-ietf-manet-nhdp-mib-19 =A0 =A0Definition of Managed = Objects for the Neighborhood Discovery Protocol
>>>> draft-ietf-manet-nhdp-sec-02 =A0 =A0Using Integrity Check = Values and Timestamps For Router Admittance in NHDP
>>>> draft-ietf-manet-olsrv2-16 =A0 =A0The Optimized Link State= Routing Protocol version 2
>>>> draft-ietf-manet-olsrv2-metrics-rationale-01 =A0 =A0Link M= etrics for the Mobile Ad Hoc Network (MANET) Routing
>>>> draft-ietf-manet-olsrv2-mib-04 =A0 =A0Definition of Manage= d Objects for the Optimized Link State Routing Protocol
>>>>
>>>>
>>>>
>>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:
>>>>
>>>>> I've seen a number of emails on the alias but not = sure LOADng
>>>>> has been accepted by the WG. =A0Is LOADng asking to be= a MANET WG
>>>>> draft?
>>>>>
>>>>> -Bo
>>>>>
>>>>>
>>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote:<= br> >>>>>
>>>>>> Please note that I strongly object any including o= f LOADng draft in the Agenda.
>>>>>> The document is not for MANET, was already present= ed before, and the
>>>>>> authors are not discussing on ietf lists of any pr= ogress. The draft is
>>>>>> not reasonable for the WG, if it is not discussed = on the MANET list.
>>>>>>
>>>>>> I got no reasonable reply to all my efforts, the l= ast as:
>>>>>> http://www.ietf.org/mail-archi= ve/web/manet/current/msg13448.html
>>>>>>
>>>>>> AB
>>>>>> On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> the MANET WG will meet on Wednesday, Nov. 7 fr= om 1pm to 2.30pm in Salon A.
>>>>>>> If you intend to present something, please sen= d a request to the chairs.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Ulrich
>>>>>> _______________________________________________ >>>>>> manet mailing list
>>>>>> manet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>> ---
>>>>> We cannot solve our problems with the same thinking we= used when we created them.
>>>>> Albert Einstein
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>> ---
>>>> We cannot solve our problems with the same thinking we use= d when we created them.
>>>> Albert Einstein
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>> **********************************************************= **********
>>>> This email and any attachments are confidential to the int= ended
>>>> recipient and may also be privileged. If you are not the i= ntended
>>>> recipient please delete it from your system and notify the= sender.
>>>> You should not copy it or use it for any purpose nor discl= ose or
>>>> distribute its contents to any other person.
>>>> **********************************************************= **********
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--bcaec54fb0c21ae44704cbf26edc-- From ulrich@herberg.name Sat Oct 13 08:33:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9486621F855A for ; Sat, 13 Oct 2012 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+ApFvS0-mdl for ; Sat, 13 Oct 2012 08:33:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15CBE21F8551 for ; Sat, 13 Oct 2012 08:33:05 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4437313vbb.31 for ; Sat, 13 Oct 2012 08:33:05 -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=EwPR23L80/H/PDZ+3Fz/T8QwFxqxSpjIpf3+A7hDbmg=; b=GJBCAk9X9t/4LIn/gFKWDljVLvdmWIserujkxAQdGSwZ5ceQpc8Naab25OLyUmMtPn CqWmY1qyjnnozg13DYyI/cBI72fJGjuXusM1b06NjUpPTk18/ArTzBA22O8nkI6OF/D8 YWXl4odP71zAz7/cfIzWvencfucQjm5ixL4no= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EwPR23L80/H/PDZ+3Fz/T8QwFxqxSpjIpf3+A7hDbmg=; b=Z6Rxkd3vvlD5KjCKhhljTEwf1svjQ7bxIU0b2fDgBXonDofR8OacA55IqM9gEDAOoa YX8c5dQZXZcrqV8oOHgVWk8E76Da1fwgjzucV40oHYeaPOMD+/gDf6XDIZ0LlJFX+Ql3 Chmjt2B1SyvpG4182eV/deEkhw1BAjXYbryO6ZUmVZmtDggMXGmwWi7IT5bAsit+VppN 2ZYG9QuAcmJHJ3zDPOkicvWj1QLbys5+iNQlkcxQk5GHCeklVpUlp9ryInzbugvF5UEz kU5PLMzRAXM//w8i0gcecYsd2uxIXTwNyyzsZwkFcW9Ez0he/H/3iPs4ylKqaqpak3l+ +u0A== MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr3319225vdb.33.1350142385263; Sat, 13 Oct 2012 08:33:05 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Sat, 13 Oct 2012 08:33:04 -0700 (PDT) In-Reply-To: <29959252-16D7-470C-96A5-05E70D218849@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> Date: Sat, 13 Oct 2012 08:33:04 -0700 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: multipart/related; boundary=bcaec50162b54515d404cbf285f6 X-Gm-Message-State: ALoCoQl4DMtDCkyfdyhWIPNavHsbSvquHb2awSIcFsD8CUceXlinI9VW5bH0DXh3I5f+/yj+4CLE Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:33:08 -0000 --bcaec50162b54515d404cbf285f6 Content-Type: multipart/alternative; boundary=bcaec50162b54515cd04cbf285f5 --bcaec50162b54515cd04cbf285f5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi C=E9dric, On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet wrote= : > Hi all, > > I agree with Teco that the message from the chair ( > http://www.ietf.org/mail-archive/web/manet/current/msg13305.html) is a > good move. > In particular that "the LLN needs to be deemphasized as the primary > purpose if adopted as manet". > I agree. > > > However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 says in > its introduction that : > > The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next > Generation (LOADng) is a routing protocol, derived from AODV > [RFC3561 ] and extended for use in= Low power and Lossy Networks > (LLNs). > > The introduction will be largely changed in the next revision. > > So, removing LLNs' related material on this draft could get back to AODV = which is already RFC 3561. So what is the improvement ? > > That is not true. There are many improvements from what we learned from AODV, and which has been integrated when designing the protocol (see below) > > From what I understand, the LOADng purpose should be a new version of AOD= V addressing some of the points suggested by the MANET chair such as "impro= vements in heterogeneity support, simplification where sensible, improved c= ontrol plane flooding, better IPv6 support, and a eventually clear border g= ateway specification". > > That is exactly what LOADng does (and that will be clearer in the next revision). It allows for improved flooding (e.g. using SMF/MPR flooding), it has improved IPv6 support, it is more flexible through the use of RFC5444, it is simplified as several items from AODV (such as iRREP, precursor list) have been removed, it is easier to secure using the security architecture based on RFC5444/RFC6622 and by avoiding iRREPs. We still need to work in the clearer border gateway specification. > > In short : LLNs constraints and challenges should not be adressed by LOAD= ng, but LOADng could improve the AODV original specification for MANET netw= orks. > > As one (out of many) use cases are LLNs, experience from these deployments should be integrated. But since the reactive MANET protocol is a MANET protocol, there will be many other use cases which we also address in the draft. We have learned from the experience with AODV (and there is plenty, just Google Scholar for AODV), and I think that many of those learnings are integrated already in LOADng. Best regards Ulrich > > Is my understanding correct ? > > > Best, > > > C=E9dric. > > > Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit : > > I assume the authors take the guidance from our chair, posted in: > http://www.ietf.org/mail-archive/web/manet/current/msg13305.html > > If so, I do not see a reason not to discuss LOADng. > And yes, I am with Stan we will *not* discuss LLN topics in MANET meeting= s. > > Teco > > Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: > > Hi, > > > (speaking on my own, not to representing the LOADng authors). > > > As was pointed out before, we often have discussed items that were not > WG documents, usually at the end of the meeting, to make sure that there = is > enough time for WG items. I also agree with what Stan said: MANET should > not be standardizing documents that are mainly focused on LLNs; however, = a > document that is focused on MANETS, and as a matter of fact is also used = in > LLN deployments should be acceptable, in my opinion. > > > We are currently finalizing some internal discussions between the > authors of LOADng, and I think that there will be an email to the list on > that regards in the next few days. Abdussalam, being against presentation > of something that has not even been proposed yet is premature and > pointless, in my opinion. > > > Best regards > > Ulrich > > > On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > > I think you are in violent agreement. The current LOADng draft is (IIRC) > aimed at LLNs, so Teco is saying unless there's a new MANET-oriented > version it shouldn't be discussed, and you are saying it won't be discuss= ed. > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > -----Original Message----- > > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > > Sent: 12 October 2012 15:12 > > To: Teco Boot > > Cc: Dearlove, Christopher (UK); List; Bo Berry (boberry= ) > > Subject: Re: [manet] MANET meeting at IETF85 > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: > > > On July 31th, our chair provided guidance on handling LOADng. > > It shows the way forward. > > > I'm looking forward to an draft-author-manet-loadng-00 draft, > submitted before next Monday. > > If there is no such draft, and little time to discuss non-wg drafts, we > should not discuss an lln draft in our meeting in Atlanta. > > > One (not too) fine point - we (the MANET WG) will *not* be discussing > an LLN draft. At any time. That would be a charter violation - LLN's are > defined and worked in ROLL. We are discussing MANET reactive protocols. > > > Stan > > > > I'm OK on discussions on how to fulfill our charter item on a reactive > protocol. > > > Teco > > > > Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het > volgende geschreven: > > > We have often discussed things not yet accepted by the WG, it can be a > step towards getting them accepted. > > > That's not a comment for or against LOADng, discussing LOADng, or > adopting LOADng, just an observation on what has happened in the past. > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Bo Berry > > Sent: 12 October 2012 13:40 > > To: Abdussalam Baryun; List; Bo Berry > > Subject: Re: [manet] MANET meeting at IETF85 > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > Looking at the MANET WG Documents page, LOADng is not on the list. So > until LOADng is accepted by the WG, gotta agree with Abdussalam, no need = to > discuss it in the little time we have for the work we've already accepted= . > > > How does this fit into the WG Charter? > > > -Bo > > > > Active Internet-Drafts > > draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) > > draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the > Neighborhood Discovery Protocol > > draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and > Timestamps For Router Admittance in NHDP > > draft-ietf-manet-olsrv2-16 The Optimized Link State Routing > Protocol version 2 > > draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the > Mobile Ad Hoc Network (MANET) Routing > > draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for > the Optimized Link State Routing Protocol > > > > > On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: > > > I've seen a number of emails on the alias but not sure LOADng > > has been accepted by the WG. Is LOADng asking to be a MANET WG > > draft? > > > -Bo > > > > On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: > > > Please note that I strongly object any including of LOADng draft in > the Agenda. > > The document is not for MANET, was already presented before, and the > > authors are not discussing on ietf lists of any progress. The draft > is > > not reasonable for the WG, if it is not discussed on the MANET list. > > > I got no reasonable reply to all my efforts, the last as: > > http://www.ietf.org/mail-archive/web/manet/current/msg13448.html > > > AB > > On 10/9/12, Ulrich Herberg wrote: > > Hi, > > > the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in > Salon A. > > If you intend to present something, please send a request to the > chairs. > > > Best regards > > Ulrich > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > --- > > We cannot solve our problems with the same thinking we used when we > created them. > > Albert Einstein > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > --- > > We cannot solve our problems with the same thinking we used when we > created them. > > Albert Einstein > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > C=E9dric CHAUVENET**** > > *Ph.D Student* > > c.chauvenet@watteco.com**** > *Direct Line : *+33(0)4 98 01 35 81**** > *Mobile : *+33(0)6 30 21 14 91** > > *Standard :* +33(0)4 98 01 60 05**** > *Fax :* +33(0)4 94 14 10 80**** > ** ** > 1766 Chemin de la Planquette**** > 83130 LA GARDE =96 France**** > www.watteco.com > > > * Before printing think about environment and costs***** > *This Message may contain confidential information intended only for > the use of the addressee named above. If you are not the intended recipie= nt > of this message you are hereby notified that any use, dissemination, > distribution or reproduction of this message is prohibited. If you receiv= ed > this message by mistake, please notify the sender by reply email > immediately. Please conduct your own virus checks before opening any > attachment as Watteco does not guarantee the integrity of this email or > attached files has been maintained nor this communication is free of > viruses, interceptions or interference. Any views expressed in this messa= ge > are those of the individual sender and may not necessarily reflect the > views of Watteco. Watteco shall not be responsible nor liable for the > improper and incomplete transmission of the information contained in this > communication nor for any delay in its receipt or damage to your system.* > * > * > > --bcaec50162b54515cd04cbf285f5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi C=E9dric,

On Sat, Oct 13, 2012 at 7:03= AM, C Chauvenet <c.chauvenet@watteco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi all,=A0

I agree with Teco that the message from the chair (http://www.ietf.org/mail-archive/web/manet/current/msg13305.html) is a= good move.=A0
In particular that "the LLN needs to be deemphasized as the primary purpose if adopted as manet&qu= ot;.


I ag= ree.

=A0


However=A0http://tools.ietf.org/html/draft-clausen-lln-loadn= g-05=A0says in its introduction that :

The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next
   Generation (LOADng) is a routing protocol, derived from AODV
   [RFC3561] and extended for use in Low power and Lossy Networks
   (LLNs).


The introduction will be largely changed in the next revision.
=
=A0


That is n= ot true. There are many improvements from what we learned from AODV, and wh= ich has been integrated when designing the protocol (see below)
=A0
<=
br>
F=
rom what I understand, the LOADng purpose should be a new version of AODV a=
ddressing some of the points suggested by the MANET chair such as "i=
mprovements in heterogeneity support, simplification where sensible, improv=
ed control plane flooding, better IPv6 support, and a eventually clear bord=
er gateway specification". =A0


That is e= xactly what LOADng does (and that will be clearer in the next revision). It= allows for improved flooding (e.g. using SMF/MPR flooding), it has improve= d IPv6 support, it is more flexible through the use of RFC5444, it is simpl= ified as several items from AODV (such as iRREP, precursor list) have been = removed, it is easier to secure using the security architecture based on RF= C5444/RFC6622 and by avoiding iRREPs. We still need to work in the clearer = border gateway specification.

=A0
<=
br>
<=
pre style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text=
-align:start;font-style:normal;margin-bottom:0px;font-weight:normal;line-he=
ight:normal;text-transform:none;font-size:1em;margin-top:0px;word-spacing:0=
px">
I=
n short :=A0LLNs=A0constraints and challenges should not be adr=
essed by LOADng, but LOADng could improve the AODV original specification f=
or MANET networks.


<= div>As one (out of many) use cases are LLNs, experience from these deployme= nts should be integrated. But since the reactive MANET protocol is a MANET = protocol, there will be many other use cases which we also address in the d= raft. We have learned from the experience with AODV (and there is plenty, j= ust Google Scholar for AODV), and I think that many of those learnings are = integrated already in LOADng.

Best regards
Ulrich

=
=A0

Is my understanding correct ?
<=
br>
B=
est,
<=
br>
C=
=E9dric.

Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit :

I assume the authors take the guidance from our chair, posted in:
http://www.ietf.org/mail-archive/web/manet/current/msg1= 3305.html

If so, I do not see a reason not to discuss LOADng.
And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings.=

Teco

Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven:

Hi,

(speaking on my own, not to representing the LOAD= ng authors).

As was pointed out before, we often have discusse= d items that were not WG documents, usually at the end of the meeting, to m= ake sure that there is enough time for WG items. I also agree with what Sta= n said: MANET should not be standardizing documents that are mainly focused on LLNs; however, a document that is foc= used on MANETS, and as a matter of fact is also used in LLN deployments sho= uld be acceptable, in my opinion.

We are currently finalizing some internal discuss= ions between the authors of LOADng, and I think that there will be an email= to the list on that regards in the next few days. Abdussalam, being agains= t presentation of something that has not even been proposed yet is premature and pointless, in my opinion.

Best regards
Ulrich

On Oct 12, 2012, at 7:15, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:

I think you are in violent agreement. The current= LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless there's= a new MANET-oriented version it shouldn't be discussed, and you are sa= ying it won't be discussed.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 | =A0Fax: +4= 4 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berr= y (boberry)
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' lin= k on IT matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:

On July 31th, our chair provided guidance on hand= ling LOADng.
It shows the way forward.

I'm looking forward to an draft-author-manet-= loadng-00 draft, submitted before next Monday.
If there is no such draft, and little time to dis= cuss non-wg drafts, we should not discuss an lln draft in our meeting in At= lanta.

One (not too) fine point - we (the MANET WG) will= *not* be discussing an LLN draft. At any time. That would be a charter vio= lation - LLN's are defined and worked in ROLL. We are discussing MANET = reactive protocols.

Stan


I'm OK on discussions on how to fulfill our c= harter item on a reactive protocol.

Teco


Op 12 okt. 2012, om 15:19 heeft Dearlove, Christo= pher (UK) het volgende geschreven:

We have often discussed things not yet accepted b= y the WG, it can be a step towards getting them accepted.

That's not a comment for or against LOADng, d= iscussing LOADng, or adopting LOADng, just an observation on what has happe= ned in the past.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 | =A0Fax: +4= 4 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Bo Berry
Sent: 12 October 2012 13:40
To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' lin= k on IT matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

Looking at the MANET WG Documents page, LOADng is= not on the list. So until LOADng is accepted by the WG, gotta agree with A= bdussalam, no need to discuss it in the little time we have for the work we= 've already accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03 =A0=A0=A0Dynamic Link Ex= change Protocol (DLEP) =A0=A0=A0
draft-ietf-manet-nhdp-mib-19 =A0=A0=A0Definition = of Managed Objects for the Neighborhood Discovery Protocol =A0=A0=A0
draft-ietf-manet-nhdp-sec-02 =A0=A0=A0Using Integ= rity Check Values and Timestamps For Router Admittance in NHDP =A0=A0=A0
draft-ietf-manet-olsrv2-16 =A0=A0=A0The Optimized= Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-metrics-rationale-01 =A0= =A0=A0Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
draft-ietf-manet-olsrv2-mib-04 =A0=A0=A0Definitio= n of Managed Objects for the Optimized Link State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:

I've seen a number of emails on the alias but= not sure LOADng
has been accepted by the WG. =A0Is LOADng asking = to be a MANET WG
draft?

-Bo


On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wr= ote:

Please note that I strongly object any including = of LOADng draft in the Agenda.
The document is not for MANET, was already presen= ted before, and the
authors are not discussing on ietf lists of any p= rogress. The draft is
not reasonable for the WG, if it is not discussed= on the MANET list.

I got no reasonable reply to all my efforts, the = last as:
http://www.ietf.org/mail-arch= ive/web/manet/current/msg13448.html

AB
On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

the MANET WG will meet on Wednesday, Nov. 7 from = 1pm to 2.30pm in Salon A.
If you intend to present something, please send a= request to the chairs.

Best regards
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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


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

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

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


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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



C=E9dric = CHAUVENET

Ph.D Student

c.chauvenet@watteco.com<= u>

Direct= Line=A0:=A0=A0=A0+33(0)4 98 01 35 81
Mobile=A0:=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0+33(0)6 30 21 14 91=

Standard := =A0=A0 += 33(0)4 98 01 60 05

Fax :=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0+33(0)4 94 14 10 80
=A0=
1766 Chemin de la Planqu= ette
83130 LA GARDE =96 Franc= e


=A0Befo= re printing think about=A0environment=A0and=A0costs
This = Message may contain confidential information intended only for the use of t= he addressee named above. If you are not the intended recipient of this mes= sage you are hereby notified that any use, dissemination, distribution or reproduction of this message = is prohibited. If you received this message by mistake, please notify the s= ender by reply email immediately. Please conduct your own virus checks befo= re opening any attachment as Watteco does not guarantee the integrity of this email or attached files has been = maintained nor this communication is free of viruses, interceptions or inte= rference. Any views expressed in this message are those of the individual s= ender and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for the = improper and incomplete transmission of the information contained in this c= ommunication nor for any delay in its receipt or damage to your system.
=


--bcaec50162b54515cd04cbf285f5-- --bcaec50162b54515d404cbf285f6 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: e5bc893de95666f8_0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAB2AJUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0H7NB /wA8I/8AvgUfZoP+eEf/AHwKmxRivH5pdxkP2aD/AJ4R/wDfAo+zQf8APCP/AL4FTYoxRzS7gQ/Z oP8AnhH/AN8Cj7NB/wA8I/8AvgVNRijml3Ah+zQf88I/++BR9mg/54R/98CpqMUc0u4EP2aD/nhH /wB8Cj7NB/zwj/74FTYoxRzS7gQ/ZoP+eEf/AHwKPs0H/PCP/vgVNijFHNLuBb06xtXgYvawsd3U xg1b/s+y/wCfOD/v2P8ACk09dtqPck1Z7V6lK/IhGUbO13n/AEaHr/zzFOFna/8APtF/3wKk6kmn DrWl2AwWlt/z7Rf98CnC0tv+feL/AL4FSCnCi4DBa2//ADwi/wC+BRUoop3AyMUYp2KMV41gG4qK 5uYLOEy3EgRM4Hck+gHc1JLKsKgtkljtVVGWY+gFc1fC7GqSjUECToAUQNuVEPTafXg5PqK3o0HU fkBam1u5kYi3gSBOzTfMx/4COB+dQ/2lqGci8H08lcVTMg+Y4YqjBWcKSqsegJ6A1d0rTW1fUvsx Z44Il3zshwefuqD2zyfoK9NYejFbFFuy1ljMLe+VFZhlJY87T/vD+H69K1sUkllZaDpU0KFp7i6B Rd+C8pPAH0A/xpY0KRIhOSqhSfXArzcRTjGXukhijFOxRiuewDcUYp2KfDH5kyL6nmmo3dgNW3TZ Ai+gpZDtjY+1PqG4OI8epr1krKwFYU4UgpwFMBwFKKBSigBaKWigDLxRinYoIODjg44PpXlWATSo Rc3ct8wysZMMHtj7zfiePoKyfGUMi6hYSwrmS4VrdfduCv8AWnXEmo/2MlrHE9otqN8kgcZl2nOF x2Pcn6V0j29vei3nkjDmJhLET/CcdfyNelSaStHoBVh0S2h0I6So/dtGVdj1Zj1Y++eaqaFZyaJo c9xeqFuDulmwc8AYHP0Gfxq+2qwJqw01lcOUDB8fISc/Ln1wCah11/MtY7FfvXThW9kHLH8uPxqn KyYFCygJjS7nLSXUqAySOckZ52j0A9BVrFOx7UYrzHdu7AbijFOxRilYBuKuWEXLSH6CqwUswUDk 1qRII41QdhW9CF5XAfVWdt0mPSrDNtUn0qr1OT3ruAQU8CkFOxQACnUgp2KACilooAzsUYp+KMV5 1gI2QOjIwyrAg/Q07SrtYdGP2mQD7EGjlJ7be/5YNU7nVrS0uTbyl/MxuwFzx1/ln8jWfLqOlXEq ymSYLMQGQDCylem4d8ZH6VrTlyMCWaWNdLkvb9HT7XJ5jFThov7nPqAB+NVrfXYWkhuLiSSaWdlg VmUJs4BPH1IBPrV+61XTWeWzuFMhTl0ZeDggj+lUxf6MQ3+hgI4OCFHzZO48dsnmpu2BbXVZGRG+ xN89x5GPNHDZxn6cUkGsC4CCK1dnkdkRC2M7epJ7UiXmmt5arGdpfzF6dScbuvqahkbR4w0Zt22B 2bIY8EfeI5yOvbrUWAtw6pHNPHH5TKsrvGjkj5mX7wx26H8qvYrPsP7PnuzJBbFJSCd7Dr0zjnvk Vrww+Y3+yOppqLbsBJaQ/wDLQj6VaoAwMDgUjttXNdsI8qsBFM2TtH41GBS9Tk0uKsBMU4CgUooA BThSYpRQAtFFFAFLFGKdijFcVgI2ijY5ZFJ6ZI5pv2eHAHlR8f7IqbFGKLAQm2gbIMMZzwcqOab9 jtsY+zxY/wBwVYxRiiwEH2W33bvIj3ZznYM59aX7Lb5z5Eecg52DrU2KkjhL8ngU1G+wEUNspf5E VfUgVeRQigDoKFUKMAYFLXRCCiAE4GTUDMXOe3anO2447U3FaAGKMUuKXFACYpRRS0AFLRS0AFFF FAFbFGKdijFc1gG4oxTgPanCJj2xT5QI8UoUscAZqYQjvzUgAA4GKpU+4ESQActz7VLS00sBWqSQ Ck4HNRsxbjtQSTRimAmKMUuKXFACYoxS4ooAKMUtFAAKWkpaACilooAb5a+lLtUdhS0ZFKyAKWky KTd7UwHUhIFNyTRigALE9KTFLijFACYoxS0UAJilxS4oxQAlFLRQAlLRRQAUUtFABRRRQAlFFFAB RRRQAUUUUAFFFFABRRRQAYoxRRQAtFFFABRRRQAUUUUAFFFFAH//2Q== --bcaec50162b54515d404cbf285f6 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: e5bc893de95666f8_0.2 R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== --bcaec50162b54515d404cbf285f6-- From ulrich@herberg.name Sat Oct 13 08:37:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC7821F8546 for ; Sat, 13 Oct 2012 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWKOvVGZmavx for ; Sat, 13 Oct 2012 08:37:41 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0032A21F8533 for ; Sat, 13 Oct 2012 08:37:40 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4943760vcb.31 for ; Sat, 13 Oct 2012 08:37:40 -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=lkxs0QSdKvWhbrVQJ4/oAgqjuvGsK7gf4tcwayGaL7w=; b=lWRxt6iawgrF6vbbcG3YWnzsujq2JlanDbbbGONAzUIuIs2tj21tF3pKQPxmzPE2rx 2TPBTduBPzRjxgzh4U0oC6ABukut7WWBpnQ6UF9DEvaYGi9ElguDHwIFlB7iuqbkgBBX Lo3rxJuwXi8ugSz+rvaLNrByROZPhT6HHxiFk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lkxs0QSdKvWhbrVQJ4/oAgqjuvGsK7gf4tcwayGaL7w=; b=fssiC6ufsRu5DcYFmYcWO+dG/ImVo19COu3t0SpIeI73YT0FAuIaXgQjijdymQUKLS Y5TRkgyPGEgz3kGC68nN2EBpK0TUGKh7nmihjbn8d64s+TOXJ+6HNCTv0M4OL9aeU2kc AQt6Ins1kJuiH13pooSUJne9z/HNkwpQWjRByRMs9wbtCzZNdyPGtrep1+K9Tj0ydbuf o1sC3u7rX1dDQwDrc4QQE5PXG6oKeEIP6SMzORDZCx43yaEySILxiJjfLKUfxiyChS1+ 7Toar2HytefyW9zxgGVS557/DJxeYTl5f7mM1dKsSKz0B7C1x4PlardySlq8nEGoUE0i /VBQ== MIME-Version: 1.0 Received: by 10.52.66.10 with SMTP id b10mr3419786vdt.71.1350142660320; Sat, 13 Oct 2012 08:37:40 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Sat, 13 Oct 2012 08:37:40 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Oct 2012 08:37:40 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf3071cf1eaa1e5704cbf29541 X-Gm-Message-State: ALoCoQmuA6ufHqh5qxIo/Gxo2BQFE0mD7FXy3QmXr90a7TPCCilqsga5T/iuXJazetUHw6J0MAYZ Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:37:42 -0000 --20cf3071cf1eaa1e5704cbf29541 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this draft is indeed interesting, and I wonder if there is any work planned to continue it. It seems to be a bit of a mixture between specifying how to use ETX in OLSRv2, and a deployment experience of ETX with OLSR in the FunkFeuer network. Is that the right way to go forward, or should that not better be separated in two drafts? Ulrich On Sat, Oct 13, 2012 at 5:41 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > I think some people in WG are interested also in Funkfeuer routing > metric [1], it was mentioned in MANET meeting 84. I hope we will see > the draft [2] to be accepted as a MANET WG draft shortly for > informational about Funkfeuer. > > AB>suggest for title> > Packet Sequence Number based ETX Metric for Funkfeuer Networking. > > AB> suggest the Abstract> > This document specifies the ETX metric and its usage in Funkfeuer's > OLSRv2 Routers. > > I recommend to include this draft [2] or a renewal in the Agenda 85, > if the authors are welling to present it. > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg12077.html > [2] http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 > > AB > ++ > On 10/12/12, Henning Rogge wrote: > > On 10/12/2012 09:53 AM, Abdussalam Baryun wrote: > >> +1 > >> > >> It is an excellent draft/work, I support the draft and your process. > >> Thanks to all: authors, you and the WG, > > > > The document will be a great help as a pointer for people who still > > arguing the use of link metrics. Good to see it here. > > > > Henning Rogge > > > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf3071cf1eaa1e5704cbf29541 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this draft is indeed interesting, and I wonder if there is any work= planned to continue it. It seems to be a bit of a mixture between specifyi= ng how to use ETX in OLSRv2, and a deployment experience of ETX with OLSR i= n the FunkFeuer network. Is that the right way to go forward, or should tha= t not better be separated in two drafts?

Ulrich

On Sat, Oct 13, 201= 2 at 5:41 AM, Abdussalam Baryun <abdussalambaryun@gmail.com&g= t; wrote:
I think some people in WG are interested als= o in Funkfeuer routing
metric [1], it was mentioned in MANET meeting 84. I hope we will see
the draft [2] to be accepted as a MANET WG draft shortly for
informational about Funkfeuer.

AB>suggest for title>
Packet Sequence Number based ETX Metric for Funkfeuer =A0Networking.

AB> suggest the Abstract>
This document specifies the ETX metric and its usage in Funkfeuer's
OLSRv2 Routers.

I recommend to include this draft [2] or a renewal in the Agenda 85,
if the authors are welling to present it.

[1] http://www.ietf.org/mail-archive/web/manet/current/= msg12077.html
[2] http://tools.ietf.org/html/draft-funkfeuer-manet-olsr= v2-etx-01

AB
++
On 10/12/12, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
> On 10/12/2012 09:53 AM, Abdussalam Baryun wrote:
>> +1
>>
>> It is an excellent draft/work, I support the draft and your proces= s.
>> Thanks to all: authors, you and the WG,
>
> The document will be a great help as a pointer for people who still > arguing the use of link metrics. Good to see it here.
>
> Henning Rogge
>
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
> mailto:henning.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf3071cf1eaa1e5704cbf29541-- From jvasseur@cisco.com Sat Oct 13 08:44:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394F721F8549 for ; Sat, 13 Oct 2012 08:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ITGbGuBHVzu for ; Sat, 13 Oct 2012 08:44:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ECD0821F8543 for ; Sat, 13 Oct 2012 08:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28963; q=dns/txt; s=iport; t=1350143084; x=1351352684; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4kHNrYCfH2DzIvCSADihtNZUDj9AVpUvw8ZUj5+TvGw=; b=HF09dw+zCHRag4JIW06EZikNqNr8uqhjZsU7YqqC6QocSkk/nhjdljIS n+Vdd93wnwrKKk4FhBupT+KmUHmS+5F3E/UMcfzBiGkvQjATiH+eB91Eg HzbKY/Yc/XI3lsVuxXOT6dCKZlHDe2XrUUOlZV/U2RLR6O3KwG05H1SKl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAImLeVCtJV2Y/2dsb2JhbABFv2uBCIIgAQEBAwEBAQEPAQc7GQMIBQcEAgEIBwoEAQEBChYHBycLFAkIAgQOBQgBGYdcBgucIJ9Ri1kUBgiFO2ADpDGBa4JtgVoJNA X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208,217";a="131269331" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 13 Oct 2012 15:44:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9DFigor014817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 15:44:42 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 10:44:42 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqVmoxQdayxYbx0aw5eRdXfbe8w== Date: Sat, 13 Oct 2012 15:44:41 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--51.450300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FD5949xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:44:46 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FD5949xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 13, 2012, at 5:26 PM, Ulrich Herberg wrote: Hi JP, On Sat, Oct 13, 2012 at 2:21 AM, JP Vasseur (jvasseur) > wrote: Hi Ulrich, On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote: > Hi, > > (speaking on my own, not to representing the LOADng authors). > > As was pointed out before, we often have discussed items that were not WG= documents, usually at the end of the meeting, to make sure that there is e= nough time for WG items. I also agree with what Stan said: MANET should not= be standardizing documents that are mainly focused on LLNs; Just to make sure that we do not play with words =85. As agreed between the= chairs, it should read "MANET is standardizing documents that are not deal= ing with LLNs/IoT". This is much stronger that "mainly on LLNs" I think (as MANET participant, not LOADng author) that the reactive protoco= l in the MANET WG should be a *MANET protocol*. I also think that a Standar= ds Track document can (or maybe should) mention where it is used in deploym= ents and implementations. JP> I would not disagree. As a matter of fact, LOADng is used in LLN deployments, and I think this is= important to mention. This is just one use case of LOADng, not the only on= e. JP> This is where we have a major disagreement; the fact that this protocol= is used for some LLNs does mean that it is the right thing to do for the I= ETF. This is why the IETF has formed a WG to deal with LLNs, and the WG worked f= or years to reach the conclusion that a pro-active protocol should be chose= n. As Adrian said at the last IETF "some if not all LLNs are MANET, but not al= l MANETs are LLNs"; as such, I think it is fair to mention use cases of LOA= Dng and deployments (and clearly there should be many more use cases that t= hose) I think this would be fully in charter of MANET, and would not coincide wit= h any other WG. JP> Working chair-hat on, if we have two WGs going in opposite directions f= or LLNs, we clearly have an overlap - this is what the chairs of ROLL and M= ANET want to avoid. Regards. JP. Regards Ulrich Thanks. JP. > however, a document that is focused on MANETS, and as a matter of fact is= also used in LLN deployments should be acceptable, in my opinion. > > We are currently finalizing some internal discussions between the authors= of LOADng, and I think that there will be an email to the list on that reg= ards in the next few days. Abdussalam, being against presentation of someth= ing that has not even been proposed yet is premature and pointless, in my o= pinion. > > Best regards > Ulrich > > On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" > wrote: > >> I think you are in violent agreement. The current LOADng draft is (IIRC)= aimed at LLNs, so Teco is saying unless there's a new MANET-oriented versi= on it shouldn't be discussed, and you are saying it won't be discussed. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124<= tel:%2B44%201245%20242124> >> chris.dearlove@baesystems.com | ht= tp://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >> Sent: 12 October 2012 15:12 >> To: Teco Boot >> Cc: Dearlove, Christopher (UK); > = List; Bo Berry (boberry) >> Subject: Re: [manet] MANET meeting at IETF85 >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >> >>> On July 31th, our chair provided guidance on handling LOADng. >>> It shows the way forward. >>> >>> I'm looking forward to an draft-author-manet-loadng-00 draft, submitted= before next Monday. >>> If there is no such draft, and little time to discuss non-wg drafts, we= should not discuss an lln draft in our meeting in Atlanta. >> >> One (not too) fine point - we (the MANET WG) will *not* be discussing an= LLN draft. At any time. That would be a charter violation - LLN's are defi= ned and worked in ROLL. We are discussing MANET reactive protocols. >> >> Stan >> >> >>> I'm OK on discussions on how to fulfill our charter item on a reactive = protocol. >>> >>> Teco >>> >>> >>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende= geschreven: >>> >>>> We have often discussed things not yet accepted by the WG, it can be a= step towards getting them accepted. >>>> >>>> That's not a comment for or against LOADng, discussing LOADng, or adop= ting LOADng, just an observation on what has happened in the past. >>>> >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | = http://www.baesystems.com >>>> >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>> >>>> >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:ma= net-bounces@ietf.org] On Behalf Of Bo Berry >>>> Sent: 12 October 2012 13:40 >>>> To: Abdussalam Baryun; > List; B= o Berry >>>> Subject: Re: [manet] MANET meeting at IETF85 >>>> >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>> >>>> Looking at the MANET WG Documents page, LOADng is not on the list. So = until LOADng is accepted by the WG, gotta agree with Abdussalam, no need to= discuss it in the little time we have for the work we've already accepted. >>>> >>>> How does this fit into the WG Charter? >>>> >>>> -Bo >>>> >>>> >>>> Active Internet-Drafts >>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) >>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the = Neighborhood Discovery Protocol >>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Times= tamps For Router Admittance in NHDP >>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protoco= l version 2 >>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the M= obile Ad Hoc Network (MANET) Routing >>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for th= e Optimized Link State Routing Protocol >>>> >>>> >>>> >>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>> >>>>> I've seen a number of emails on the alias but not sure LOADng >>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>>> draft? >>>>> >>>>> -Bo >>>>> >>>>> >>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>> >>>>>> Please note that I strongly object any including of LOADng draft in = the Agenda. >>>>>> The document is not for MANET, was already presented before, and the >>>>>> authors are not discussing on ietf lists of any progress. The draft = is >>>>>> not reasonable for the WG, if it is not discussed on the MANET list. >>>>>> >>>>>> I got no reasonable reply to all my efforts, the last as: >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>> >>>>>> AB >>>>>> On 10/9/12, Ulrich Herberg > wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in S= alon A. >>>>>>> If you intend to present something, please send a request to the ch= airs. >>>>>>> >>>>>>> Best regards >>>>>>> Ulrich >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when we c= reated them. >>>>> Albert Einstein >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> --- >>>> We cannot solve our problems with the same thinking we used when we cr= eated them. >>>> Albert Einstein >>>> >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>>> ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> ******************************************************************** >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FD5949xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 13, 2012, at 5:26 PM, Ulrich Herberg wrote:

Hi JP,

On Sat, Oct 13, 2012 at 2:21 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
Hi Ulrich,

On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote:

> Hi,
>
> (speaking on my own, not to representing the LOADng authors).
>
> As was pointed out before, we often have discussed items that were not= WG documents, usually at the end of the meeting, to make sure that there i= s enough time for WG items. I also agree with what Stan said: MANET should = not be standardizing documents that are mainly focused on LLNs;

Just to make sure that we do not play with words =85. As agreed between the= chairs, it should read "MANET is standardizing documents that are not= dealing with LLNs/IoT".
This is much stronger that "mainly on LLNs"


I think (as MANET participant, not LOADng author) that the reactive pr= otocol in the MANET WG should be a *MANET protocol*. I also think that a St= andards Track document can (or maybe should) mention where it is used in de= ployments and implementations.

JP> I would not disagree.

As a matter of fact, LOADng is used in LLN deployments, and I think th= is is important to mention. This is just one use case of LOADng, not the on= ly one.

JP> This is where we have a major disagreement; the fact tha= t this protocol is used for some LLNs does mean that it is the right thing = to do for the IETF.
This is why the IETF has formed a WG to deal with LLNs, and the WG wor= ked for years to reach the conclusion that a pro-active protocol shoul= d be chosen.

As Adrian said at the last IETF "some if not all LLNs are MANET, but not all MANETs are LLNs&quo= t;; as such, I think it is fair to mention use cases of LOADng and deployme= nts (and clearly there should be many more use cases that those)
I think this would be fully in charter of MANET, and would not coincid= e with any other WG.

JP> Working chair-hat on, if we have two WGs going in opposite dire= ctions for LLNs, we clearly have an overlap - this is what the chairs of RO= LL and MANET 
want to avoid.

Regards.

JP.


Regards
Ulrich

 

Thanks.

JP.

> however, a document that is focused on MANETS, and as a matter of fact= is also used in LLN deployments should be acceptable, in my opinion.
>
> We are currently finalizing some internal discussions between the auth= ors of LOADng, and I think that there will be an email to the list on that = regards in the next few days. Abdussalam, being against presentation of som= ething that has not even been proposed yet is premature and pointless, in my opinion.
>
> Best regards
> Ulrich
>
> On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" <<= a href=3D"mailto:Chris.Dearlove@baesystems.com">Chris.Dearlove@baesystems.c= om> wrote:
>
>> I think you are in violent agreement. The current LOADng draft is = (IIRC) aimed at LLNs, so Teco is saying unless there's a new MANET-oriented= version it shouldn't be discussed, and you are saying it won't be discusse= d.
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1= 245 242124
>> chris.dearlove@ba= esystems.com | http://www.baesyst= ems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
>> Sent: 12 October 2012 15:12
>> To: Teco Boot
>> Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berry (boberry)
>> Subject: Re: [manet] MANET meeting at IETF85
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:
>>
>>> On July 31th, our chair provided guidance on handling LOADng.<= br> >>> It shows the way forward.
>>>
>>> I'm looking forward to an draft-author-manet-loadng-00 draft, = submitted before next Monday.
>>> If there is no such draft, and little time to discuss non-wg d= rafts, we should not discuss an lln draft in our meeting in Atlanta.
>>
>> One (not too) fine point - we (the MANET WG) will *not* be discuss= ing an LLN draft. At any time. That would be a charter violation - LLN's ar= e defined and worked in ROLL. We are discussing MANET reactive protocols. >>
>> Stan
>>
>>
>>> I'm OK on discussions on how to fulfill our charter item on a = reactive protocol.
>>>
>>> Teco
>>>
>>>
>>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het= volgende geschreven:
>>>
>>>> We have often discussed things not yet accepted by the WG,= it can be a step towards getting them accepted.
>>>>
>>>> That's not a comment for or against LOADng, discussing LOA= Dng, or adopting LOADng, just an observation on what has happened in the pa= st.
>>>>
>>>> --
>>>> Christopher Dearlove
>>>> Senior Principal Engineer, Communications Group
>>>> Communications, Networks and Image Analysis Capability
>>>> BAE Systems Advanced Technology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,= UK
>>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124<= br> >>>> chris.dea= rlove@baesystems.com | http://www.baesyst= ems.com
>>>>
>>>> BAE Systems (Operations) Limited
>>>> Registered Office: Warwick House, PO Box 87, Farnborough A= erospace Centre, Farnborough, Hants, GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: manet-boun= ces@ietf.org [mailto:manet-bo= unces@ietf.org] On Behalf Of Bo Berry
>>>> Sent: 12 October 2012 13:40
>>>> To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
>>>> Subject: Re: [manet] MANET meeting at IETF85
>>>>
>>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation,
>>>> either from an external partner or from the internet.
>>>> Keep this in mind if you answer this message.
>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>
>>>> Looking at the MANET WG Documents page, LOADng is not on t= he list. So until LOADng is accepted by the WG, gotta agree with Abdussalam= , no need to discuss it in the little time we have for the work we've alrea= dy accepted.
>>>>
>>>> How does this fit into the WG Charter?
>>>>
>>>> -Bo
>>>>
>>>>
>>>> Active Internet-Drafts
>>>> draft-ietf-manet-dlep-03    Dynamic Link Exchang= e Protocol (DLEP)
>>>> draft-ietf-manet-nhdp-mib-19    Definition of Ma= naged Objects for the Neighborhood Discovery Protocol
>>>> draft-ietf-manet-nhdp-sec-02    Using Integrity = Check Values and Timestamps For Router Admittance in NHDP
>>>> draft-ietf-manet-olsrv2-16    The Optimized Link= State Routing Protocol version 2
>>>> draft-ietf-manet-olsrv2-metrics-rationale-01    = Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
>>>> draft-ietf-manet-olsrv2-mib-04    Definition of = Managed Objects for the Optimized Link State Routing Protocol
>>>>
>>>>
>>>>
>>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:
>>>>
>>>>> I've seen a number of emails on the alias but not sure= LOADng
>>>>> has been accepted by the WG.  Is LOADng asking to= be a MANET WG
>>>>> draft?
>>>>>
>>>>> -Bo
>>>>>
>>>>>
>>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote:<= br> >>>>>
>>>>>> Please note that I strongly object any including o= f LOADng draft in the Agenda.
>>>>>> The document is not for MANET, was already present= ed before, and the
>>>>>> authors are not discussing on ietf lists of any pr= ogress. The draft is
>>>>>> not reasonable for the WG, if it is not discussed = on the MANET list.
>>>>>>
>>>>>> I got no reasonable reply to all my efforts, the l= ast as:
>>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html
>>>>>>
>>>>>> AB
>>>>>> On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> the MANET WG will meet on Wednesday, Nov. 7 fr= om 1pm to 2.30pm in Salon A.
>>>>>>> If you intend to present something, please sen= d a request to the chairs.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Ulrich
>>>>>> _______________________________________________ >>>>>> manet mailing list
>>>>>> manet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>> ---
>>>>> We cannot solve our problems with the same thinking we= used when we created them.
>>>>> Albert Einstein
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>> ---
>>>> We cannot solve our problems with the same thinking we use= d when we created them.
>>>> Albert Einstein
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>> **********************************************************= **********
>>>> This email and any attachments are confidential to the int= ended
>>>> recipient and may also be privileged. If you are not the i= ntended
>>>> recipient please delete it from your system and notify the= sender.
>>>> You should not copy it or use it for any purpose nor discl= ose or
>>>> distribute its contents to any other person.
>>>> **********************************************************= **********
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A7721FD5949xmbrcdx02ciscoc_-- From ulrich@herberg.name Sat Oct 13 08:57:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2795921F859F for ; Sat, 13 Oct 2012 08:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeJf3uiv0T6M for ; Sat, 13 Oct 2012 08:57:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82AC821F859A for ; Sat, 13 Oct 2012 08:57:47 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3736655pbb.31 for ; Sat, 13 Oct 2012 08:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=5429GlKL/uCn6fuirfTs6yQDJdTAVk2EgMUe67/RBCU=; b=dHFp2pmZDGdiOq8+Az0yIDI6UNlQBjtztPyFPYAcQ2LH+p3JtlWD5Pw8gklZJSMwV8 /j4nMt5EOLLRuZQlAk5w0e2lbeLy85LmptYOEkHo/efMBrwYDo+lJT6bMliGfGgYmM0E AuG1N/v5YjyDE17EJWb9yyLrpUf/bF0FMwgNQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=5429GlKL/uCn6fuirfTs6yQDJdTAVk2EgMUe67/RBCU=; b=g35j3cDkdSiI6xEzDxvFsIkNlMQoV4FMuNtOigIXzdrnO4PTkOEhCigXHiIAtVptIA tdRDdDlRHEy98b5spNoLPCK0RcJs/7PpBBkBL2QrghoRYQH2L2vo+jmIA6yhfJxvwi3I GP6Dlm3uOJ+i+esfE5pahJUq8C5gUQ4hn0eD2MI0TYrKH8wvCPhZC0j8/+pdCBYwIc0Y IGeZSSJDRv7hv2ZGRMpkDcgXtg0bZzhD0MhIHQD7kf2eSlgWPIQrCutH8sgwmUsdyC9u 1lHlMw4dsaTN2AsFbg7ZmIzMFsw+oTugUd/PmbJG22coLSYsnUiWHI+DZXi5bCDh9NMs coeQ== Received: by 10.68.202.168 with SMTP id kj8mr23013456pbc.8.1350143867128; Sat, 13 Oct 2012 08:57:47 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id vz8sm6194011pbc.63.2012.10.13.08.57.45 (version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 08:57:46 -0700 (PDT) References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-0D5DB8C3-5D16-4AA0-BDF0-1C29679A8CD5 Content-Transfer-Encoding: 7bit Message-Id: <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Sat, 13 Oct 2012 08:57:44 -0700 To: "JP Vasseur (jvasseur)" X-Gm-Message-State: ALoCoQmMMJffdzwPAmrssAuyhEBnpHXQR4wFgAx78p0lk8jHuLjm+A/Mydke+/YY5lE0P+0WSZTy Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:57:49 -0000 --Apple-Mail-0D5DB8C3-5D16-4AA0-BDF0-1C29679A8CD5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi JP, On Oct 13, 2012, at 8:44, "JP Vasseur (jvasseur)" wrote= : > Hi Ulrich, >=20 > On Oct 13, 2012, at 5:26 PM, Ulrich Herberg wrote: >=20 >> Hi JP, >>=20 >> On Sat, Oct 13, 2012 at 2:21 AM, JP Vasseur (jvasseur) wrote: >>> Hi Ulrich, >>>=20 >>> On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote: >>>=20 >>> > Hi, >>> > >>> > (speaking on my own, not to representing the LOADng authors). >>> > >>> > As was pointed out before, we often have discussed items that were not= WG documents, usually at the end of the meeting, to make sure that there is= enough time for WG items. I also agree with what Stan said: MANET should no= t be standardizing documents that are mainly focused on LLNs; >>>=20 >>> Just to make sure that we do not play with words =E2=80=A6. As agreed be= tween the chairs, it should read "MANET is standardizing documents that are n= ot dealing with LLNs/IoT". >>> This is much stronger that "mainly on LLNs" >>=20 >>=20 >> I think (as MANET participant, not LOADng author) that the reactive proto= col in the MANET WG should be a *MANET protocol*. I also think that a Standa= rds Track document can (or maybe should) mention where it is used in deploym= ents and implementations. >=20 > JP> I would not disagree. >=20 >> As a matter of fact, LOADng is used in LLN deployments, and I think this i= s important to mention. This is just one use case of LOADng, not the only on= e. >=20 > JP> This is where we have a major disagreement; the fact that this protoco= l is used for some LLNs does mean that it is the right thing to do for the I= ETF. I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, if we= come up with a MANET reactive protocol, it is only logical that for some LL= Ns the reactive MANET protocol would be suitable as well; but clearly, MANET= should cover the general case of MANETs. > This is why the IETF has formed a WG to deal with LLNs, and the WG worked f= or years to reach the conclusion that a pro-active protocol should be chosen= . That is fine, and I don't see any problem with that. >=20 >> As Adrian said at the last IETF "some if not all LLNs are MANET, but not a= ll MANETs are LLNs"; as such, I think it is fair to mention use cases of LOA= Dng and deployments (and clearly there should be many more use cases that th= ose) >> I think this would be fully in charter of MANET, and would not coincide w= ith any other WG. >=20 > JP> Working chair-hat on, if we have two WGs going in opposite directions f= or LLNs, we clearly have an overlap - this is what the chairs of ROLL and MA= NET=20 > want to avoid. Right, and I don't see why there would be overlap. Regards Ulrich >=20 > Regards. >=20 > JP. >=20 >>=20 >> Regards >> Ulrich >>=20 >> =20 >>>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>> > however, a document that is focused on MANETS, and as a matter of fact= is also used in LLN deployments should be acceptable, in my opinion. >>> > >>> > We are currently finalizing some internal discussions between the auth= ors of LOADng, and I think that there will be an email to the list on that r= egards in the next few days. Abdussalam, being against presentation of somet= hing that has not even been proposed yet is premature and pointless, in my o= pinion. >>> > >>> > Best regards >>> > Ulrich >>> > >>> > On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" wrote: >>> > >>> >> I think you are in violent agreement. The current LOADng draft is (II= RC) aimed at LLNs, so Teco is saying unless there's a new MANET-oriented ver= sion it shouldn't be discussed, and you are saying it won't be discussed. >>> >> >>> >> -- >>> >> Christopher Dearlove >>> >> Senior Principal Engineer, Communications Group >>> >> Communications, Networks and Image Analysis Capability >>> >> BAE Systems Advanced Technology Centre >>> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> >> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >> >>> >> BAE Systems (Operations) Limited >>> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Ce= ntre, Farnborough, Hants, GU14 6YU, UK >>> >> Registered in England & Wales No: 1996687 >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >>> >> Sent: 12 October 2012 15:12 >>> >> To: Teco Boot >>> >> Cc: Dearlove, Christopher (UK); List; Bo Berry (bobe= rry) >>> >> Subject: Re: [manet] MANET meeting at IETF85 >>> >> >>> >> ----------------------! WARNING ! ---------------------- >>> >> This message originates from outside our organisation, >>> >> either from an external partner or from the internet. >>> >> Keep this in mind if you answer this message. >>> >> Follow the 'Report Suspicious Emails' link on IT matters >>> >> for instructions on reporting suspicious email messages. >>> >> -------------------------------------------------------- >>> >> >>> >> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >>> >> >>> >>> On July 31th, our chair provided guidance on handling LOADng. >>> >>> It shows the way forward. >>> >>> >>> >>> I'm looking forward to an draft-author-manet-loadng-00 draft, submit= ted before next Monday. >>> >>> If there is no such draft, and little time to discuss non-wg drafts,= we should not discuss an lln draft in our meeting in Atlanta. >>> >> >>> >> One (not too) fine point - we (the MANET WG) will *not* be discussing= an LLN draft. At any time. That would be a charter violation - LLN's are de= fined and worked in ROLL. We are discussing MANET reactive protocols. >>> >> >>> >> Stan >>> >> >>> >> >>> >>> I'm OK on discussions on how to fulfill our charter item on a reacti= ve protocol. >>> >>> >>> >>> Teco >>> >>> >>> >>> >>> >>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volge= nde geschreven: >>> >>> >>> >>>> We have often discussed things not yet accepted by the WG, it can b= e a step towards getting them accepted. >>> >>>> >>> >>>> That's not a comment for or against LOADng, discussing LOADng, or a= dopting LOADng, just an observation on what has happened in the past. >>> >>>> >>> >>>> -- >>> >>>> Christopher Dearlove >>> >>>> Senior Principal Engineer, Communications Group >>> >>>> Communications, Networks and Image Analysis Capability >>> >>>> BAE Systems Advanced Technology Centre >>> >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>>> >>> >>>> BAE Systems (Operations) Limited >>> >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace C= entre, Farnborough, Hants, GU14 6YU, UK >>> >>>> Registered in England & Wales No: 1996687 >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Beh= alf Of Bo Berry >>> >>>> Sent: 12 October 2012 13:40 >>> >>>> To: Abdussalam Baryun; List; Bo Berry >>> >>>> Subject: Re: [manet] MANET meeting at IETF85 >>> >>>> >>> >>>> ----------------------! WARNING ! ---------------------- >>> >>>> This message originates from outside our organisation, >>> >>>> either from an external partner or from the internet. >>> >>>> Keep this in mind if you answer this message. >>> >>>> Follow the 'Report Suspicious Emails' link on IT matters >>> >>>> for instructions on reporting suspicious email messages. >>> >>>> -------------------------------------------------------- >>> >>>> >>> >>>> Looking at the MANET WG Documents page, LOADng is not on the list. S= o until LOADng is accepted by the WG, gotta agree with Abdussalam, no need t= o discuss it in the little time we have for the work we've already accepted.= >>> >>>> >>> >>>> How does this fit into the WG Charter? >>> >>>> >>> >>>> -Bo >>> >>>> >>> >>>> >>> >>>> Active Internet-Drafts >>> >>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) >>> >>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for t= he Neighborhood Discovery Protocol >>> >>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Ti= mestamps For Router Admittance in NHDP >>> >>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Prot= ocol version 2 >>> >>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for th= e Mobile Ad Hoc Network (MANET) Routing >>> >>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for= the Optimized Link State Routing Protocol >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>> >>>> >>> >>>>> I've seen a number of emails on the alias but not sure LOADng >>> >>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>> >>>>> draft? >>> >>>>> >>> >>>>> -Bo >>> >>>>> >>> >>>>> >>> >>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>> >>>>> >>> >>>>>> Please note that I strongly object any including of LOADng draft i= n the Agenda. >>> >>>>>> The document is not for MANET, was already presented before, and t= he >>> >>>>>> authors are not discussing on ietf lists of any progress. The dra= ft is >>> >>>>>> not reasonable for the WG, if it is not discussed on the MANET li= st. >>> >>>>>> >>> >>>>>> I got no reasonable reply to all my efforts, the last as: >>> >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>> >>>>>> >>> >>>>>> AB >>> >>>>>> On 10/9/12, Ulrich Herberg wrote: >>> >>>>>>> Hi, >>> >>>>>>> >>> >>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm i= n Salon A. >>> >>>>>>> If you intend to present something, please send a request to the= chairs. >>> >>>>>>> >>> >>>>>>> Best regards >>> >>>>>>> Ulrich >>> >>>>>> _______________________________________________ >>> >>>>>> manet mailing list >>> >>>>>> manet@ietf.org >>> >>>>>> https://www.ietf.org/mailman/listinfo/manet >>> >>>>> >>> >>>>> --- >>> >>>>> We cannot solve our problems with the same thinking we used when w= e created them. >>> >>>>> Albert Einstein >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> manet mailing list >>> >>>>> manet@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/manet >>> >>>> >>> >>>> --- >>> >>>> We cannot solve our problems with the same thinking we used when we= created them. >>> >>>> Albert Einstein >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> manet mailing list >>> >>>> manet@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>>> >>> >>>> >>> >>>> *******************************************************************= * >>> >>>> This email and any attachments are confidential to the intended >>> >>>> recipient and may also be privileged. If you are not the intended >>> >>>> recipient please delete it from your system and notify the sender. >>> >>>> You should not copy it or use it for any purpose nor disclose or >>> >>>> distribute its contents to any other person. >>> >>>> *******************************************************************= * >>> >>>> >>> >>>> _______________________________________________ >>> >>>> manet mailing list >>> >>>> manet@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> _______________________________________________ >>> >>> manet mailing list >>> >>> manet@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >>> >> >>> >> _______________________________________________ >>> >> manet mailing list >>> >> manet@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/manet >>> > _______________________________________________ >>> > manet mailing list >>> > manet@ietf.org >>> > https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 --Apple-Mail-0D5DB8C3-5D16-4AA0-BDF0-1C29679A8CD5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi JP,

On Oct 13, 2012, at 8:44= , "JP Vasseur (jvasseur)" <jvasseur= @cisco.com> wrote:

Hi Ulrich,

On Oct 13, 2012, at 5:26 PM, Ulrich Herberg wrote:

Hi JP,

On Sat, Oct 13, 2012 at 2:21 AM, JP Vasseur (jvas= seur) <jvasseur@cisco.c= om> wrote:
Hi Ulrich,

On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote:

> Hi,
>
> (speaking on my own, not to representing the LOADng authors).
>
> As was pointed out before, we often have discussed items that were not W= G documents, usually at the end of the meeting, to make sure that there is e= nough time for WG items. I also agree with what Stan said: MANET should not b= e standardizing documents that are mainly focused on LLNs;

Just to make sure that we do not play with words =E2=80=A6. As agreed betwee= n the chairs, it should read "MANET is standardizing documents that are not d= ealing with LLNs/IoT".
This is much stronger that "mainly on LLNs"


I think (as MANET participant, not LOADng author) that the reactive pro= tocol in the MANET WG should be a *MANET protocol*. I also think that a Stan= dards Track document can (or maybe should) mention where it is used in deplo= yments and implementations.

JP> I would not disagree.

As a matter of fact, LOADng is used in LLN deployments, and I think thi= s is important to mention. This is just one use case of LOADng, not the only= one.

JP> This is where we have a major disagreement; the fact that= this protocol is used for some LLNs does mean that it is the right thing to= do for the IETF.

I r= epeat what Adrian said: some if not all LLNs are MANETs. Therefore, if we co= me up with a MANET reactive protocol, it is only logical that for some LLNs t= he reactive MANET protocol would be suitable as well; but clearly, MANET sho= uld cover the general case of MANETs.


This is why the IETF has formed a WG to deal with LLNs, and the WG work= ed for years to reach the conclusion that a pro-active protocol should b= e chosen.

That is fi= ne, and I don't see any problem with that.


As Adrian said at the last IETF "s= ome if not all LLNs are MANET, but not all MANETs are LLNs"; as such,= I think it is fair to mention use cases of LOADng and deployments (and clea= rly there should be many more use cases that those)
I think this would be fully in charter of MANET, and would not coincide= with any other WG.

JP> Working chair-hat on, if we have two WGs going in opposite direc= tions for LLNs, we clearly have an overlap - this is what the chairs of ROLL= and MANET 
want to avoid.

= Right, and I don't see why there would be overlap.

= Regards
Ulrich




Regards.

JP.


Regards
Ulrich

 

Thanks.

JP.

> however, a document that is focused on MANETS, and as a matter of fact i= s also used in LLN deployments should be acceptable, in my opinion.
>
> We are currently finalizing some internal discussions between the autho= rs of LOADng, and I think that there will be an email to the list on that re= gards in the next few days. Abdussalam, being against presentation of someth= ing that has not even been proposed yet is premature and pointless, in my opinion.
>
> Best regards
> Ulrich
>
> On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> w= rote:
>
>> I think you are in violent agreement. The current LOADng draft is (= IIRC) aimed at LLNs, so Teco is saying unless there's a new MANET-oriented v= ersion it shouldn't be discussed, and you are saying it won't be discussed.<= br> >>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: = +44 1245 242194 |  Fax: +44 1245 24212= 4
>> chris.dearlove@bae= systems.com | http://www.baesyste= ms.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace C= entre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
>> Sent: 12 October 2012 15:12
>> To: Teco Boot
>> Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berry (boberry)
>> Subject: Re: [manet] MANET meeting at IETF85
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:
>>
>>> On July 31th, our chair provided guidance on handling LOADng. >>> It shows the way forward.
>>>
>>> I'm looking forward to an draft-author-manet-loadng-00 draft, s= ubmitted before next Monday.
>>> If there is no such draft, and little time to discuss non-wg dr= afts, we should not discuss an lln draft in our meeting in Atlanta.
>>
>> One (not too) fine point - we (the MANET WG) will *not* be discussi= ng an LLN draft. At any time. That would be a charter violation - LLN's are d= efined and worked in ROLL. We are discussing MANET reactive protocols.
>>
>> Stan
>>
>>
>>> I'm OK on discussions on how to fulfill our charter item on a r= eactive protocol.
>>>
>>> Teco
>>>
>>>
>>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het v= olgende geschreven:
>>>
>>>> We have often discussed things not yet accepted by the WG, i= t can be a step towards getting them accepted.
>>>>
>>>> That's not a comment for or against LOADng, discussing LOAD= ng, or adopting LOADng, just an observation on what has happened in the past= .
>>>>
>>>> --
>>>> Christopher Dearlove
>>>> Senior Principal Engineer, Communications Group
>>>> Communications, Networks and Image Analysis Capability
>>>> BAE Systems Advanced Technology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, U= K
>>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>>>> chris.dear= love@baesystems.com | http://www.baesyste= ms.com
>>>>
>>>> BAE Systems (Operations) Limited
>>>> Registered Office: Warwick House, PO Box 87, Farnborough Ae= rospace Centre, Farnborough, Hants, GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: manet-bounc= es@ietf.org [mailto:manet-boun= ces@ietf.org] On Behalf Of Bo Berry
>>>> Sent: 12 October 2012 13:40
>>>> To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
>>>> Subject: Re: [manet] MANET meeting at IETF85
>>>>
>>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation,
>>>> either from an external partner or from the internet.
>>>> Keep this in mind if you answer this message.
>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>
>>>> Looking at the MANET WG Documents page, LOADng is not on th= e list. So until LOADng is accepted by the WG, gotta agree with Abdussalam, n= o need to discuss it in the little time we have for the work we've already a= ccepted.
>>>>
>>>> How does this fit into the WG Charter?
>>>>
>>>> -Bo
>>>>
>>>>
>>>> Active Internet-Drafts
>>>> draft-ietf-manet-dlep-03    Dynamic Link Exchange= Protocol (DLEP)
>>>> draft-ietf-manet-nhdp-mib-19    Definition of Man= aged Objects for the Neighborhood Discovery Protocol
>>>> draft-ietf-manet-nhdp-sec-02    Using Integrity C= heck Values and Timestamps For Router Admittance in NHDP
>>>> draft-ietf-manet-olsrv2-16    The Optimized Link S= tate Routing Protocol version 2
>>>> draft-ietf-manet-olsrv2-metrics-rationale-01    L= ink Metrics for the Mobile Ad Hoc Network (MANET) Routing
>>>> draft-ietf-manet-olsrv2-mib-04    Definition of M= anaged Objects for the Optimized Link State Routing Protocol
>>>>
>>>>
>>>>
>>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:
>>>>
>>>>> I've seen a number of emails on the alias but not sure L= OADng
>>>>> has been accepted by the WG.  Is LOADng asking to b= e a MANET WG
>>>>> draft?
>>>>>
>>>>> -Bo
>>>>>
>>>>>
>>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>>
>>>>>> Please note that I strongly object any including of= LOADng draft in the Agenda.
>>>>>> The document is not for MANET, was already presente= d before, and the
>>>>>> authors are not discussing on ietf lists of any pro= gress. The draft is
>>>>>> not reasonable for the WG, if it is not discussed o= n the MANET list.
>>>>>>
>>>>>> I got no reasonable reply to all my efforts, the la= st as:
>>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html
>>>>>>
>>>>>> AB
>>>>>> On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> the MANET WG will meet on Wednesday, Nov. 7 fro= m 1pm to 2.30pm in Salon A.
>>>>>>> If you intend to present something, please send= a request to the chairs.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Ulrich
>>>>>> _______________________________________________
= >>>>>> manet mailing list
>>>>>> manet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>> ---
>>>>> We cannot solve our problems with the same thinking we u= sed when we created them.
>>>>> Albert Einstein
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>> ---
>>>> We cannot solve our problems with the same thinking we used= when we created them.
>>>> Albert Einstein
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>> ***********************************************************= *********
>>>> This email and any attachments are confidential to the inte= nded
>>>> recipient and may also be privileged. If you are not the in= tended
>>>> recipient please delete it from your system and notify the s= ender.
>>>> You should not copy it or use it for any purpose nor disclo= se or
>>>> distribute its contents to any other person.
>>>> ***********************************************************= *********
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet



= --Apple-Mail-0D5DB8C3-5D16-4AA0-BDF0-1C29679A8CD5-- From jvasseur@cisco.com Sat Oct 13 09:48:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A225D21F843F for ; Sat, 13 Oct 2012 09:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egDHaLSp9oTB for ; Sat, 13 Oct 2012 09:48:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 72A5D21F851B for ; Sat, 13 Oct 2012 09:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31703; q=dns/txt; s=iport; t=1350146905; x=1351356505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=27Wo+tGcCCmmflqbACOgOsJuxY7+ZCuu5wQCoHJ4x6Q=; b=ev5L09JYGVndBt/hpuarkHJeBJmvbTAGyaqfKDFNDkreshwhxsTfs6xO bRYqQUbs71beFHk+/JezvaRicTFYgWB5RDTVHFWlCecgN5IAV6tHQv2F2 BujbUdE6Q05sw/I4SibmaLFzlJaJtBW/94kH3WIasjWl+9PlPDZbzT/Pr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALuaeVCtJV2a/2dsb2JhbABFv2yBCIIgAQEBAwEBAQEPAQc7GQMIBQcEAgEIBwoEAQEBChYHBycLFAkIAgQOBQgBGYdcBgucLJ9Qi1kUBgiFO2ADpDGBa4JtgVoJNA X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208,217";a="131285889" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 13 Oct 2012 16:48:24 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9DGmOTZ022274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 16:48:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 11:48:23 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqVmoxQdayxYbx0aw5eRdXfbe8w== Date: Sat, 13 Oct 2012 16:48:22 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> In-Reply-To: <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--51.538500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FD5E91xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 16:48:28 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FD5E91xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 13, 2012, at 5:57 PM, Ulrich Herberg wrote: Hi JP, On Oct 13, 2012, at 8:44, "JP Vasseur (jvasseur)" > wrote: Hi Ulrich, On Oct 13, 2012, at 5:26 PM, Ulrich Herberg wrote: Hi JP, On Sat, Oct 13, 2012 at 2:21 AM, JP Vasseur (jvasseur) > wrote: Hi Ulrich, On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote: > Hi, > > (speaking on my own, not to representing the LOADng authors). > > As was pointed out before, we often have discussed items that were not WG= documents, usually at the end of the meeting, to make sure that there is e= nough time for WG items. I also agree with what Stan said: MANET should not= be standardizing documents that are mainly focused on LLNs; Just to make sure that we do not play with words =85. As agreed between the= chairs, it should read "MANET is standardizing documents that are not deal= ing with LLNs/IoT". This is much stronger that "mainly on LLNs" I think (as MANET participant, not LOADng author) that the reactive protoco= l in the MANET WG should be a *MANET protocol*. I also think that a Standar= ds Track document can (or maybe should) mention where it is used in deploym= ents and implementations. JP> I would not disagree. As a matter of fact, LOADng is used in LLN deployments, and I think this is= important to mention. This is just one use case of LOADng, not the only on= e. JP> This is where we have a major disagreement; the fact that this protocol= is used for some LLNs does mean that it is the right thing to do for the I= ETF. I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, if w= e come up with a MANET reactive protocol, it is only logical that for some = LLNs the reactive MANET protocol would be suitable as well; but clearly, MA= NET should cover the general case of MANETs. JP> So in this case, I would suggest to explicitly exclude all LLNs coverag= e from the Load ID, and have it covered in ROLL. Does that make sense ? This is why the IETF has formed a WG to deal with LLNs, and the WG worked f= or years to reach the conclusion that a pro-active protocol should be chose= n. That is fine, and I don't see any problem with that. As Adrian said at the last IETF "some if not all LLNs are MANET, but not al= l MANETs are LLNs"; as such, I think it is fair to mention use cases of LOA= Dng and deployments (and clearly there should be many more use cases that t= hose) I think this would be fully in charter of MANET, and would not coincide wit= h any other WG. JP> Working chair-hat on, if we have two WGs going in opposite directions f= or LLNs, we clearly have an overlap - this is what the chairs of ROLL and M= ANET want to avoid. Right, and I don't see why there would be overlap. JP> As long as you agree with the previous statement, we're fine. Thanks. JP. Regards Ulrich Regards. JP. Regards Ulrich Thanks. JP. > however, a document that is focused on MANETS, and as a matter of fact is= also used in LLN deployments should be acceptable, in my opinion. > > We are currently finalizing some internal discussions between the authors= of LOADng, and I think that there will be an email to the list on that reg= ards in the next few days. Abdussalam, being against presentation of someth= ing that has not even been proposed yet is premature and pointless, in my o= pinion. > > Best regards > Ulrich > > On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" > wrote: > >> I think you are in violent agreement. The current LOADng draft is (IIRC)= aimed at LLNs, so Teco is saying unless there's a new MANET-oriented versi= on it shouldn't be discussed, and you are saying it won't be discussed. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124<= tel:%2B44%201245%20242124> >> chris.dearlove@baesystems.com | ht= tp://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >> Sent: 12 October 2012 15:12 >> To: Teco Boot >> Cc: Dearlove, Christopher (UK); > = List; Bo Berry (boberry) >> Subject: Re: [manet] MANET meeting at IETF85 >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >> >>> On July 31th, our chair provided guidance on handling LOADng. >>> It shows the way forward. >>> >>> I'm looking forward to an draft-author-manet-loadng-00 draft, submitted= before next Monday. >>> If there is no such draft, and little time to discuss non-wg drafts, we= should not discuss an lln draft in our meeting in Atlanta. >> >> One (not too) fine point - we (the MANET WG) will *not* be discussing an= LLN draft. At any time. That would be a charter violation - LLN's are defi= ned and worked in ROLL. We are discussing MANET reactive protocols. >> >> Stan >> >> >>> I'm OK on discussions on how to fulfill our charter item on a reactive = protocol. >>> >>> Teco >>> >>> >>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende= geschreven: >>> >>>> We have often discussed things not yet accepted by the WG, it can be a= step towards getting them accepted. >>>> >>>> That's not a comment for or against LOADng, discussing LOADng, or adop= ting LOADng, just an observation on what has happened in the past. >>>> >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | = http://www.baesystems.com >>>> >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>> >>>> >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:ma= net-bounces@ietf.org] On Behalf Of Bo Berry >>>> Sent: 12 October 2012 13:40 >>>> To: Abdussalam Baryun; > List; B= o Berry >>>> Subject: Re: [manet] MANET meeting at IETF85 >>>> >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>> >>>> Looking at the MANET WG Documents page, LOADng is not on the list. So = until LOADng is accepted by the WG, gotta agree with Abdussalam, no need to= discuss it in the little time we have for the work we've already accepted. >>>> >>>> How does this fit into the WG Charter? >>>> >>>> -Bo >>>> >>>> >>>> Active Internet-Drafts >>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) >>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the = Neighborhood Discovery Protocol >>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Times= tamps For Router Admittance in NHDP >>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protoco= l version 2 >>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the M= obile Ad Hoc Network (MANET) Routing >>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for th= e Optimized Link State Routing Protocol >>>> >>>> >>>> >>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>> >>>>> I've seen a number of emails on the alias but not sure LOADng >>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>>> draft? >>>>> >>>>> -Bo >>>>> >>>>> >>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>> >>>>>> Please note that I strongly object any including of LOADng draft in = the Agenda. >>>>>> The document is not for MANET, was already presented before, and the >>>>>> authors are not discussing on ietf lists of any progress. The draft = is >>>>>> not reasonable for the WG, if it is not discussed on the MANET list. >>>>>> >>>>>> I got no reasonable reply to all my efforts, the last as: >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>> >>>>>> AB >>>>>> On 10/9/12, Ulrich Herberg > wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in S= alon A. >>>>>>> If you intend to present something, please send a request to the ch= airs. >>>>>>> >>>>>>> Best regards >>>>>>> Ulrich >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> --- >>>>> We cannot solve our problems with the same thinking we used when we c= reated them. >>>>> Albert Einstein >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> --- >>>> We cannot solve our problems with the same thinking we used when we cr= eated them. >>>> Albert Einstein >>>> >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>>> ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> ******************************************************************** >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FD5E91xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 13, 2012, at 5:57 PM, Ulrich Herberg wrote:

Hi JP,

On Oct 13, 2012, at 8:44, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Hi Ulrich,

On Oct 13, 2012, at 5:26 PM, Ulrich Herberg wrote:

Hi JP,

On Sat, Oct 13, 2012 at 2:21 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
Hi Ulrich,

On Oct 12, 2012, at 5:38 PM, Ulrich Herberg wrote:

> Hi,
>
> (speaking on my own, not to representing the LOADng authors).
>
> As was pointed out before, we often have discussed items that were not= WG documents, usually at the end of the meeting, to make sure that there i= s enough time for WG items. I also agree with what Stan said: MANET should = not be standardizing documents that are mainly focused on LLNs;

Just to make sure that we do not play with words =85. As agreed between the= chairs, it should read "MANET is standardizing documents that are not= dealing with LLNs/IoT".
This is much stronger that "mainly on LLNs"


I think (as MANET participant, not LOADng author) that the reactive pr= otocol in the MANET WG should be a *MANET protocol*. I also think that a St= andards Track document can (or maybe should) mention where it is used in de= ployments and implementations.

JP> I would not disagree.

As a matter of fact, LOADng is used in LLN deployments, and I think th= is is important to mention. This is just one use case of LOADng, not the on= ly one.

JP> This is where we have a major disagreement; the fact tha= t this protocol is used for some LLNs does mean that it is the right thing = to do for the IETF.

I repeat what Adrian said: some if not all LLNs are MANETs. Therefore,= if we come up with a MANET reactive protocol, it is only logical that for = some LLNs the reactive MANET protocol would be suitable as well; but clearl= y, MANET should cover the general case of MANETs.

JP> So in this case, I would suggest to explicitly exclude all LLNs= coverage from the Load ID, and have it covered in ROLL. Does that make sen= se ?



This is why the IETF has formed a WG to deal with LLNs, and the WG wor= ked for years to reach the conclusion that a pro-active protocol shoul= d be chosen.

That is fine, and I don't see any problem with that.


As Adrian said at the last IETF "some if not all LLNs are MANET, but not all MANETs are LLNs&quo= t;; as such, I think it is fair to mention use cases of LOADng and deployme= nts (and clearly there should be many more use cases that those)
I think this would be fully in charter of MANET, and would not coincid= e with any other WG.

JP> Working chair-hat on, if we have two WGs going in opposite dire= ctions for LLNs, we clearly have an overlap - this is what the chairs of RO= LL and MANET 
want to avoid.

Right, and I don't see why there would be overlap.

JP> As long as you agree with the previous statement, we're fine.

Thanks.

JP.


Regards
Ulrich




Regards.

JP.


Regards
Ulrich

 

Thanks.

JP.

> however, a document that is focused on MANETS, and as a matter of fact= is also used in LLN deployments should be acceptable, in my opinion.
>
> We are currently finalizing some internal discussions between the auth= ors of LOADng, and I think that there will be an email to the list on that = regards in the next few days. Abdussalam, being against presentation of som= ething that has not even been proposed yet is premature and pointless, in my opinion.
>
> Best regards
> Ulrich
>
> On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" <<= a href=3D"mailto:Chris.Dearlove@baesystems.com">Chris.Dearlove@baesystems.c= om> wrote:
>
>> I think you are in violent agreement. The current LOADng draft is = (IIRC) aimed at LLNs, so Teco is saying unless there's a new MANET-oriented= version it shouldn't be discussed, and you are saying it won't be discusse= d.
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1= 245 242124
>> chris.dearlove@ba= esystems.com | http://www.baesyst= ems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
>> Sent: 12 October 2012 15:12
>> To: Teco Boot
>> Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berry (boberry)
>> Subject: Re: [manet] MANET meeting at IETF85
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:
>>
>>> On July 31th, our chair provided guidance on handling LOADng.<= br> >>> It shows the way forward.
>>>
>>> I'm looking forward to an draft-author-manet-loadng-00 draft, = submitted before next Monday.
>>> If there is no such draft, and little time to discuss non-wg d= rafts, we should not discuss an lln draft in our meeting in Atlanta.
>>
>> One (not too) fine point - we (the MANET WG) will *not* be discuss= ing an LLN draft. At any time. That would be a charter violation - LLN's ar= e defined and worked in ROLL. We are discussing MANET reactive protocols. >>
>> Stan
>>
>>
>>> I'm OK on discussions on how to fulfill our charter item on a = reactive protocol.
>>>
>>> Teco
>>>
>>>
>>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het= volgende geschreven:
>>>
>>>> We have often discussed things not yet accepted by the WG,= it can be a step towards getting them accepted.
>>>>
>>>> That's not a comment for or against LOADng, discussing LOA= Dng, or adopting LOADng, just an observation on what has happened in the pa= st.
>>>>
>>>> --
>>>> Christopher Dearlove
>>>> Senior Principal Engineer, Communications Group
>>>> Communications, Networks and Image Analysis Capability
>>>> BAE Systems Advanced Technology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,= UK
>>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124<= br> >>>> chris.dea= rlove@baesystems.com | http://www.baesyst= ems.com
>>>>
>>>> BAE Systems (Operations) Limited
>>>> Registered Office: Warwick House, PO Box 87, Farnborough A= erospace Centre, Farnborough, Hants, GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: manet-boun= ces@ietf.org [mailto:manet-bo= unces@ietf.org] On Behalf Of Bo Berry
>>>> Sent: 12 October 2012 13:40
>>>> To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
>>>> Subject: Re: [manet] MANET meeting at IETF85
>>>>
>>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation,
>>>> either from an external partner or from the internet.
>>>> Keep this in mind if you answer this message.
>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>
>>>> Looking at the MANET WG Documents page, LOADng is not on t= he list. So until LOADng is accepted by the WG, gotta agree with Abdussalam= , no need to discuss it in the little time we have for the work we've alrea= dy accepted.
>>>>
>>>> How does this fit into the WG Charter?
>>>>
>>>> -Bo
>>>>
>>>>
>>>> Active Internet-Drafts
>>>> draft-ietf-manet-dlep-03    Dynamic Link Exchang= e Protocol (DLEP)
>>>> draft-ietf-manet-nhdp-mib-19    Definition of Ma= naged Objects for the Neighborhood Discovery Protocol
>>>> draft-ietf-manet-nhdp-sec-02    Using Integrity = Check Values and Timestamps For Router Admittance in NHDP
>>>> draft-ietf-manet-olsrv2-16    The Optimized Link= State Routing Protocol version 2
>>>> draft-ietf-manet-olsrv2-metrics-rationale-01    = Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
>>>> draft-ietf-manet-olsrv2-mib-04    Definition of = Managed Objects for the Optimized Link State Routing Protocol
>>>>
>>>>
>>>>
>>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:
>>>>
>>>>> I've seen a number of emails on the alias but not sure= LOADng
>>>>> has been accepted by the WG.  Is LOADng asking to= be a MANET WG
>>>>> draft?
>>>>>
>>>>> -Bo
>>>>>
>>>>>
>>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote:<= br> >>>>>
>>>>>> Please note that I strongly object any including o= f LOADng draft in the Agenda.
>>>>>> The document is not for MANET, was already present= ed before, and the
>>>>>> authors are not discussing on ietf lists of any pr= ogress. The draft is
>>>>>> not reasonable for the WG, if it is not discussed = on the MANET list.
>>>>>>
>>>>>> I got no reasonable reply to all my efforts, the l= ast as:
>>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13448.html
>>>>>>
>>>>>> AB
>>>>>> On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> the MANET WG will meet on Wednesday, Nov. 7 fr= om 1pm to 2.30pm in Salon A.
>>>>>>> If you intend to present something, please sen= d a request to the chairs.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Ulrich
>>>>>> _______________________________________________ >>>>>> manet mailing list
>>>>>> manet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>> ---
>>>>> We cannot solve our problems with the same thinking we= used when we created them.
>>>>> Albert Einstein
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>> ---
>>>> We cannot solve our problems with the same thinking we use= d when we created them.
>>>> Albert Einstein
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>> **********************************************************= **********
>>>> This email and any attachments are confidential to the int= ended
>>>> recipient and may also be privileged. If you are not the i= ntended
>>>> recipient please delete it from your system and notify the= sender.
>>>> You should not copy it or use it for any purpose nor discl= ose or
>>>> distribute its contents to any other person.
>>>> **********************************************************= **********
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet




--_000_03B78081B371D44390ED6E7BADBB4A7721FD5E91xmbrcdx02ciscoc_-- From c.chauvenet@watteco.com Sat Oct 13 11:16:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ED121F84D7 for ; Sat, 13 Oct 2012 11:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=1.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qRIDUcrd9Xq for ; Sat, 13 Oct 2012 11:16:32 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 663B921F8496 for ; Sat, 13 Oct 2012 11:16:32 -0700 (PDT) Received: from mail46-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Sat, 13 Oct 2012 18:16:29 +0000 Received: from mail46-ch1 (localhost [127.0.0.1]) by mail46-ch1-R.bigfish.com (Postfix) with ESMTP id D68782A016C; Sat, 13 Oct 2012 18:16:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zzbb2dI98dI9371Ic89bhd6eahc85eh542M1dbaI1418I14ffIzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh84d07hz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail46-ch1 (localhost.localdomain [127.0.0.1]) by mail46-ch1 (MessageSwitch) id 1350152184892626_18317; Sat, 13 Oct 2012 18:16:24 +0000 (UTC) Received: from CH1EHSMHS042.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail46-ch1.bigfish.com (Postfix) with ESMTP id D669C2600B8; Sat, 13 Oct 2012 18:16:24 +0000 (UTC) Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS042.bigfish.com (10.43.69.251) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 13 Oct 2012 18:16:21 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.67.167]) with mapi id 14.16.0207.009; Sat, 13 Oct 2012 18:16:19 +0000 From: C Chauvenet To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAA== Date: Sat, 13 Oct 2012 18:16:18 +0000 Message-ID: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_546B80D07AA74320B28AAC6059C6084Ewattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:16:35 -0000 --_000_546B80D07AA74320B28AAC6059C6084Ewattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, Thank you for your answer, see inline. Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit : Hi C=E9dric, On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet > wrote: Hi all, I agree with Teco that the message from the chair (http://www.ietf.org/mail= -archive/web/manet/current/msg13305.html) is a good move. In particular that "the LLN needs to be deemphasized as the primary purpose= if adopted as manet". I agree. However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 says in its = introduction that : The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) is a routing protocol, derived from AODV [RFC3561] and extended for use in Lo= w power and Lossy Networks (LLNs). The introduction will be largely changed in the next revision. So, removing LLNs' related material on this draft could get back to AODV wh= ich is already RFC 3561. So what is the improvement ? That is not true. There are many improvements from what we learned from AOD= V, and which has been integrated when designing the protocol (see below) >From what I understand, the LOADng purpose should be a new version of AODV = addressing some of the points suggested by the MANET chair such as "improve= ments in heterogeneity support, simplification where sensible, improved con= trol plane flooding, better IPv6 support, and a eventually clear border gat= eway specification". That is exactly what LOADng does (and that will be clearer in the next revi= sion). It allows for improved flooding (e.g. using SMF/MPR flooding), it ha= s improved IPv6 support, it is more flexible through the use of RFC5444, it= is simplified as several items from AODV (such as iRREP, precursor list) h= ave been removed, it is easier to secure using the security architecture ba= sed on RFC5444/RFC6622 and by avoiding iRREPs. We still need to work in the= clearer border gateway specification. In short : LLNs constraints and challenges should not be adressed by LOADng= , but LOADng could improve the AODV original specification for MANET networ= ks. As one (out of many) use cases are LLNs, experience from these deployments = should be integrated. The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : The LOADng routing protocol was run over UDP and IPv4. Either Ethernet or 802.11 wireless network was used in the test. The description of the participants are in section 4.3 : 1 - LIX ) : It consists of approximately 6000 lines of JAVA code running in a Mac OS environment 2 - Hitachi1) : It consists of 1589 lines of C code running in the Hitachi proprietary micro OS environment embedded in a 16MHz H8 micro processor. 3 - Hitachi2) : It consists of 1987 lines of C++ code running in a Mac OS environment. So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? But since the reactive MANET protocol is a MANET protocol, there will be ma= ny other use cases which we also address in the draft. We have learned from= the experience with AODV (and there is plenty, just Google Scholar for AOD= V), and I think that many of those learnings are integrated already in LOAD= ng. Best regards Ulrich Is my understanding correct ? Best, C=E9dric. Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit : I assume the authors take the guidance from our chair, posted in: http://www.ietf.org/mail-archive/web/manet/current/msg13305.html If so, I do not see a reason not to discuss LOADng. And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings. Teco Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: Hi, (speaking on my own, not to representing the LOADng authors). As was pointed out before, we often have discussed items that were not WG d= ocuments, usually at the end of the meeting, to make sure that there is eno= ugh time for WG items. I also agree with what Stan said: MANET should not b= e standardizing documents that are mainly focused on LLNs; however, a docum= ent that is focused on MANETS, and as a matter of fact is also used in LLN = deployments should be acceptable, in my opinion. We are currently finalizing some internal discussions between the authors o= f LOADng, and I think that there will be an email to the list on that regar= ds in the next few days. Abdussalam, being against presentation of somethin= g that has not even been proposed yet is premature and pointless, in my opi= nion. Best regards Ulrich On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" > wrote: I think you are in violent agreement. The current LOADng draft is (IIRC) ai= med at LLNs, so Teco is saying unless there's a new MANET-oriented version = it shouldn't be discussed, and you are saying it won't be discussed. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 12 October 2012 15:12 To: Teco Boot Cc: Dearlove, Christopher (UK); > Lis= t; Bo Berry (boberry) Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: On July 31th, our chair provided guidance on handling LOADng. It shows the way forward. I'm looking forward to an draft-author-manet-loadng-00 draft, submitted bef= ore next Monday. If there is no such draft, and little time to discuss non-wg drafts, we sho= uld not discuss an lln draft in our meeting in Atlanta. One (not too) fine point - we (the MANET WG) will *not* be discussing an LL= N draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols. Stan I'm OK on discussions on how to fulfill our charter item on a reactive prot= ocol. Teco Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende ges= chreven: We have often discussed things not yet accepted by the WG, it can be a step= towards getting them accepted. That's not a comment for or against LOADng, discussing LOADng, or adopting = LOADng, just an observation on what has happened in the past. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Bo Berry Sent: 12 October 2012 13:40 To: Abdussalam Baryun; > List; Bo Ber= ry Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Looking at the MANET WG Documents page, LOADng is not on the list. So until= LOADng is accepted by the WG, gotta agree with Abdussalam, no need to disc= uss it in the little time we have for the work we've already accepted. How does this fit into the WG Charter? -Bo Active Internet-Drafts draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neigh= borhood Discovery Protocol draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps= For Router Admittance in NHDP draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol ver= sion 2 draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile= Ad Hoc Network (MANET) Routing draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Opt= imized Link State Routing Protocol On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: I've seen a number of emails on the alias but not sure LOADng has been accepted by the WG. Is LOADng asking to be a MANET WG draft? -Bo On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: Please note that I strongly object any including of LOADng draft in the Age= nda. The document is not for MANET, was already presented before, and the authors are not discussing on ietf lists of any progress. The draft is not reasonable for the WG, if it is not discussed on the MANET list. I got no reasonable reply to all my efforts, the last as: http://www.ietf.org/mail-archive/web/manet/current/msg13448.html AB On 10/9/12, Ulrich Herberg = > wrote: Hi, the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. If you intend to present something, please send a request to the chairs. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet C=E9dric CHAUVENET Ph.D Student c.chauvenet@watteco.com Direct Line : +33(0)4 98 01 35 81 Mobile : +33(0)6 30 21 14 91 Standard : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE =96 France www.watteco.com Before printing think about environment and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. --_000_546B80D07AA74320B28AAC6059C6084Ewattecocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4ADFD7FC37E9A44CA2D6BB2302CC4100@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Ulrich, 

Thank you for your answer, see inline.

Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit :

Hi C=E9dric,

On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
Hi all, 

I agree with Teco that the message from the chair (http://www.ietf.org/mail-archive/web/manet/current/msg13305.html) is a= good move. 
In particular that "the LLN needs to be deemphasized as the primary purpose if adopted as manet&qu= ot;.


I agree.

 


However http://tools.ietf.org/html/draft-clausen-lln-lo= adng-05 says in its introduction that :

The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next
   Generation (LOADng) is a routing protocol, derived from AODV
   [RFC3561] and extended for use in Low power and Lossy Networks
   (LLNs).


The introduction will be largely changed in the next revision.
 


That is not true. There are many improvements from what we learned fro= m AODV, and which has been integrated when designing the protocol (see belo= w)
 

From what I understand, the LOADng purpose should be a new version of A=
ODV addressing some of the points suggested by the MANET chair such as &quo=
t;improvements in heterogeneity support, simplification where sensible, i=
mproved control plane flooding, better IPv6 support, and a eventually clear=
 border gateway specification".  


That is exactly what LOADng does (and that will be clearer in the next= revision). It allows for improved flooding (e.g. using SMF/MPR flooding), = it has improved IPv6 support, it is more flexible through the use of RFC544= 4, it is simplified as several items from AODV (such as iRREP, precursor list) have been removed, it is easier = to secure using the security architecture based on RFC5444/RFC6622 and by a= voiding iRREPs. We still need to work in the clearer border gateway specifi= cation.

 

In short : LLNs constraints and challenges sh=
ould not be adressed by LOADng, but LOADng could improve the AODV original =
specification for MANET networks.


As one (out of many) use cases are LLNs, experience from these deploym= ents should be integrated.

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).


The LOADng routing protocol was run over U=
DP and
   IPv4.  Either Ethernet or 802.11 wireless network was used in the
   test.

The description of the participants are in section 4.3 : 
1 - LIX ) : It
      consists of approximately 6000 lines of JAVA code running in a Mac
      OS environment
2 - Hitachi1) : It consists of 1589 l= ines of C
      code running in the Hitachi propriet=
ary micro OS environment
      embedded in a 16MHz H8 micro processor.
3 - Hitachi2) : It consists of 1987 l= ines of C++ code
      running in a Mac OS environment.
So my first guess is that LOADng is suitable for what I called "m= ains-powered computer using Wifi" ?


But since the reactive MANET protocol is a MANET protocol, there will = be many other use cases which we also address in the draft. We have learned= from the experience with AODV (and there is plenty, just Google Scholar fo= r AODV), and I think that many of those learnings are integrated already in LOADng.

Best regards
Ulrich


 

Is my understanding correct ?

Best,

C=E9dric.

Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit :

I assume the authors take the guidance from our chair, posted in:
http://www.ietf.org/mail-archive/web/manet/current/msg1= 3305.html

If so, I do not see a reason not to discuss LOADng.
And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings.=

Teco

Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven:

Hi,

(speaking on my own, not to representing the LOAD= ng authors).

As was pointed out before, we often have discusse= d items that were not WG documents, usually at the end of the meeting, to m= ake sure that there is enough time for WG items. I also agree with what Sta= n said: MANET should not be standardizing documents that are mainly focused on LLNs; however, a document that is foc= used on MANETS, and as a matter of fact is also used in LLN deployments sho= uld be acceptable, in my opinion.

We are currently finalizing some internal discuss= ions between the authors of LOADng, and I think that there will be an email= to the list on that regards in the next few days. Abdussalam, being agains= t presentation of something that has not even been proposed yet is premature and pointless, in my opinion.

Best regards
Ulrich

On Oct 12, 2012, at 7:15, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:

I think you are in violent agreement. The current= LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless there's a n= ew MANET-oriented version it shouldn't be discussed, and you are saying it = won't be discussed.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berr= y (boberry)
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:

On July 31th, our chair provided guidance on hand= ling LOADng.
It shows the way forward.

I'm looking forward to an draft-author-manet-load= ng-00 draft, submitted before next Monday.
If there is no such draft, and little time to dis= cuss non-wg drafts, we should not discuss an lln draft in our meeting in At= lanta.

One (not too) fine point - we (the MANET WG) will= *not* be discussing an LLN draft. At any time. That would be a charter vio= lation - LLN's are defined and worked in ROLL. We are discussing MANET reac= tive protocols.

Stan


I'm OK on discussions on how to fulfill our chart= er item on a reactive protocol.

Teco


Op 12 okt. 2012, om 15:19 heeft Dearlove, Christo= pher (UK) het volgende geschreven:

We have often discussed things not yet accepted b= y the WG, it can be a step towards getting them accepted.

That's not a comment for or against LOADng, discu= ssing LOADng, or adopting LOADng, just an observation on what has happened = in the past.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Bo Berry
Sent: 12 October 2012 13:40
To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

Looking at the MANET WG Documents page, LOADng is= not on the list. So until LOADng is accepted by the WG, gotta agree with A= bdussalam, no need to discuss it in the little time we have for the work we= 've already accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03    Dynami= c Link Exchange Protocol (DLEP)    
draft-ietf-manet-nhdp-mib-19    De= finition of Managed Objects for the Neighborhood Discovery Protocol  &= nbsp; 
draft-ietf-manet-nhdp-sec-02    Us= ing Integrity Check Values and Timestamps For Router Admittance in NHDP &nb= sp;  
draft-ietf-manet-olsrv2-16    The = Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-metrics-rationale-01 &nbs= p;  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
draft-ietf-manet-olsrv2-mib-04    = Definition of Managed Objects for the Optimized Link State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:

I've seen a number of emails on the alias but not= sure LOADng
has been accepted by the WG.  Is LOADng aski= ng to be a MANET WG
draft?

-Bo


On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wr= ote:

Please note that I strongly object any including = of LOADng draft in the Agenda.
The document is not for MANET, was already presen= ted before, and the
authors are not discussing on ietf lists of any p= rogress. The draft is
not reasonable for the WG, if it is not discussed= on the MANET list.

I got no reasonable reply to all my efforts, the = last as:
http://www.ietf.org/mail-arch= ive/web/manet/current/msg13448.html

AB
On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

the MANET WG will meet on Wednesday, Nov. 7 from = 1pm to 2.30pm in Salon A.
If you intend to present something, please send a= request to the chairs.

Best regards
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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


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

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

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


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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


<image001.jpg>

C=E9dric = CHAUVENET

Ph.D Student

c.chauvenet@watteco.com<= u>

Direct= Line :   +33(0)4 98 01 35 81=
Mobile : &n= bsp;        +33(0)6 30 = 21 14 91

Standard :=    +33(0)4 98 01 60 05

Fax :     = ;        +3= 3(0)4 94 14 10 80
 
1766 Chemin de la Planqu= ette
83130 LA GARDE =96 Franc= e

<image002.gif>

 B= efore printing think about environment and costs
This = Message may contain confidential information intended only for the use of t= he addressee named above. If you are not the intended recipient of this mes= sage you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohib= ited. If you received this message by mistake, please notify the sender by = reply email immediately. Please conduct your own virus checks before openin= g any attachment as Watteco does not guarantee the integrity of this email or attached files has been maint= ained nor this communication is free of viruses, interceptions or interfere= nce. Any views expressed in this message are those of the individual sender= and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for the = improper and incomplete transmission of the information contained in this c= ommunication nor for any delay in its receipt or damage to your system.
=



--_000_546B80D07AA74320B28AAC6059C6084Ewattecocom_-- From jvasseur@cisco.com Sat Oct 13 11:57:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9834721F8493 for ; Sat, 13 Oct 2012 11:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1q8+RvOAiz1 for ; Sat, 13 Oct 2012 11:57:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E8CA521F848B for ; Sat, 13 Oct 2012 11:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81365; q=dns/txt; s=iport; t=1350154671; x=1351364271; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l2ccPJ5BkszM1BS4/9FjIfbf6UiLD70QDMHId1OOJho=; b=l1uGHwrXmz28/I7WphK6eBY9l8MsqLRT9BUTRqt7y80v0DJAoKZk4yQb weTKtHrUT4ebtT5oSYjD5WdThaVnyUJtDbx1hASKhOmoQm9ediJZl6LlI yVms/IddOt04aCDOOiuCEmc0DtU3L8EjgDBF0Ab48vF1nwibT1u/8M31w I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAEa5eVCtJV2a/2dsb2JhbABCA4JLtEUBiF2BCIIgAQEBBAEBAQ8BBy8MGQMIDAQCAQgHCgEDAQELFgEGBycLFAMGCAIEDgUIARmHYgucNJ9Gi1kUBgEHgnWCRmADlwGNMIFrgm2BWgk0 X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208,217";a="131338054" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 13 Oct 2012 18:57:39 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9DIvcMp006773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 18:57:38 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 13:57:38 -0500 From: "JP Vasseur (jvasseur)" To: C Chauvenet Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqXScxQdayxYbx0aw5eRdXfbe8w== Date: Sat, 13 Oct 2012 18:57:37 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD6815@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> In-Reply-To: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--39.626400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FD6815xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:57:58 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FD6815xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Cedric - I can totally with everything you said. On Oct 13, 2012, at 8:16 PM, C Chauvenet wrote: Hi Ulrich, Thank you for your answer, see inline. Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit : Hi C=E9dric, On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet > wrote: Hi all, I agree with Teco that the message from the chair (http://www.ietf.org/mail= -archive/web/manet/current/msg13305.html) is a good move. In particular that "the LLN needs to be deemphasized as the primary purpose= if adopted as manet". I agree. However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 says in its = introduction that : The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) is a routing protocol, derived from AODV [RFC3561] and extended for use in Lo= w power and Lossy Networks (LLNs). The introduction will be largely changed in the next revision. So, removing LLNs' related material on this draft could get back to AODV wh= ich is already RFC 3561. So what is the improvement ? That is not true. There are many improvements from what we learned from AOD= V, and which has been integrated when designing the protocol (see below) >From what I understand, the LOADng purpose should be a new version of AODV = addressing some of the points suggested by the MANET chair such as "improve= ments in heterogeneity support, simplification where sensible, improved con= trol plane flooding, better IPv6 support, and a eventually clear border gat= eway specification". That is exactly what LOADng does (and that will be clearer in the next revi= sion). It allows for improved flooding (e.g. using SMF/MPR flooding), it ha= s improved IPv6 support, it is more flexible through the use of RFC5444, it= is simplified as several items from AODV (such as iRREP, precursor list) h= ave been removed, it is easier to secure using the security architecture ba= sed on RFC5444/RFC6622 and by avoiding iRREPs. We still need to work in the= clearer border gateway specification. In short : LLNs constraints and challenges should not be adressed by LOADng= , but LOADng could improve the AODV original specification for MANET networ= ks. As one (out of many) use cases are LLNs, experience from these deployments = should be integrated. The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : The LOADng routing protocol was run over UDP and IPv4. Either Ethernet or 802.11 wireless network was used in the test. The description of the participants are in section 4.3 : 1 - LIX ) : It consists of approximately 6000 lines of JAVA code running in a Mac OS environment 2 - Hitachi1) : It consists of 1589 lines of C code running in the Hitachi proprietary micro OS environment embedded in a 16MHz H8 micro processor. 3 - Hitachi2) : It consists of 1987 lines of C++ code running in a Mac OS environment. So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? But since the reactive MANET protocol is a MANET protocol, there will be ma= ny other use cases which we also address in the draft. We have learned from= the experience with AODV (and there is plenty, just Google Scholar for AOD= V), and I think that many of those learnings are integrated already in LOAD= ng. Best regards Ulrich Is my understanding correct ? Best, C=E9dric. Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit : I assume the authors take the guidance from our chair, posted in: http://www.ietf.org/mail-archive/web/manet/current/msg13305.html If so, I do not see a reason not to discuss LOADng. And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings. Teco Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: Hi, (speaking on my own, not to representing the LOADng authors). As was pointed out before, we often have discussed items that were not WG d= ocuments, usually at the end of the meeting, to make sure that there is eno= ugh time for WG items. I also agree with what Stan said: MANET should not b= e standardizing documents that are mainly focused on LLNs; however, a docum= ent that is focused on MANETS, and as a matter of fact is also used in LLN = deployments should be acceptable, in my opinion. We are currently finalizing some internal discussions between the authors o= f LOADng, and I think that there will be an email to the list on that regar= ds in the next few days. Abdussalam, being against presentation of somethin= g that has not even been proposed yet is premature and pointless, in my opi= nion. Best regards Ulrich On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" > wrote: I think you are in violent agreement. The current LOADng draft is (IIRC) ai= med at LLNs, so Teco is saying unless there's a new MANET-oriented version = it shouldn't be discussed, and you are saying it won't be discussed. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 12 October 2012 15:12 To: Teco Boot Cc: Dearlove, Christopher (UK); > Lis= t; Bo Berry (boberry) Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: On July 31th, our chair provided guidance on handling LOADng. It shows the way forward. I'm looking forward to an draft-author-manet-loadng-00 draft, submitted bef= ore next Monday. If there is no such draft, and little time to discuss non-wg drafts, we sho= uld not discuss an lln draft in our meeting in Atlanta. One (not too) fine point - we (the MANET WG) will *not* be discussing an LL= N draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols. Stan I'm OK on discussions on how to fulfill our charter item on a reactive prot= ocol. Teco Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende ges= chreven: We have often discussed things not yet accepted by the WG, it can be a step= towards getting them accepted. That's not a comment for or against LOADng, discussing LOADng, or adopting = LOADng, just an observation on what has happened in the past. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Bo Berry Sent: 12 October 2012 13:40 To: Abdussalam Baryun; > List; Bo Ber= ry Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Looking at the MANET WG Documents page, LOADng is not on the list. So until= LOADng is accepted by the WG, gotta agree with Abdussalam, no need to disc= uss it in the little time we have for the work we've already accepted. How does this fit into the WG Charter? -Bo Active Internet-Drafts draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neigh= borhood Discovery Protocol draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps= For Router Admittance in NHDP draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol ver= sion 2 draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile= Ad Hoc Network (MANET) Routing draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Opt= imized Link State Routing Protocol On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: I've seen a number of emails on the alias but not sure LOADng has been accepted by the WG. Is LOADng asking to be a MANET WG draft? -Bo On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: Please note that I strongly object any including of LOADng draft in the Age= nda. The document is not for MANET, was already presented before, and the authors are not discussing on ietf lists of any progress. The draft is not reasonable for the WG, if it is not discussed on the MANET list. I got no reasonable reply to all my efforts, the last as: http://www.ietf.org/mail-archive/web/manet/current/msg13448.html AB On 10/9/12, Ulrich Herberg = > wrote: Hi, the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. If you intend to present something, please send a request to the chairs. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet C=E9dric CHAUVENET Ph.D Student c.chauvenet@watteco.com Direct Line : +33(0)4 98 01 35 81 Mobile : +33(0)6 30 21 14 91 Standard : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE =96 France www.watteco.com Before printing think about environment and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FD6815xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4D027037B1675B4ABF35E4A617A718B4@cisco.com> Content-Transfer-Encoding: quoted-printable Thanks Cedric - I can totally with everything you said.

On Oct 13, 2012, at 8:16 PM, C Chauvenet wrote:

Hi Ulrich, 

Thank you for your answer, see inline.

Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit :

Hi C=E9dric,

On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
Hi all, 

I agree with Teco that the message from the chair (http://www.ietf.org/mail-archive/web/manet/current/msg13305.html) is a= good move. 
In particular that "the LLN needs to be deemphasized as the primary purpose if adopted as manet&qu= ot;.


I agree.

 


However http://tools.ietf.org/html/draft-clausen-lln-lo= adng-05 says in its introduction that :

The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next
   Generation (LOADng) is a routing protocol, derived from AODV
   [RFC3561] and extended for use in Low power and Lossy Networks
   (LLNs).


The introduction will be largely changed in the next revision.
 


That is not true. There are many improvements from what we learned fro= m AODV, and which has been integrated when designing the protocol (see belo= w)
 

From what I understand, the LOADng purpose should be a new version of A=
ODV addressing some of the points suggested by the MANET chair such as &quo=
t;improvements in heterogeneity support, simplification where sensible, i=
mproved control plane flooding, better IPv6 support, and a eventually clear=
 border gateway specification".  


That is exactly what LOADng does (and that will be clearer in the next= revision). It allows for improved flooding (e.g. using SMF/MPR flooding), = it has improved IPv6 support, it is more flexible through the use of RFC544= 4, it is simplified as several items from AODV (such as iRREP, precursor list) have been removed, it is easier = to secure using the security architecture based on RFC5444/RFC6622 and by a= voiding iRREPs. We still need to work in the clearer border gateway specifi= cation.

 

In short : LLNs constraints and challenges sh=
ould not be adressed by LOADng, but LOADng could improve the AODV original =
specification for MANET networks.


As one (out of many) use cases are LLNs, experience from these deploym= ents should be integrated.

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).


The LOADng routing protocol was run over U=
DP and
   IPv4.  Either Ethernet or 802.11 wireless network was used in the
   test.

The description of the participants are in section 4.3 : 
1 - LIX ) : It
      consists of approximately 6000 lines of JAVA code running in a Mac
      OS environment
2 - Hitachi1) : It consists of 1589 l= ines of C
      code running in the Hitachi propriet=
ary micro OS environment
      embedded in a 16MHz H8 micro processor.
3 - Hitachi2) : It consists of 1987 l= ines of C++ code
      running in a Mac OS environment.
So my first guess is that LOADng is suitable for what I called "m= ains-powered computer using Wifi" ?


But since the reactive MANET protocol is a MANET protocol, there will = be many other use cases which we also address in the draft. We have learned= from the experience with AODV (and there is plenty, just Google Scholar fo= r AODV), and I think that many of those learnings are integrated already in LOADng.

Best regards
Ulrich


 

Is my understanding correct ?

Best,

C=E9dric.

Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit :

I assume the authors take the guidance from our chair, posted in:
http://www.ietf.org/mail-archive/web/manet/current/msg1= 3305.html

If so, I do not see a reason not to discuss LOADng.
And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings.=

Teco

Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven:

Hi,

(speaking on my own, not to representing the LOAD= ng authors).

As was pointed out before, we often have discusse= d items that were not WG documents, usually at the end of the meeting, to m= ake sure that there is enough time for WG items. I also agree with what Sta= n said: MANET should not be standardizing documents that are mainly focused on LLNs; however, a document that is foc= used on MANETS, and as a matter of fact is also used in LLN deployments sho= uld be acceptable, in my opinion.

We are currently finalizing some internal discuss= ions between the authors of LOADng, and I think that there will be an email= to the list on that regards in the next few days. Abdussalam, being agains= t presentation of something that has not even been proposed yet is premature and pointless, in my opinion.

Best regards
Ulrich

On Oct 12, 2012, at 7:15, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:

I think you are in violent agreement. The current= LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless there's a n= ew MANET-oriented version it shouldn't be discussed, and you are saying it = won't be discussed.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berr= y (boberry)
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:

On July 31th, our chair provided guidance on hand= ling LOADng.
It shows the way forward.

I'm looking forward to an draft-author-manet-load= ng-00 draft, submitted before next Monday.
If there is no such draft, and little time to dis= cuss non-wg drafts, we should not discuss an lln draft in our meeting in At= lanta.

One (not too) fine point - we (the MANET WG) will= *not* be discussing an LLN draft. At any time. That would be a charter vio= lation - LLN's are defined and worked in ROLL. We are discussing MANET reac= tive protocols.

Stan


I'm OK on discussions on how to fulfill our chart= er item on a reactive protocol.

Teco


Op 12 okt. 2012, om 15:19 heeft Dearlove, Christo= pher (UK) het volgende geschreven:

We have often discussed things not yet accepted b= y the WG, it can be a step towards getting them accepted.

That's not a comment for or against LOADng, discu= ssing LOADng, or adopting LOADng, just an observation on what has happened = in the past.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Bo Berry
Sent: 12 October 2012 13:40
To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

Looking at the MANET WG Documents page, LOADng is= not on the list. So until LOADng is accepted by the WG, gotta agree with A= bdussalam, no need to discuss it in the little time we have for the work we= 've already accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03    Dynami= c Link Exchange Protocol (DLEP)    
draft-ietf-manet-nhdp-mib-19    De= finition of Managed Objects for the Neighborhood Discovery Protocol  &= nbsp; 
draft-ietf-manet-nhdp-sec-02    Us= ing Integrity Check Values and Timestamps For Router Admittance in NHDP &nb= sp;  
draft-ietf-manet-olsrv2-16    The = Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-metrics-rationale-01 &nbs= p;  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
draft-ietf-manet-olsrv2-mib-04    = Definition of Managed Objects for the Optimized Link State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:

I've seen a number of emails on the alias but not= sure LOADng
has been accepted by the WG.  Is LOADng aski= ng to be a MANET WG
draft?

-Bo


On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wr= ote:

Please note that I strongly object any including = of LOADng draft in the Agenda.
The document is not for MANET, was already presen= ted before, and the
authors are not discussing on ietf lists of any p= rogress. The draft is
not reasonable for the WG, if it is not discussed= on the MANET list.

I got no reasonable reply to all my efforts, the = last as:
http://www.ietf.org/mail-arch= ive/web/manet/current/msg13448.html

AB
On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

the MANET WG will meet on Wednesday, Nov. 7 from = 1pm to 2.30pm in Salon A.
If you intend to present something, please send a= request to the chairs.

Best regards
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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


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

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

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


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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


<image001.jpg>

C=E9dric = CHAUVENET

Ph.D Student

c.chauvenet@watteco.com<= u>

Direct= Line :   +33(0)4 98 01 35 81=
Mobile : &n= bsp;        +33(0)6 30 = 21 14 91

Standard :=    +33(0)4 98 01 60 05

Fax :     = ;        +3= 3(0)4 94 14 10 80
 
1766 Chemin de la Planqu= ette
83130 LA GARDE =96 Franc= e

<image002.gif>

 B= efore printing think about environment and costs
This = Message may contain confidential information intended only for the use of t= he addressee named above. If you are not the intended recipient of this mes= sage you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohib= ited. If you received this message by mistake, please notify the sender by = reply email immediately. Please conduct your own virus checks before openin= g any attachment as Watteco does not guarantee the integrity of this email or attached files has been maint= ained nor this communication is free of viruses, interceptions or interfere= nce. Any views expressed in this message are those of the individual sender= and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for the = improper and incomplete transmission of the information contained in this c= ommunication nor for any delay in its receipt or damage to your system.
=



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

--_000_03B78081B371D44390ED6E7BADBB4A7721FD6815xmbrcdx02ciscoc_-- From yi.jiazi@gmail.com Sat Oct 13 13:45:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CEC1F0417 for ; Sat, 13 Oct 2012 13:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9BBAuFdJmPC for ; Sat, 13 Oct 2012 13:45:15 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id DCFFC21F846D for ; Sat, 13 Oct 2012 13:45:14 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so322270wib.1 for ; Sat, 13 Oct 2012 13:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:message-id:mime-version:subject:date :references:to:in-reply-to:x-mailer; bh=dr0BJOocp6x+U0TGYindRn0oihgx8YDenKXPiQJ8cJs=; b=wwyAXYWzwaEbs0X/j/9CRoDhdOxqDa/HDff8YuwdU6HYBDTzZuxQQpaSIH1bYjDQ7t iIx+IqRcGpDWyJWFvotvR8mHvvAw3tdyHFeVxfjw1wvy09VjsofQ8df+bcP4JATf1io7 p4JL/PlqwEIVeeVWphZjZ7KeNLGtu+S+I9oUl1Rsz6Xx+dhBgVBPQg0gSTOU1Y8WV5sU x5rsOYGSuz1Hfi/SxyCocxA14vSZZhl5Bd+S1/QVvMjTm33AZCEWrKDc0mp6Oy7Mss3t Q2wMoShSIs7j5nvy24CydZrPKPO12ZErOP26XimqT5ICeIyZPNtjWLtnqR4+NkzuNBB+ yHiw== Received: by 10.180.79.103 with SMTP id i7mr13855990wix.13.1350161113592; Sat, 13 Oct 2012 13:45:13 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id ct3sm4998584wib.5.2012.10.13.13.45.07 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 13:45:12 -0700 (PDT) Sender: Jiazi YI From: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_45B26DB4-965A-4F35-B127-09FEF0A87A68" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Sat, 13 Oct 2012 22:45:06 +0200 References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> To: List In-Reply-To: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> X-Mailer: Apple Mail (2.1499) Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 20:45:18 -0000 --Apple-Mail=_45B26DB4-965A-4F35-B127-09FEF0A87A68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Cedric,=20 I think I have answered you this question before in a private mail.=20 As long as you asked, let me just repeat it again: Those are tests aimed for interoperability, not for performance.=20 So the main purpose is to: o Verify the function/messages exchanges of the protocol, so as = to find bugs and improve the specification.=20 o Make sure that the document is well written such as = independent/interoperable implementations can be developed.=20 Those tests are to make sure that the protocol can be implemented = independently without consulting the original developers of the = protocol.=20 So I won't say this interop test is related to the definition of the = protocol scope.=20 best Jiazi On Oct 13, 2012, at 8:16 PM, C Chauvenet = wrote: > Hi Ulrich,=20 >=20 > Thank you for your answer, see inline. >=20 > Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit : >=20 >> Hi C=E9dric, >>=20 >> On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet = wrote: >> Hi all,=20 >>=20 >> I agree with Teco that the message from the chair = (http://www.ietf.org/mail-archive/web/manet/current/msg13305.html) is a = good move.=20 >> In particular that "the LLN needs to be deemphasized as the primary = purpose if adopted as manet". >>=20 >>=20 >> I agree. >>=20 >> =20 >>=20 >>=20 >> However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 says = in its introduction that : >>=20 >> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next >> Generation (LOADng) is a routing protocol, derived from AODV >> [RFC3561] and extended for use in Low power and Lossy Networks >> (LLNs). >>=20 >>=20 >> The introduction will be largely changed in the next revision. >> =20 >>=20 >> So, removing LLNs' related material on this draft could get back to = AODV which is already RFC 3561. So what is the improvement ? >>=20 >>=20 >> That is not true. There are many improvements from what we learned = from AODV, and which has been integrated when designing the protocol = (see below) >> =20 >>=20 >> =46rom what I understand, the LOADng purpose should be a new version = of AODV addressing some of the points suggested by the MANET chair such = as "improvements in heterogeneity support, simplification where = sensible, improved control plane flooding, better IPv6 support, and a = eventually clear border gateway specification". =20 >>=20 >>=20 >> That is exactly what LOADng does (and that will be clearer in the = next revision). It allows for improved flooding (e.g. using SMF/MPR = flooding), it has improved IPv6 support, it is more flexible through the = use of RFC5444, it is simplified as several items from AODV (such as = iRREP, precursor list) have been removed, it is easier to secure using = the security architecture based on RFC5444/RFC6622 and by avoiding = iRREPs. We still need to work in the clearer border gateway = specification. >>=20 >> =20 >>=20 >> In short : LLNs constraints and challenges should not be adressed by = LOADng, but LOADng could improve the AODV original specification for = MANET networks. >>=20 >>=20 >> As one (out of many) use cases are LLNs, experience from these = deployments should be integrated. >=20 > The distinction between MANET and LLNs seems to be vanish here. > This brings us back to the summer discussion between what is a MANET = and what is a LLN that did not really fostered on a consensus. > WG chairs could help there, as it is their related scope. > My vision is that LLNs are more constrained than MANET for the = following criterion : Power consumption, Loss of the media, Computation = capability, Throughput. > What do you think ? > My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol. > Do you agree ? >=20 > I'm trying to figure out if LOADng is efficient over a mains-powered = computer using Wifi, a 8K/48K RAM/ROM device, or both (cover such a = wide range would be magical !). >=20 > I see in the interop report = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report= -02 in section 3 : >=20 > The LOADng routing protocol was run over UDP and > IPv4. Either Ethernet or 802.11 wireless network was used in the > test. >=20 > The description of the participants are in section 4.3 :=20 > 1 - LIX ) : It > consists of approximately 6000 lines of JAVA code running in a = Mac > OS environment > 2 - Hitachi1) : It consists of 1589 lines of C > code running in the Hitachi proprietary micro OS environment > embedded in a 16MHz H8 micro processor. > 3 - Hitachi2) : It consists of 1987 lines of C++ code > running in a Mac OS environment. >=20 > So my first guess is that LOADng is suitable for what I called = "mains-powered computer using Wifi" ? >=20 >=20 >> But since the reactive MANET protocol is a MANET protocol, there will = be many other use cases which we also address in the draft. We have = learned from the experience with AODV (and there is plenty, just Google = Scholar for AODV), and I think that many of those learnings are = integrated already in LOADng. >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> =20 >>=20 >> Is my understanding correct ? >>=20 >> Best, >>=20 >> C=E9dric. >>=20 >> Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit : >>=20 >>> I assume the authors take the guidance from our chair, posted in: >>> http://www.ietf.org/mail-archive/web/manet/current/msg13305.html >>>=20 >>> If so, I do not see a reason not to discuss LOADng. >>> And yes, I am with Stan we will *not* discuss LLN topics in MANET = meetings. >>>=20 >>> Teco >>>=20 >>> Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende = geschreven: >>>=20 >>>> Hi, >>>>=20 >>>> (speaking on my own, not to representing the LOADng authors). >>>>=20 >>>> As was pointed out before, we often have discussed items that were = not WG documents, usually at the end of the meeting, to make sure that = there is enough time for WG items. I also agree with what Stan said: = MANET should not be standardizing documents that are mainly focused on = LLNs; however, a document that is focused on MANETS, and as a matter of = fact is also used in LLN deployments should be acceptable, in my = opinion. >>>>=20 >>>> We are currently finalizing some internal discussions between the = authors of LOADng, and I think that there will be an email to the list = on that regards in the next few days. Abdussalam, being against = presentation of something that has not even been proposed yet is = premature and pointless, in my opinion.=20 >>>>=20 >>>> Best regards >>>> Ulrich >>>>=20 >>>> On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" = wrote: >>>>=20 >>>>> I think you are in violent agreement. The current LOADng draft is = (IIRC) aimed at LLNs, so Teco is saying unless there's a new = MANET-oriented version it shouldn't be discussed, and you are saying it = won't be discussed. >>>>>=20 >>>>> --=20 >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>=20 >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >>>>> Sent: 12 October 2012 15:12 >>>>> To: Teco Boot >>>>> Cc: Dearlove, Christopher (UK); List; Bo Berry = (boberry) >>>>> Subject: Re: [manet] MANET meeting at IETF85 >>>>>=20 >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>>=20 >>>>> On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: >>>>>=20 >>>>>> On July 31th, our chair provided guidance on handling LOADng. >>>>>> It shows the way forward. >>>>>>=20 >>>>>> I'm looking forward to an draft-author-manet-loadng-00 draft, = submitted before next Monday. >>>>>> If there is no such draft, and little time to discuss non-wg = drafts, we should not discuss an lln draft in our meeting in Atlanta. >>>>>=20 >>>>> One (not too) fine point - we (the MANET WG) will *not* be = discussing an LLN draft. At any time. That would be a charter violation = - LLN's are defined and worked in ROLL. We are discussing MANET reactive = protocols.=20 >>>>>=20 >>>>> Stan >>>>>=20 >>>>>=20 >>>>>> I'm OK on discussions on how to fulfill our charter item on a = reactive protocol. >>>>>>=20 >>>>>> Teco=20 >>>>>>=20 >>>>>>=20 >>>>>> Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het = volgende geschreven: >>>>>>=20 >>>>>>> We have often discussed things not yet accepted by the WG, it = can be a step towards getting them accepted. >>>>>>>=20 >>>>>>> That's not a comment for or against LOADng, discussing LOADng, = or adopting LOADng, just an observation on what has happened in the = past. >>>>>>>=20 >>>>>>> --=20 >>>>>>> Christopher Dearlove >>>>>>> Senior Principal Engineer, Communications Group >>>>>>> Communications, Networks and Image Analysis Capability >>>>>>> BAE Systems Advanced Technology Centre >>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>=20 >>>>>>> BAE Systems (Operations) Limited >>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>>>>> Registered in England & Wales No: 1996687 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Bo Berry >>>>>>> Sent: 12 October 2012 13:40 >>>>>>> To: Abdussalam Baryun; List; Bo Berry >>>>>>> Subject: Re: [manet] MANET meeting at IETF85 >>>>>>>=20 >>>>>>> ----------------------! WARNING ! ---------------------- >>>>>>> This message originates from outside our organisation, >>>>>>> either from an external partner or from the internet. >>>>>>> Keep this in mind if you answer this message. >>>>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>>>> for instructions on reporting suspicious email messages. >>>>>>> -------------------------------------------------------- >>>>>>>=20 >>>>>>> Looking at the MANET WG Documents page, LOADng is not on the = list. So until LOADng is accepted by the WG, gotta agree with = Abdussalam, no need to discuss it in the little time we have for the = work we've already accepted. >>>>>>>=20 >>>>>>> How does this fit into the WG Charter? >>>>>>>=20 >>>>>>> -Bo >>>>>>>=20 >>>>>>>=20 >>>>>>> Active Internet-Drafts >>>>>>> draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol = (DLEP) =20 >>>>>>> draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects = for the Neighborhood Discovery Protocol =20 >>>>>>> draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and = Timestamps For Router Admittance in NHDP =20 >>>>>>> draft-ietf-manet-olsrv2-16 The Optimized Link State Routing = Protocol version 2 >>>>>>> draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for = the Mobile Ad Hoc Network (MANET) Routing=20 >>>>>>> draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects = for the Optimized Link State Routing Protocol=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: >>>>>>>=20 >>>>>>>> I've seen a number of emails on the alias but not sure LOADng=20= >>>>>>>> has been accepted by the WG. Is LOADng asking to be a MANET WG >>>>>>>> draft? >>>>>>>>=20 >>>>>>>> -Bo >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: >>>>>>>>=20 >>>>>>>>> Please note that I strongly object any including of LOADng = draft in the Agenda. >>>>>>>>> The document is not for MANET, was already presented before, = and the >>>>>>>>> authors are not discussing on ietf lists of any progress. The = draft is >>>>>>>>> not reasonable for the WG, if it is not discussed on the MANET = list. >>>>>>>>>=20 >>>>>>>>> I got no reasonable reply to all my efforts, the last as: >>>>>>>>> = http://www.ietf.org/mail-archive/web/manet/current/msg13448.html >>>>>>>>>=20 >>>>>>>>> AB >>>>>>>>> On 10/9/12, Ulrich Herberg wrote: >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> the MANET WG will meet on Wednesday, Nov. 7 from 1pm to = 2.30pm in Salon A. >>>>>>>>>> If you intend to present something, please send a request to = the chairs. >>>>>>>>>>=20 >>>>>>>>>> Best regards >>>>>>>>>> Ulrich >>>>>>>>> _______________________________________________ >>>>>>>>> manet mailing list >>>>>>>>> manet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>=20 >>>>>>>> --- >>>>>>>> We cannot solve our problems with the same thinking we used = when we created them.=20 >>>>>>>> Albert Einstein >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>> --- >>>>>>> We cannot solve our problems with the same thinking we used when = we created them.=20 >>>>>>> Albert Einstein >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>>=20 >>>>>>> = ******************************************************************** >>>>>>> This email and any attachments are confidential to the intended >>>>>>> recipient and may also be privileged. If you are not the = intended >>>>>>> recipient please delete it from your system and notify the = sender. >>>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>>> distribute its contents to any other person. >>>>>>> = ******************************************************************** >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> >> C=E9dric CHAUVENET >>=20 >> Ph.D Student >>=20 >> c.chauvenet@watteco.com >>=20 >> Direct Line : +33(0)4 98 01 35 81 >> Mobile : +33(0)6 30 21 14 91 >> Standard : +33(0)4 98 01 60 05 >> Fax : +33(0)4 94 14 10 80 >> =20 >> 1766 Chemin de la Planquette >> 83130 LA GARDE =96 France >> www.watteco.com >>=20 >> >> Before printing think about environment and costs >>=20 >> This Message may contain confidential information intended only for = the use of the addressee named above. If you are not the intended = recipient of this message you are hereby notified that any use, = dissemination, distribution or reproduction of this message is = prohibited. If you received this message by mistake, please notify the = sender by reply email immediately. Please conduct your own virus checks = before opening any attachment as Watteco does not guarantee the = integrity of this email or attached files has been maintained nor this = communication is free of viruses, interceptions or interference. Any = views expressed in this message are those of the individual sender and = may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of = the information contained in this communication nor for any delay in its = receipt or damage to your system. >>=20 >>=20 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_45B26DB4-965A-4F35-B127-09FEF0A87A68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Cedric, 

I think I = have answered you this question before in a private = mail. 

As long as = you asked, let me just repeat it again:
Those are tests aimed for interoperability, = not for performance. 

So the main purpose = is to:
o Verify the function/messages exchanges of the protocol, = so as to find bugs and improve the specification. 
o Make = sure that the document is well written such as independent/interoperable = implementations can be developed. 

Those = tests are to make sure that the protocol can be implemented = independently without consulting the original developers of the = protocol. 
So I won't say this interop test is related to = the definition of the protocol = scope. 

best

Jiazi



On Oct 13, 2012, at 8:16 PM, C Chauvenet <c.chauvenet@watteco.com> = wrote:

Hi Ulrich, 

Thank you for your answer, see inline.

Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit :

Hi C=E9dric,

On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet = <c.chauvenet@watteco.com> wrote:
Hi all, 

I agree with Teco that the message from the chair (http://www.ietf.org/mail-archive/web/manet/current/msg13= 305.html) is a good move. 
In particular that "the LLN needs to be deemphasized as the primary purpose if adopted as = manet".


I agree.

 


The introduction will be largely changed in the next = revision.
 

So, =
removing LLNs' related material on this draft could get back to AODV =
which is already RFC 3561. So what is the improvement ?


That is not true. There are many improvements from what we learned = from AODV, and which has been integrated when designing the protocol = (see below)
 

=46rom=
 what I understand, the LOADng purpose should be a new version of AODV =
addressing some of the points suggested by the MANET chair such as =
"improvemen=
ts in heterogeneity support, simplification where sensible, improved =
control plane flooding, better IPv6 support, and a eventually clear =
border gateway specification".  =


That is exactly what LOADng does (and that will be clearer in the = next revision). It allows for improved flooding (e.g. using SMF/MPR = flooding), it has improved IPv6 support, it is more flexible through the = use of RFC5444, it is simplified as several items from AODV (such as iRREP, precursor list) have been removed, it is = easier to secure using the security architecture based on = RFC5444/RFC6622 and by avoiding iRREPs. We still need to work in the = clearer border gateway specification.

 

In =
short : LLNs&n=
bsp;constr=
aints and challenges should not be adressed by LOADng, but LOADng could =
improve the AODV original specification for MANET networks.


As one (out of many) use cases are LLNs, experience from these = deployments should be integrated.

The distinction between MANET and LLNs seems to be vanish = here.
This brings us back to the summer discussion between what is a = MANET and what is a LLN that did not really fostered on a = consensus.
WG chairs could help there, as it is their related scope.
My vision is that LLNs are more constrained than MANET for the = following criterion : Power consumption, Loss of the media, Computation = capability, Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not = be considered in a MANET protocol.
Do you agree ?

I'm trying to figure out if LOADng is efficient over a = mains-powered computer using Wifi, a 8K/48K RAM/ROM device,  or = both (cover such a wide range would be magical !).

The =
LOADng routing protocol was run over UDP and
   IPv4.  Either Ethernet or 802.11 wireless network was used in the
   test.
1 - =
LIX ) : It
      consists of approximately 6000 lines of JAVA code running in a Mac
      OS environment
2 - Hitachi1) : It = consists of 1589 lines of C
      =
code running in the Hitachi proprietary micro OS environment
      embedded in a 16MHz H8 micro processor.
3 - Hitachi2) : It = consists of 1987 lines of C++ code
      =
running in a Mac OS environment.

So my first guess is that LOADng is suitable for what I called = "mains-powered computer using Wifi" ?


But since the reactive MANET protocol is a MANET protocol, there = will be many other use cases which we also address in the draft. We have = learned from the experience with AODV (and there is plenty, just Google = Scholar for AODV), and I think that many of those learnings are integrated already in LOADng.

Best regards
Ulrich


 

Is =
my understanding correct ?

Best,<=
/span>

C=E9dr=
ic.

Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit :

I assume the authors take the guidance from our chair, posted = in:
http://www.ietf.org/mail-archive/web/manet/current/msg13= 305.html

If so, I do not see a reason not to discuss LOADng.
And yes, I am with Stan we will *not* discuss LLN topics in MANET = meetings.

Teco

Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende = geschreven:

Hi,

(speaking on my own, not to representing the = LOADng authors).

As was pointed out before, we often have = discussed items that were not WG documents, usually at the end of the = meeting, to make sure that there is enough time for WG items. I also = agree with what Stan said: MANET should not be standardizing documents that are mainly focused on LLNs; however, a document that is = focused on MANETS, and as a matter of fact is also used in LLN = deployments should be acceptable, in my opinion.

We are currently finalizing some internal = discussions between the authors of LOADng, and I think that there will = be an email to the list on that regards in the next few days. = Abdussalam, being against presentation of something that has not even been proposed yet is premature and pointless, in my opinion. =

Best regards
Ulrich

On Oct 12, 2012, at 7:15, "Dearlove, = Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

I think you are in violent agreement. The = current LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless = there's a new MANET-oriented version it shouldn't be discussed, and you = are saying it won't be discussed.

--
Christopher Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis = Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, = Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, = Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: = 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet@ietf.org> = List; Bo Berry (boberry)
Subject: Re: [manet] MANET meeting at = IETF85

----------------------! WARNING ! = ----------------------
This message originates from outside our = organisation,
either from an external partner or from the = internet.
Keep this in mind if you answer this = message.
Follow the 'Report Suspicious Emails' link on = IT matters
for instructions on reporting suspicious email = messages.
--------------------------------------------------------
=

On Oct 12, 2012, at 9:33 AM, Teco Boot = wrote:

On July 31th, our chair provided guidance on = handling LOADng.
It shows the way forward.

I'm looking forward to an = draft-author-manet-loadng-00 draft, submitted before next Monday.
If there is no such draft, and little time to = discuss non-wg drafts, we should not discuss an lln draft in our meeting = in Atlanta.

One (not too) fine point - we (the MANET WG) = will *not* be discussing an LLN draft. At any time. That would be a = charter violation - LLN's are defined and worked in ROLL. We are = discussing MANET reactive protocols.

Stan


I'm OK on discussions on how to fulfill our = charter item on a reactive protocol.

Teco


Op 12 okt. 2012, om 15:19 heeft Dearlove, = Christopher (UK) het volgende geschreven:

We have often discussed things not yet = accepted by the WG, it can be a step towards getting them accepted.

That's not a comment for or against LOADng, = discussing LOADng, or adopting LOADng, just an observation on what has = happened in the past.

--
Christopher Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis = Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, = Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, = Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: = 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Bo Berry
Sent: 12 October 2012 13:40
To: Abdussalam Baryun; <manet@ietf.org> = List; Bo Berry
Subject: Re: [manet] MANET meeting at = IETF85

----------------------! WARNING ! = ----------------------
This message originates from outside our = organisation,
either from an external partner or from the = internet.
Keep this in mind if you answer this = message.
Follow the 'Report Suspicious Emails' link on = IT matters
for instructions on reporting suspicious email = messages.
--------------------------------------------------------
=

Looking at the MANET WG Documents page, LOADng = is not on the list. So until LOADng is accepted by the WG, gotta agree = with Abdussalam, no need to discuss it in the little time we have for = the work we've already accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03 =    Dynamic Link Exchange Protocol (DLEP) =    
draft-ietf-manet-nhdp-mib-19 =    Definition of Managed Objects for the Neighborhood = Discovery Protocol    
draft-ietf-manet-nhdp-sec-02 =    Using Integrity Check Values and Timestamps For Router = Admittance in NHDP    
draft-ietf-manet-olsrv2-16 =    The Optimized Link State Routing Protocol version = 2
draft-ietf-manet-olsrv2-metrics-rationale-01 =    Link Metrics for the Mobile Ad Hoc Network (MANET) = Routing
draft-ietf-manet-olsrv2-mib-04 =    Definition of Managed Objects for the Optimized Link = State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry = wrote:

I've seen a number of emails on the alias but = not sure LOADng
has been accepted by the WG.  Is LOADng = asking to be a MANET WG
draft?

-Bo


On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun = wrote:

Please note that I strongly object any = including of LOADng draft in the Agenda.
The document is not for MANET, was already = presented before, and the
authors are not discussing on ietf lists of = any progress. The draft is
not reasonable for the WG, if it is not = discussed on the MANET list.

I got no reasonable reply to all my efforts, = the last as:
http://www.ietf.org/mail-archive/web/manet/current/msg13= 448.html

AB
On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

the MANET WG will meet on Wednesday, Nov. 7 = from 1pm to 2.30pm in Salon A.
If you intend to present something, please = send a request to the chairs.

Best regards
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same = thinking we used when we created them.
Albert Einstein



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

---
We cannot solve our problems with the same = thinking we used when we created them.
Albert Einstein



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


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

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

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


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

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


<image001.jpg>

C=E9dric= CHAUVENET

Ph.D = Student

c.chauvenet@watteco.com

Direct = Line :   +33(0)4 98 01 35 81
Mobile :  &nbs= p;       +33(0)6 30 21 14 = 91

Standard = :   +33(0)4 98 01 60 05

Fax = :     = ;        +33(0)4 94 14 10 80
 
1766 Chemin de la = Planquette
83130 LA GARDE =96 = France

<image002.gif>

 Before printing think = about environment and costs
This= Message may contain confidential information intended only for the use = of the addressee named above. If you are not the intended recipient of = this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is = prohibited. If you received this message by mistake, please notify the = sender by reply email immediately. Please conduct your own virus checks = before opening any attachment as Watteco does not guarantee the integrity of this email or attached files has been = maintained nor this communication is free of viruses, interceptions or = interference. Any views expressed in this message are those of the = individual sender and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for = the improper and incomplete transmission of the information contained in = this communication nor for any delay in its receipt or damage to your = system.



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

= --Apple-Mail=_45B26DB4-965A-4F35-B127-09FEF0A87A68-- From jvasseur@cisco.com Sat Oct 13 13:53:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B9521F846E for ; Sat, 13 Oct 2012 13:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0UfqE8Iqg+z for ; Sat, 13 Oct 2012 13:53:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8160C21F8444 for ; Sat, 13 Oct 2012 13:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=86398; q=dns/txt; s=iport; t=1350161595; x=1351371195; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=olb6b000jasSZujKZ2KRcHtghjbPkcIvOPyE4+AqkJw=; b=dNGQUS4303FoRJTmmUm5lwzFOHusgX4V916aVsqpWvgmdCSRo28T0R5M WOAF0zllFTW1JvWZqyc9rG1Y9dbIltZZQXzdClGYuMCxKnLYwkQIPpNIF O+2wBbBdOviOkcc6De0wSZh7w/m5EQzf18JtRu2XC1ld5wx9Xxene5SfN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFABzUeVCtJV2a/2dsb2JhbABBA4JLtEUBiF6BCIIgAQEBBAEBAQ8BBy8MGQMIDAQCAQgHCgEDAQELFgEGBycLFAMGCAIEDgUIARmHYgucQp8zi1kUBgEHgnWCRmADlwGNMIFrgm2BWgk0 X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208,217";a="131295902" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 13 Oct 2012 20:53:14 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9DKrEcp015327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 20:53:14 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 15:53:14 -0500 From: "JP Vasseur (jvasseur)" To: Jiazi YI Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqYTCxQdayxYbx0aw5eRdXfbe8w== Date: Sat, 13 Oct 2012 20:53:13 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD70EA@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--43.994100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FD70EAxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: List Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 20:53:18 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FD70EAxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Jiazi, Would you mind sharing the level of interop testing ? Thanks. JP. On Oct 13, 2012, at 10:45 PM, Jiazi YI wrote: Hi Cedric, I think I have answered you this question before in a private mail. As long as you asked, let me just repeat it again: Those are tests aimed for interoperability, not for performance. So the main purpose is to: o Verify the function/messages exchanges of the protocol, so as to find bug= s and improve the specification. o Make sure that the document is well written such as independent/interoper= able implementations can be developed. Those tests are to make sure that the protocol can be implemented independe= ntly without consulting the original developers of the protocol. So I won't say this interop test is related to the definition of the protoc= ol scope. best Jiazi On Oct 13, 2012, at 8:16 PM, C Chauvenet > wrote: Hi Ulrich, Thank you for your answer, see inline. Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit : Hi C=E9dric, On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet > wrote: Hi all, I agree with Teco that the message from the chair (http://www.ietf.org/mail= -archive/web/manet/current/msg13305.html) is a good move. In particular that "the LLN needs to be deemphasized as the primary purpose= if adopted as manet". I agree. However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 says in its = introduction that : The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) is a routing protocol, derived from AODV [RFC3561] and extended for use in Lo= w power and Lossy Networks (LLNs). The introduction will be largely changed in the next revision. So, removing LLNs' related material on this draft could get back to AODV wh= ich is already RFC 3561. So what is the improvement ? That is not true. There are many improvements from what we learned from AOD= V, and which has been integrated when designing the protocol (see below) >From what I understand, the LOADng purpose should be a new version of AODV = addressing some of the points suggested by the MANET chair such as "improve= ments in heterogeneity support, simplification where sensible, improved con= trol plane flooding, better IPv6 support, and a eventually clear border gat= eway specification". That is exactly what LOADng does (and that will be clearer in the next revi= sion). It allows for improved flooding (e.g. using SMF/MPR flooding), it ha= s improved IPv6 support, it is more flexible through the use of RFC5444, it= is simplified as several items from AODV (such as iRREP, precursor list) h= ave been removed, it is easier to secure using the security architecture ba= sed on RFC5444/RFC6622 and by avoiding iRREPs. We still need to work in the= clearer border gateway specification. In short : LLNs constraints and challenges should not be adressed by LOADng= , but LOADng could improve the AODV original specification for MANET networ= ks. As one (out of many) use cases are LLNs, experience from these deployments = should be integrated. The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : The LOADng routing protocol was run over UDP and IPv4. Either Ethernet or 802.11 wireless network was used in the test. The description of the participants are in section 4.3 : 1 - LIX ) : It consists of approximately 6000 lines of JAVA code running in a Mac OS environment 2 - Hitachi1) : It consists of 1589 lines of C code running in the Hitachi proprietary micro OS environment embedded in a 16MHz H8 micro processor. 3 - Hitachi2) : It consists of 1987 lines of C++ code running in a Mac OS environment. So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? But since the reactive MANET protocol is a MANET protocol, there will be ma= ny other use cases which we also address in the draft. We have learned from= the experience with AODV (and there is plenty, just Google Scholar for AOD= V), and I think that many of those learnings are integrated already in LOAD= ng. Best regards Ulrich Is my understanding correct ? Best, C=E9dric. Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit : I assume the authors take the guidance from our chair, posted in: http://www.ietf.org/mail-archive/web/manet/current/msg13305.html If so, I do not see a reason not to discuss LOADng. And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings. Teco Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: Hi, (speaking on my own, not to representing the LOADng authors). As was pointed out before, we often have discussed items that were not WG d= ocuments, usually at the end of the meeting, to make sure that there is eno= ugh time for WG items. I also agree with what Stan said: MANET should not b= e standardizing documents that are mainly focused on LLNs; however, a docum= ent that is focused on MANETS, and as a matter of fact is also used in LLN = deployments should be acceptable, in my opinion. We are currently finalizing some internal discussions between the authors o= f LOADng, and I think that there will be an email to the list on that regar= ds in the next few days. Abdussalam, being against presentation of somethin= g that has not even been proposed yet is premature and pointless, in my opi= nion. Best regards Ulrich On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" > wrote: I think you are in violent agreement. The current LOADng draft is (IIRC) ai= med at LLNs, so Teco is saying unless there's a new MANET-oriented version = it shouldn't be discussed, and you are saying it won't be discussed. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 12 October 2012 15:12 To: Teco Boot Cc: Dearlove, Christopher (UK); > Lis= t; Bo Berry (boberry) Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: On July 31th, our chair provided guidance on handling LOADng. It shows the way forward. I'm looking forward to an draft-author-manet-loadng-00 draft, submitted bef= ore next Monday. If there is no such draft, and little time to discuss non-wg drafts, we sho= uld not discuss an lln draft in our meeting in Atlanta. One (not too) fine point - we (the MANET WG) will *not* be discussing an LL= N draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols. Stan I'm OK on discussions on how to fulfill our charter item on a reactive prot= ocol. Teco Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende ges= chreven: We have often discussed things not yet accepted by the WG, it can be a step= towards getting them accepted. That's not a comment for or against LOADng, discussing LOADng, or adopting = LOADng, just an observation on what has happened in the past. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Bo Berry Sent: 12 October 2012 13:40 To: Abdussalam Baryun; > List; Bo Ber= ry Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Looking at the MANET WG Documents page, LOADng is not on the list. So until= LOADng is accepted by the WG, gotta agree with Abdussalam, no need to disc= uss it in the little time we have for the work we've already accepted. How does this fit into the WG Charter? -Bo Active Internet-Drafts draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neigh= borhood Discovery Protocol draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps= For Router Admittance in NHDP draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol ver= sion 2 draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile= Ad Hoc Network (MANET) Routing draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Opt= imized Link State Routing Protocol On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: I've seen a number of emails on the alias but not sure LOADng has been accepted by the WG. Is LOADng asking to be a MANET WG draft? -Bo On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: Please note that I strongly object any including of LOADng draft in the Age= nda. The document is not for MANET, was already presented before, and the authors are not discussing on ietf lists of any progress. The draft is not reasonable for the WG, if it is not discussed on the MANET list. I got no reasonable reply to all my efforts, the last as: http://www.ietf.org/mail-archive/web/manet/current/msg13448.html AB On 10/9/12, Ulrich Herberg = > wrote: Hi, the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. If you intend to present something, please send a request to the chairs. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet C=E9dric CHAUVENET Ph.D Student c.chauvenet@watteco.com Direct Line : +33(0)4 98 01 35 81 Mobile : +33(0)6 30 21 14 91 Standard : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE =96 France www.watteco.com Before printing think about environment and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FD70EAxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <08D3B717F137EA4DA72382700054EE57@cisco.com> Content-Transfer-Encoding: quoted-printable Dear Jiazi,

Would you mind sharing the level of interop testing ?

Thanks.

JP.

On Oct 13, 2012, at 10:45 PM, Jiazi YI wrote:

Hi Cedric, 

I think I have answer= ed you this question before in a private mail. 

As long as you asked,= let me just repeat it again:

Those are tests aimed for interoperability, not for performance. =

So the main purpose is to:
o V= erify the function/messages exchanges of the protocol, so as to find bugs a= nd improve the specification. 
o M= ake sure that the document is well written such as independent/interoperabl= e implementations can be developed. 

Those tests are to make sure that the protocol can be implemented inde= pendently without consulting the original developers of the protocol. =
So I won't say this interop test is related to the definition of the p= rotocol scope. 

best

Jiazi



On Oct 13, 2012, at 8:16 PM, C Chauvenet <c.chauvenet@watteco.com> wrote:

Hi Ulrich, 

Thank you for your answer, see inline.

Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit :

Hi C=E9dric,

On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
Hi all, 

I agree with Teco that the message from the chair (http://www.ietf.org/mail-archive/web/manet/current/msg13305.html) is a= good move. 
In particular that "the LLN needs to be deemphasized as the primary purpose if adopted as manet&qu= ot;.


I agree.

 


However http://tools.ietf.org/html/draft-clausen-lln-lo= adng-05 says in its introduction that :

The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next
   Generation (LOADng) is a routing protocol, derived from AODV
   [RFC3561] and extended for use in Low power and Lossy Networks
   (LLNs).


The introduction will be largely changed in the next revision.
 


That is not true. There are many improvements from what we learned fro= m AODV, and which has been integrated when designing the protocol (see belo= w)
 

From what I understand, the LOADng purpose should be a new version of A=
ODV addressing some of the points suggested by the MANET chair such as &quo=
t;improvements in heterogeneity support, simplification where sensible, i=
mproved control plane flooding, better IPv6 support, and a eventually clear=
 border gateway specification".  


That is exactly what LOADng does (and that will be clearer in the next= revision). It allows for improved flooding (e.g. using SMF/MPR flooding), = it has improved IPv6 support, it is more flexible through the use of RFC544= 4, it is simplified as several items from AODV (such as iRREP, precursor list) have been removed, it is easier = to secure using the security architecture based on RFC5444/RFC6622 and by a= voiding iRREPs. We still need to work in the clearer border gateway specifi= cation.

 

In short : LLNs constraints and challenges sh=
ould not be adressed by LOADng, but LOADng could improve the AODV original =
specification for MANET networks.


As one (out of many) use cases are LLNs, experience from these deploym= ents should be integrated.

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).


The LOADng routing protocol was run over UDP and
   IPv4.  Either Ethernet or 802.11 wireless network was used in the
   test.

The description of the participants are in section 4.3 : 
1 - LIX ) : It
      consists of approximately 6000 lines of JAVA code running in a Mac
      OS environment
2 - Hitachi1) : It consists of 1589 l= ines of C
      code running in the Hitachi proprietary micro OS environm=
ent
      embedded in a 16MHz H8 micro processor.
3 - Hitachi2) : It consists of 1987 l= ines of C++ code
      running in a Mac OS environment.

So my first guess is that LOADng is suitable for what I called "m= ains-powered computer using Wifi" ?


But since the reactive MANET protocol is a MANET protocol, there will = be many other use cases which we also address in the draft. We have learned= from the experience with AODV (and there is plenty, just Google Scholar fo= r AODV), and I think that many of those learnings are integrated already in LOADng.

Best regards
Ulrich


 

Is my understanding correct ?

Best,

C=E9dric.

Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit :

I assume the authors take the guidance from our chair, posted in:
http://www.ietf.org/mail-archive/web/manet/current/msg1= 3305.html

If so, I do not see a reason not to discuss LOADng.
And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings.=

Teco

Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven:

Hi,

(speaking on my own, not to representing the LOAD= ng authors).

As was pointed out before, we often have discusse= d items that were not WG documents, usually at the end of the meeting, to m= ake sure that there is enough time for WG items. I also agree with what Sta= n said: MANET should not be standardizing documents that are mainly focused on LLNs; however, a document that is foc= used on MANETS, and as a matter of fact is also used in LLN deployments sho= uld be acceptable, in my opinion.

We are currently finalizing some internal discuss= ions between the authors of LOADng, and I think that there will be an email= to the list on that regards in the next few days. Abdussalam, being agains= t presentation of something that has not even been proposed yet is premature and pointless, in my opinion.

Best regards
Ulrich

On Oct 12, 2012, at 7:15, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:

I think you are in violent agreement. The current= LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless there's a n= ew MANET-oriented version it shouldn't be discussed, and you are saying it = won't be discussed.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berr= y (boberry)
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:

On July 31th, our chair provided guidance on hand= ling LOADng.
It shows the way forward.

I'm looking forward to an draft-author-manet-load= ng-00 draft, submitted before next Monday.
If there is no such draft, and little time to dis= cuss non-wg drafts, we should not discuss an lln draft in our meeting in At= lanta.

One (not too) fine point - we (the MANET WG) will= *not* be discussing an LLN draft. At any time. That would be a charter vio= lation - LLN's are defined and worked in ROLL. We are discussing MANET reac= tive protocols.

Stan


I'm OK on discussions on how to fulfill our chart= er item on a reactive protocol.

Teco


Op 12 okt. 2012, om 15:19 heeft Dearlove, Christo= pher (UK) het volgende geschreven:

We have often discussed things not yet accepted b= y the WG, it can be a step towards getting them accepted.

That's not a comment for or against LOADng, discu= ssing LOADng, or adopting LOADng, just an observation on what has happened = in the past.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Bo Berry
Sent: 12 October 2012 13:40
To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

Looking at the MANET WG Documents page, LOADng is= not on the list. So until LOADng is accepted by the WG, gotta agree with A= bdussalam, no need to discuss it in the little time we have for the work we= 've already accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03    Dynami= c Link Exchange Protocol (DLEP)    
draft-ietf-manet-nhdp-mib-19    De= finition of Managed Objects for the Neighborhood Discovery Protocol  &= nbsp; 
draft-ietf-manet-nhdp-sec-02    Us= ing Integrity Check Values and Timestamps For Router Admittance in NHDP &nb= sp;  
draft-ietf-manet-olsrv2-16    The = Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-metrics-rationale-01 &nbs= p;  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
draft-ietf-manet-olsrv2-mib-04    = Definition of Managed Objects for the Optimized Link State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:

I've seen a number of emails on the alias but not= sure LOADng
has been accepted by the WG.  Is LOADng aski= ng to be a MANET WG
draft?

-Bo


On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wr= ote:

Please note that I strongly object any including = of LOADng draft in the Agenda.
The document is not for MANET, was already presen= ted before, and the
authors are not discussing on ietf lists of any p= rogress. The draft is
not reasonable for the WG, if it is not discussed= on the MANET list.

I got no reasonable reply to all my efforts, the = last as:
http://www.ietf.org/mail-arch= ive/web/manet/current/msg13448.html

AB
On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

the MANET WG will meet on Wednesday, Nov. 7 from = 1pm to 2.30pm in Salon A.
If you intend to present something, please send a= request to the chairs.

Best regards
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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


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

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

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


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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


<image001.jpg>

C=E9dric = CHAUVENET

Ph.D Student

c.chauvenet@watteco.com<= u>

Direct= Line :   +33(0)4 98 01 35 81=
Mobile : &n= bsp;        +33(0)6 30 = 21 14 91

Standard :=    +33(0)4 98 01 60 05

Fax :     = ;        +3= 3(0)4 94 14 10 80
 
1766 Chemin de la Planqu= ette
83130 LA GARDE =96 Franc= e

<image002.gif>

 B= efore printing think about environment and costs
This = Message may contain confidential information intended only for the use of t= he addressee named above. If you are not the intended recipient of this mes= sage you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohib= ited. If you received this message by mistake, please notify the sender by = reply email immediately. Please conduct your own virus checks before openin= g any attachment as Watteco does not guarantee the integrity of this email or attached files has been maint= ained nor this communication is free of viruses, interceptions or interfere= nce. Any views expressed in this message are those of the individual sender= and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for the = improper and incomplete transmission of the information contained in this c= ommunication nor for any delay in its receipt or damage to your system.
=



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

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

--_000_03B78081B371D44390ED6E7BADBB4A7721FD70EAxmbrcdx02ciscoc_-- From c.chauvenet@watteco.com Sat Oct 13 13:55:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C262921F846E for ; Sat, 13 Oct 2012 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3U8JFirJYlF for ; Sat, 13 Oct 2012 13:55:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id DBA1D21F8458 for ; Sat, 13 Oct 2012 13:55:51 -0700 (PDT) Received: from mail118-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Sat, 13 Oct 2012 20:55:51 +0000 Received: from mail118-ch1 (localhost [127.0.0.1]) by mail118-ch1-R.bigfish.com (Postfix) with ESMTP id 1EB79480106; Sat, 13 Oct 2012 20:55:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zzbb2dI98dI9371Ic89bhd6eahc85eh542M1dbaI1418I14ffIzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh84d07hz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail118-ch1 (localhost.localdomain [127.0.0.1]) by mail118-ch1 (MessageSwitch) id 1350161746474130_3573; Sat, 13 Oct 2012 20:55:46 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail118-ch1.bigfish.com (Postfix) with ESMTP id 704E5100047; Sat, 13 Oct 2012 20:55:46 +0000 (UTC) Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 13 Oct 2012 20:55:46 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT003.eurprd05.prod.outlook.com ([10.255.67.166]) with mapi id 14.16.0207.009; Sat, 13 Oct 2012 20:55:44 +0000 From: C Chauvenet To: Jiazi YI Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAIAAJm+AgAAGHIA= Date: Sat, 13 Oct 2012 20:55:43 +0000 Message-ID: <484EB252-C12E-40EC-89A9-0C1ADECD2204@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <107E45B2-4159-4AE0-B7E9-98BBAE657AD3@gmail.com> In-Reply-To: <107E45B2-4159-4AE0-B7E9-98BBAE657AD3@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_484EB252C12E40EC89A90C1ADECD2204wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 20:55:54 -0000 --_000_484EB252C12E40EC89A90C1ADECD2204wattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Le 13 oct. 2012 =E0 22:33, Jiazi YI a =E9crit : Hi Cedric, I think I have answered you this question before in a private mail. True. We will see what is the feeling of the WG this time. As long as you asked, let me just repeat it again: Those are tests aimed for interoperability, not for performance. So the main purpose is to: o Verify the function/messages exchanges of the protocol, so as to find bug= s and improve the specification. o Make sure that the document is well written such as independent/interoper= able implementations can be developed. Those tests are to make sure that the protocol can be implemented independe= ntly without consulting the original developers of the protocol. So I won't say this interop test is related to the definition of the protoc= ol scope. Does it means that these implementations have not been deployed ? What is your feeling regarding my previous question : "I'm trying to figure= out if LOADng is efficient over a mains-powered computer using Wifi, a 8K/= 48K RAM/ROM device, or both ?" C=E9dric. best Jiazi On Oct 13, 2012, at 8:16 PM, C Chauvenet > wrote: Hi Ulrich, Thank you for your answer, see inline. Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit : Hi C=E9dric, On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet > wrote: Hi all, I agree with Teco that the message from the chair (http://www.ietf.org/mail= -archive/web/manet/current/msg13305.html) is a good move. In particular that "the LLN needs to be deemphasized as the primary purpose= if adopted as manet". I agree. However http://tools.ietf.org/html/draft-clausen-lln-loadng-05 says in its = introduction that : The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) is a routing protocol, derived from AODV [RFC3561] and extended for use in Lo= w power and Lossy Networks (LLNs). The introduction will be largely changed in the next revision. So, removing LLNs' related material on this draft could get back to AODV wh= ich is already RFC 3561. So what is the improvement ? That is not true. There are many improvements from what we learned from AOD= V, and which has been integrated when designing the protocol (see below) >From what I understand, the LOADng purpose should be a new version of AODV = addressing some of the points suggested by the MANET chair such as "improve= ments in heterogeneity support, simplification where sensible, improved con= trol plane flooding, better IPv6 support, and a eventually clear border gat= eway specification". That is exactly what LOADng does (and that will be clearer in the next revi= sion). It allows for improved flooding (e.g. using SMF/MPR flooding), it ha= s improved IPv6 support, it is more flexible through the use of RFC5444, it= is simplified as several items from AODV (such as iRREP, precursor list) h= ave been removed, it is easier to secure using the security architecture ba= sed on RFC5444/RFC6622 and by avoiding iRREPs. We still need to work in the= clearer border gateway specification. In short : LLNs constraints and challenges should not be adressed by LOADng= , but LOADng could improve the AODV original specification for MANET networ= ks. As one (out of many) use cases are LLNs, experience from these deployments = should be integrated. The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : The LOADng routing protocol was run over UDP and IPv4. Either Ethernet or 802.11 wireless network was used in the test. The description of the participants are in section 4.3 : 1 - LIX ) : It consists of approximately 6000 lines of JAVA code running in a Mac OS environment 2 - Hitachi1) : It consists of 1589 lines of C code running in the Hitachi proprietary micro OS environment embedded in a 16MHz H8 micro processor. 3 - Hitachi2) : It consists of 1987 lines of C++ code running in a Mac OS environment. So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? But since the reactive MANET protocol is a MANET protocol, there will be ma= ny other use cases which we also address in the draft. We have learned from= the experience with AODV (and there is plenty, just Google Scholar for AOD= V), and I think that many of those learnings are integrated already in LOAD= ng. Best regards Ulrich Is my understanding correct ? Best, C=E9dric. Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit : I assume the authors take the guidance from our chair, posted in: http://www.ietf.org/mail-archive/web/manet/current/msg13305.html If so, I do not see a reason not to discuss LOADng. And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings. Teco Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven: Hi, (speaking on my own, not to representing the LOADng authors). As was pointed out before, we often have discussed items that were not WG d= ocuments, usually at the end of the meeting, to make sure that there is eno= ugh time for WG items. I also agree with what Stan said: MANET should not b= e standardizing documents that are mainly focused on LLNs; however, a docum= ent that is focused on MANETS, and as a matter of fact is also used in LLN = deployments should be acceptable, in my opinion. We are currently finalizing some internal discussions between the authors o= f LOADng, and I think that there will be an email to the list on that regar= ds in the next few days. Abdussalam, being against presentation of somethin= g that has not even been proposed yet is premature and pointless, in my opi= nion. Best regards Ulrich On Oct 12, 2012, at 7:15, "Dearlove, Christopher (UK)" > wrote: I think you are in violent agreement. The current LOADng draft is (IIRC) ai= med at LLNs, so Teco is saying unless there's a new MANET-oriented version = it shouldn't be discussed, and you are saying it won't be discussed. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 12 October 2012 15:12 To: Teco Boot Cc: Dearlove, Christopher (UK); > Lis= t; Bo Berry (boberry) Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 12, 2012, at 9:33 AM, Teco Boot wrote: On July 31th, our chair provided guidance on handling LOADng. It shows the way forward. I'm looking forward to an draft-author-manet-loadng-00 draft, submitted bef= ore next Monday. If there is no such draft, and little time to discuss non-wg drafts, we sho= uld not discuss an lln draft in our meeting in Atlanta. One (not too) fine point - we (the MANET WG) will *not* be discussing an LL= N draft. At any time. That would be a charter violation - LLN's are defined= and worked in ROLL. We are discussing MANET reactive protocols. Stan I'm OK on discussions on how to fulfill our charter item on a reactive prot= ocol. Teco Op 12 okt. 2012, om 15:19 heeft Dearlove, Christopher (UK) het volgende ges= chreven: We have often discussed things not yet accepted by the WG, it can be a step= towards getting them accepted. That's not a comment for or against LOADng, discussing LOADng, or adopting = LOADng, just an observation on what has happened in the past. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Bo Berry Sent: 12 October 2012 13:40 To: Abdussalam Baryun; > List; Bo Ber= ry Subject: Re: [manet] MANET meeting at IETF85 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Looking at the MANET WG Documents page, LOADng is not on the list. So until= LOADng is accepted by the WG, gotta agree with Abdussalam, no need to disc= uss it in the little time we have for the work we've already accepted. How does this fit into the WG Charter? -Bo Active Internet-Drafts draft-ietf-manet-dlep-03 Dynamic Link Exchange Protocol (DLEP) draft-ietf-manet-nhdp-mib-19 Definition of Managed Objects for the Neigh= borhood Discovery Protocol draft-ietf-manet-nhdp-sec-02 Using Integrity Check Values and Timestamps= For Router Admittance in NHDP draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol ver= sion 2 draft-ietf-manet-olsrv2-metrics-rationale-01 Link Metrics for the Mobile= Ad Hoc Network (MANET) Routing draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Opt= imized Link State Routing Protocol On Oct 12, 2012, at 7:39 AM, Bo Berry wrote: I've seen a number of emails on the alias but not sure LOADng has been accepted by the WG. Is LOADng asking to be a MANET WG draft? -Bo On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wrote: Please note that I strongly object any including of LOADng draft in the Age= nda. The document is not for MANET, was already presented before, and the authors are not discussing on ietf lists of any progress. The draft is not reasonable for the WG, if it is not discussed on the MANET list. I got no reasonable reply to all my efforts, the last as: http://www.ietf.org/mail-archive/web/manet/current/msg13448.html AB On 10/9/12, Ulrich Herberg = > wrote: Hi, the MANET WG will meet on Wednesday, Nov. 7 from 1pm to 2.30pm in Salon A. If you intend to present something, please send a request to the chairs. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --- We cannot solve our problems with the same thinking we used when we created= them. Albert Einstein _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet C=E9dric CHAUVENET Ph.D Student c.chauvenet@watteco.com Direct Line : +33(0)4 98 01 35 81 Mobile : +33(0)6 30 21 14 91 Standard : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE =96 France www.watteco.com Before printing think about environment and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_484EB252C12E40EC89A90C1ADECD2204wattecocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Le 13 oct. 2012 =E0 22:33, Jiazi YI a =E9crit :

Hi Cedric, 

I think I have answered you this question before in a private mail. 

True. 
We will see what is the feeling of the WG this time.


As long as you asked, let me just repeat it again:

Those are tests aimed for interoperability, not for performance. =

So the main purpose is to:
o V= erify the function/messages exchanges of the protocol, so as to find bugs a= nd improve the specification. 
o M= ake sure that the document is well written such as independent/interoperabl= e implementations can be developed. 

Those tests are to make sure that the protocol can be implemented inde= pendently without consulting the original developers of the protocol. =
So I won't say this interop test is related to the definition of the p= rotocol scope. 

Does it means that these implementations have not been deployed ?

What is your feeling regarding my previous question : "I'm trying= to figure out if LOADng is efficient over a mains-powered computer using W= ifi, a 8K/48K RAM/ROM device,  or both ?"

C=E9dric.

best

Jiazi

On Oct 13, 2012, at 8:16 PM, C Chauvenet <c.chauvenet@watteco.com> wrote:

Hi Ulrich, 

Thank you for your answer, see inline.

Le 13 oct. 2012 =E0 17:33, Ulrich Herberg a =E9crit :

Hi C=E9dric,

On Sat, Oct 13, 2012 at 7:03 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
Hi all, 

I agree with Teco that the message from the chair (http://www.ietf.org/mail-archive/web/manet/current/msg13305.html) is a= good move. 
In particular that "the LLN needs to be deemphasized as the primary purpose if adopted as manet&qu= ot;.


I agree.

 


However http://tools.ietf.org/html/draft-clausen-lln-lo= adng-05 says in its introduction that :

The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next
   Generation (LOADng) is a routing protocol, derived from AODV
   [RFC3561] and extended for use in Low power and Lossy Networks
   (LLNs).


The introduction will be largely changed in the next revision.
 


That is not true. There are many improvements from what we learned fro= m AODV, and which has been integrated when designing the protocol (see belo= w)
 

From what I understand, the LOADng purpose should be a new version of A=
ODV addressing some of the points suggested by the MANET chair such as &quo=
t;improvements in heterogeneity support, simplification where sensible, i=
mproved control plane flooding, better IPv6 support, and a eventually clear=
 border gateway specification".  


That is exactly what LOADng does (and that will be clearer in the next= revision). It allows for improved flooding (e.g. using SMF/MPR flooding), = it has improved IPv6 support, it is more flexible through the use of RFC544= 4, it is simplified as several items from AODV (such as iRREP, precursor list) have been removed, it is easier = to secure using the security architecture based on RFC5444/RFC6622 and by a= voiding iRREPs. We still need to work in the clearer border gateway specifi= cation.

 

In short : LLNs constraints and challenges sh=
ould not be adressed by LOADng, but LOADng could improve the AODV original =
specification for MANET networks.


As one (out of many) use cases are LLNs, experience from these deploym= ents should be integrated.

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).


The LOADng routing protocol was run over UDP and
   IPv4.  Either Ethernet or 802.11 wireless network was used in the
   test.

The description of the participants are in section 4.3 : 
1 - LIX ) : It
      consists of approximately 6000 lines of JAVA code running in a Mac
      OS environment
2 - Hitachi1) : It consists of 1589 l= ines of C
      code running in the Hitachi proprietary micro OS environm=
ent
      embedded in a 16MHz H8 micro processor.
3 - Hitachi2) : It consists of 1987 l= ines of C++ code
      running in a Mac OS environment.

So my first guess is that LOADng is suitable for what I called "m= ains-powered computer using Wifi" ?


But since the reactive MANET protocol is a MANET protocol, there will = be many other use cases which we also address in the draft. We have learned= from the experience with AODV (and there is plenty, just Google Scholar fo= r AODV), and I think that many of those learnings are integrated already in LOADng.

Best regards
Ulrich


 

Is my understanding correct ?

Best,

C=E9dric.

Le 12 oct. 2012 =E0 17:54, Teco Boot a =E9crit :

I assume the authors take the guidance from our chair, posted in:
http://www.ietf.org/mail-archive/web/manet/current/msg1= 3305.html

If so, I do not see a reason not to discuss LOADng.
And yes, I am with Stan we will *not* discuss LLN topics in MANET meetings.=

Teco

Op 12 okt. 2012, om 17:38 heeft Ulrich Herberg het volgende geschreven:

Hi,

(speaking on my own, not to representing the LOAD= ng authors).

As was pointed out before, we often have discusse= d items that were not WG documents, usually at the end of the meeting, to m= ake sure that there is enough time for WG items. I also agree with what Sta= n said: MANET should not be standardizing documents that are mainly focused on LLNs; however, a document that is foc= used on MANETS, and as a matter of fact is also used in LLN deployments sho= uld be acceptable, in my opinion.

We are currently finalizing some internal discuss= ions between the authors of LOADng, and I think that there will be an email= to the list on that regards in the next few days. Abdussalam, being agains= t presentation of something that has not even been proposed yet is premature and pointless, in my opinion.

Best regards
Ulrich

On Oct 12, 2012, at 7:15, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:

I think you are in violent agreement. The current= LOADng draft is (IIRC) aimed at LLNs, so Teco is saying unless there's a n= ew MANET-oriented version it shouldn't be discussed, and you are saying it = won't be discussed.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 12 October 2012 15:12
To: Teco Boot
Cc: Dearlove, Christopher (UK); <manet@ietf.org> List; Bo Berr= y (boberry)
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

On Oct 12, 2012, at 9:33 AM, Teco Boot wrote:

On July 31th, our chair provided guidance on hand= ling LOADng.
It shows the way forward.

I'm looking forward to an draft-author-manet-load= ng-00 draft, submitted before next Monday.
If there is no such draft, and little time to dis= cuss non-wg drafts, we should not discuss an lln draft in our meeting in At= lanta.

One (not too) fine point - we (the MANET WG) will= *not* be discussing an LLN draft. At any time. That would be a charter vio= lation - LLN's are defined and worked in ROLL. We are discussing MANET reac= tive protocols.

Stan


I'm OK on discussions on how to fulfill our chart= er item on a reactive protocol.

Teco


Op 12 okt. 2012, om 15:19 heeft Dearlove, Christo= pher (UK) het volgende geschreven:

We have often discussed things not yet accepted b= y the WG, it can be a step towards getting them accepted.

That's not a comment for or against LOADng, discu= ssing LOADng, or adopting LOADng, just an observation on what has happened = in the past.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capab= ility
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford,= CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farn= borough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Bo Berry
Sent: 12 October 2012 13:40
To: Abdussalam Baryun; <manet@ietf.org> List; Bo Berry
Subject: Re: [manet] MANET meeting at IETF85

----------------------! WARNING ! ---------------= -------
This message originates from outside our organisa= tion,
either from an external partner or from the inter= net.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT = matters
for instructions on reporting suspicious email me= ssages.
-------------------------------------------------= -------

Looking at the MANET WG Documents page, LOADng is= not on the list. So until LOADng is accepted by the WG, gotta agree with A= bdussalam, no need to discuss it in the little time we have for the work we= 've already accepted.

How does this fit into the WG Charter?

-Bo


Active Internet-Drafts
draft-ietf-manet-dlep-03    Dynami= c Link Exchange Protocol (DLEP)    
draft-ietf-manet-nhdp-mib-19    De= finition of Managed Objects for the Neighborhood Discovery Protocol  &= nbsp; 
draft-ietf-manet-nhdp-sec-02    Us= ing Integrity Check Values and Timestamps For Router Admittance in NHDP &nb= sp;  
draft-ietf-manet-olsrv2-16    The = Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-metrics-rationale-01 &nbs= p;  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing
draft-ietf-manet-olsrv2-mib-04    = Definition of Managed Objects for the Optimized Link State Routing Protocol



On Oct 12, 2012, at 7:39 AM, Bo Berry wrote:

I've seen a number of emails on the alias but not= sure LOADng
has been accepted by the WG.  Is LOADng aski= ng to be a MANET WG
draft?

-Bo


On Oct 12, 2012, at 5:34 AM, Abdussalam Baryun wr= ote:

Please note that I strongly object any including = of LOADng draft in the Agenda.
The document is not for MANET, was already presen= ted before, and the
authors are not discussing on ietf lists of any p= rogress. The draft is
not reasonable for the WG, if it is not discussed= on the MANET list.

I got no reasonable reply to all my efforts, the = last as:
http://www.ietf.org/mail-arch= ive/web/manet/current/msg13448.html

AB
On 10/9/12, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

the MANET WG will meet on Wednesday, Nov. 7 from = 1pm to 2.30pm in Salon A.
If you intend to present something, please send a= request to the chairs.

Best regards
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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

---
We cannot solve our problems with the same thinki= ng we used when we created them.
Albert Einstein



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


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

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

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


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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


<image001.jpg>

C=E9dric = CHAUVENET

Ph.D Student

c.chauvenet@watteco.com<= u>

Direct= Line :   +33(0)4 98 01 35 81=
Mobile : &n= bsp;        +33(0)6 30 = 21 14 91

Standard :=    +33(0)4 98 01 60 05

Fax :     = ;        +3= 3(0)4 94 14 10 80
 
1766 Chemin de la Planqu= ette
83130 LA GARDE =96 Franc= e

<image002.gif>

 B= efore printing think about environment and costs
This = Message may contain confidential information intended only for the use of t= he addressee named above. If you are not the intended recipient of this mes= sage you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohib= ited. If you received this message by mistake, please notify the sender by = reply email immediately. Please conduct your own virus checks before openin= g any attachment as Watteco does not guarantee the integrity of this email or attached files has been maint= ained nor this communication is free of viruses, interceptions or interfere= nce. Any views expressed in this message are those of the individual sender= and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for the = improper and incomplete transmission of the information contained in this c= ommunication nor for any delay in its receipt or damage to your system.
=



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


--_000_484EB252C12E40EC89A90C1ADECD2204wattecocom_-- From hrogge@googlemail.com Sat Oct 13 14:18:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9221F844F for ; Sat, 13 Oct 2012 14:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTGs6+DddzsS for ; Sat, 13 Oct 2012 14:18:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3951F21F843F for ; Sat, 13 Oct 2012 14:18:44 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3840687pbb.31 for ; Sat, 13 Oct 2012 14:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=GKpxrTNNm0E9L8SckW0azV5TDMX7Q/4oSNM+fRG5lDw=; b=A/sVqZSR8aVOBWBHPOwUyAGsuf5reA5MFqC0z+mj/KgFkLeXGouv7wlrXAOlAtH7z8 TK3ZXjICV9ghnttSJx8Qi3uavn0a/PNY+au3nwA27q81YLHJfTK5rN+l7qLD89lhpbnn 68y/HMgP5jRJu/9kri/uNTN7VWuFYn/OxI+7TrBQ7tGIK1JcP5GQLxG/JxwKbOgPG+K7 5F3lBDE9aOaL/lBudO1ot1GNAFNIl/FoAxtBRprvh805veM++G7yySux/qOhmnb2wQtx Lx447fi59tbZrmul+5iOUqkIU7d6RspmH9k8Q7IuFk2EYUxnu7sSgVTqgsMxnUK3TmlG ShQA== Received: by 10.66.88.198 with SMTP id bi6mr21439907pab.23.1350163123695; Sat, 13 Oct 2012 14:18:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sat, 13 Oct 2012 14:18:23 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sat, 13 Oct 2012 23:18:23 +0200 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 21:18:45 -0000 Interesting question... the last time we worked on the draft the discussion bogged down with the question if this is the "right way" to do ETX. Maybe a split would be a good idea, we could have an informal document specifying the strategy we are using at Freifunk/Funkfeuer for ETX. And then we could work on how to transform this into a good OLSRv2 metric. Henning Rogge On Sat, Oct 13, 2012 at 5:37 PM, Ulrich Herberg wrote= : > I think this draft is indeed interesting, and I wonder if there is any wo= rk > planned to continue it. It seems to be a bit of a mixture between specify= ing > how to use ETX in OLSRv2, and a deployment experience of ETX with OLSR in > the FunkFeuer network. Is that the right way to go forward, or should tha= t > not better be separated in two drafts? > > Ulrich > > > On Sat, Oct 13, 2012 at 5:41 AM, Abdussalam Baryun > wrote: >> >> I think some people in WG are interested also in Funkfeuer routing >> metric [1], it was mentioned in MANET meeting 84. I hope we will see >> the draft [2] to be accepted as a MANET WG draft shortly for >> informational about Funkfeuer. >> >> AB>suggest for title> >> Packet Sequence Number based ETX Metric for Funkfeuer Networking. >> >> AB> suggest the Abstract> >> This document specifies the ETX metric and its usage in Funkfeuer's >> OLSRv2 Routers. >> >> I recommend to include this draft [2] or a renewal in the Agenda 85, >> if the authors are welling to present it. >> >> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12077.html >> [2] http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 >> >> AB >> ++ >> On 10/12/12, Henning Rogge wrote: >> > On 10/12/2012 09:53 AM, Abdussalam Baryun wrote: >> >> +1 >> >> >> >> It is an excellent draft/work, I support the draft and your process. >> >> Thanks to all: authors, you and the WG, >> > >> > The document will be a great help as a pointer for people who still >> > arguing the use of link metrics. Good to see it here. >> > >> > Henning Rogge >> > >> > >> > -- >> > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> > Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> > Kommunikationssysteme (KOM) >> > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> > Telefon +49 228 9435-961, Fax +49 228 9435 685 >> > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> > >> > >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From yi.jiazi@gmail.com Sat Oct 13 15:01:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C451411E8097 for ; Sat, 13 Oct 2012 15:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHkpOH3E4I9l for ; Sat, 13 Oct 2012 15:01:47 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D3E4211E808D for ; Sat, 13 Oct 2012 15:01:46 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so591590wib.13 for ; Sat, 13 Oct 2012 15:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=z6KYKkFwmuJmmTMGeeJMGX6gIbOAlHInbx1T4BTZAwg=; b=MnYO9Gem2M+2BQJWiLYKVAkZtP/eUNEqaGtfNFokjCHb9FasNHzkSSA+UZrRcbFxG9 KP7FnixnEQGviCT4ufn59QQ8L5nfi8BRNrXwzYmj1xdGHwLEWsBXNviBQBxaJ/5n0PgU EqFzN4RkTxnFP4fQx3QhT7roLKpA345Fz4301Taaf+eX2eeuRyg6F5N8rBGbQLvL1wzC PmjIlTuudePrKdzCtSxlj9T9y7baJDR9RvWDyXyuAIN0CbSrrnUlzmykNaxh+TS/t/nY gve0Z0HcKCcuN4IcxwDtg93yilvyWSKL3ikiStAICvq/I+LprGlGACeIdAAQuMcgVeAr H1/A== Received: by 10.216.45.144 with SMTP id p16mr4830362web.170.1350165705930; Sat, 13 Oct 2012 15:01:45 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id v3sm6024673wiy.5.2012.10.13.15.01.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 15:01:45 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_510B97EB-86DD-4090-9D3A-ABD84D0256DA" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <484EB252-C12E-40EC-89A9-0C1ADECD2204@watteco.com> Date: Sun, 14 Oct 2012 00:01:42 +0200 Message-Id: <2A02C7BE-DF41-4723-9B37-806F15863EE5@jiaziyi.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <107E45B2-4159-4AE0-B7E9-98BBAE657AD3@gmail.com> <484EB252-C12E-40EC-89A9-0C1ADECD2204@watteco.com> To: C Chauvenet , "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1499) Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 22:01:47 -0000 --Apple-Mail=_510B97EB-86DD-4090-9D3A-ABD84D0256DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Cedric, dear JP > Would you mind sharing the level of interop testing ? I'm not sure what does the *level* mean exactly here.=20 Currently, all the information available is already in the draft. If you = have any other questions, please provide your comments. We will include = them in the new revision, if possible.=20 >> Those tests are to make sure that the protocol can be implemented = independently without consulting the original developers of the = protocol.=20 >> So I won't say this interop test is related to the definition of the = protocol scope.=20 >=20 > Does it means that these implementations have not been deployed ? Some of them (not all) have been deployed.=20 >=20 > What is your feeling regarding my previous question : "I'm trying to = figure out if LOADng is efficient over a mains-powered computer using = Wifi, a 8K/48K RAM/ROM device, or both ?" My feeling is both.=20 btw, I don't why we are having this discussion in this session.=20 For the moment, the LOADng authors neither submitted a new revision, nor = requested a slot in the WG meeting (yet).=20 I'm feeling kind of pointless to have this discussion now.=20 The comments from the WG would be seriously considered in the next = revision of the drafts. The authors would appreciate your comments when = the new revision is released.=20 best Jiazi= --Apple-Mail=_510B97EB-86DD-4090-9D3A-ABD84D0256DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear Cedric, dear JP

Would you mind = sharing the level of interop testing ?
I'm not sure = what does the *level* mean exactly = here. 

Currently, all the information = available is already in the draft. If you have any other questions, = please provide your comments. We will include them in the new revision, = if possible. 

Those tests are to make sure that the = protocol can be implemented independently without consulting the = original developers of the protocol. 
So I won't say this = interop test is related to the definition of the protocol = scope. 

Does= it means that these implementations have not been deployed = ?

Some of them (not all) have been = deployed. 


What is your feeling regarding my = previous question : "I'm trying to figure out if LOADng is efficient = over a mains-powered computer using Wifi, a 8K/48K RAM/ROM device, =  or both = ?"

My feeling is = both. 

btw, I don't why we are having this = discussion in this session. 
For the moment, the LOADng = authors neither submitted a new revision, nor requested a slot in the WG = meeting (yet). 
I'm feeling kind of pointless to have = this discussion now. 
The comments from the WG would be = seriously considered in the next revision of the drafts. The authors = would appreciate your comments when the new revision is = released. 

best

Jia= zi
= --Apple-Mail=_510B97EB-86DD-4090-9D3A-ABD84D0256DA-- From jpmacker@gmail.com Sat Oct 13 15:57:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF3511E8097 for ; Sat, 13 Oct 2012 15:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNXm+Sy7B7wv for ; Sat, 13 Oct 2012 15:57:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFB0D11E8091 for ; Sat, 13 Oct 2012 15:57:33 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4617265vbb.31 for ; Sat, 13 Oct 2012 15:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RQjxigN6EJ9K8Ugk/U83FLv6SAkHm9E6SdnQZquZU34=; b=O9IMERH/LfESSmBmR8flvTYYbd3yUNAZqBVrKcP30w/7q1BXLNIgJsvyq2wSnVjB3h MHRS2GuyF2uRKGNKuYa8uWJhEKlT2n3HMn3/o/YzlbXeR0Rbf7N32qaR44hg20+OaJWH YYaAAY67xqY3XZOGJu/U+7c301pD59Z6DHmDw1RCEIlnLFD+ZNnXigtkTHAA2t5ompbI jUoTh+MaPx8WjrXTH1XNVsF1HoS0FQSjL2qadVk9FVVm7HrmMb3GlsbEVkApeXDuXrVp VW7EI3ljtZymTGUf1u1nf4yd7d/N3Z4GvzXBWR2jnvxwIZaPsIca+k7+SyLafB+iD9k+ wrSw== MIME-Version: 1.0 Received: by 10.52.91.204 with SMTP id cg12mr3671101vdb.98.1350169052949; Sat, 13 Oct 2012 15:57:32 -0700 (PDT) Received: by 10.59.5.6 with HTTP; Sat, 13 Oct 2012 15:57:32 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Oct 2012 18:57:32 -0400 Message-ID: From: Joseph Macker To: Henning Rogge Content-Type: multipart/alternative; boundary=20cf307ac4e5c9ae2404cbf8ba18 Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 22:57:35 -0000 --20cf307ac4e5c9ae2404cbf8ba18 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Henning: I remember similar offline discussion in Paris related to this and whether it would be a good idea to split out. This would be a good agenda item discussion in my opinion also. -Joe On Sat, Oct 13, 2012 at 5:18 PM, Henning Rogge wrote= : > Interesting question... the last time we worked on the draft the > discussion bogged down with the question if this is the "right way" to > do ETX. > > Maybe a split would be a good idea, we could have an informal document > specifying the strategy we are using at Freifunk/Funkfeuer for ETX. > And then we could work on how to transform this into a good OLSRv2 > metric. > > Henning Rogge > > On Sat, Oct 13, 2012 at 5:37 PM, Ulrich Herberg > wrote: > > I think this draft is indeed interesting, and I wonder if there is any > work > > planned to continue it. It seems to be a bit of a mixture between > specifying > > how to use ETX in OLSRv2, and a deployment experience of ETX with OLSR = in > > the FunkFeuer network. Is that the right way to go forward, or should > that > > not better be separated in two drafts? > > > > Ulrich > > > > > > On Sat, Oct 13, 2012 at 5:41 AM, Abdussalam Baryun > > wrote: > >> > >> I think some people in WG are interested also in Funkfeuer routing > >> metric [1], it was mentioned in MANET meeting 84. I hope we will see > >> the draft [2] to be accepted as a MANET WG draft shortly for > >> informational about Funkfeuer. > >> > >> AB>suggest for title> > >> Packet Sequence Number based ETX Metric for Funkfeuer Networking. > >> > >> AB> suggest the Abstract> > >> This document specifies the ETX metric and its usage in Funkfeuer's > >> OLSRv2 Routers. > >> > >> I recommend to include this draft [2] or a renewal in the Agenda 85, > >> if the authors are welling to present it. > >> > >> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12077.html > >> [2] http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 > >> > >> AB > >> ++ > >> On 10/12/12, Henning Rogge wrote: > >> > On 10/12/2012 09:53 AM, Abdussalam Baryun wrote: > >> >> +1 > >> >> > >> >> It is an excellent draft/work, I support the draft and your process= . > >> >> Thanks to all: authors, you and the WG, > >> > > >> > The document will be a great help as a pointer for people who still > >> > arguing the use of link metrics. Good to see it here. > >> > > >> > Henning Rogge > >> > > >> > > >> > -- > >> > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> > Kommunikationssysteme (KOM) > >> > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> > Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.d= e > >> > > >> > > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307ac4e5c9ae2404cbf8ba18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Henning:

I remember similar offline discussion in Paris related to t= his and whether it would be a good idea to split out.=A0 This would be=A0 a= good agenda item discussion in my opinion also.

-Joe


On Sat, Oct 13, 2012 at 5:18 PM, Henning Rogge <hrogge@googlemail.com<= /a>> wrote:
Interesting question... the last time we worked on the draft the
discussion bogged down with the question if this is the "right way&quo= t; to
do ETX.

Maybe a split would be a good idea, we could have an informal document
specifying the strategy we are using at Freifunk/Funkfeuer for ETX.
And then we could work on how to transform this into a good OLSRv2
metric.

Henning Rogge

On Sat, Oct 13, 2012 at 5:37 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
> I think this draft is indeed interesting, and I wonder if there is any= work
> planned to continue it. It seems to be a bit of a mixture between spec= ifying
> how to use ETX in OLSRv2, and a deployment experience of ETX with OLSR= in
> the FunkFeuer network. Is that the right way to go forward, or should = that
> not better be separated in two drafts?
>
> Ulrich
>
>
> On Sat, Oct 13, 2012 at 5:41 AM, Abdussalam Baryun
> <abdussalambaryun@gma= il.com> wrote:
>>
>> I think some people in WG are interested also in Funkfeuer routing=
>> metric [1], it was mentioned in MANET meeting 84. I hope we will s= ee
>> the draft [2] to be accepted as a MANET WG draft shortly for
>> informational about Funkfeuer.
>>
>> AB>suggest for title>
>> Packet Sequence Number based ETX Metric for Funkfeuer =A0Networkin= g.
>>
>> AB> suggest the Abstract>
>> This document specifies the ETX metric and its usage in Funkfeuer&= #39;s
>> OLSRv2 Routers.
>>
>> I recommend to include this draft [2] or a renewal in the Agenda 8= 5,
>> if the authors are welling to present it.
>>
>> [1] http://www.ietf.org/mail-archive/web/manet= /current/msg12077.html
>> [2] http://tools.ietf.org/html/draft-funkfeuer-m= anet-olsrv2-etx-01
>>
>> AB
>> ++
>> On 10/12/12, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
>> > On 10/12/2012 09:53 AM, Abdussalam Baryun wrote:
>> >> +1
>> >>
>> >> It is an excellent draft/work, I support the draft and yo= ur process.
>> >> Thanks to all: authors, you and the WG,
>> >
>> > The document will be a great help as a pointer for people who= still
>> > arguing the use of link metrics. Good to see it here.
>> >
>> > Henning Rogge
>> >
>> >
>> > --
>> > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=
>> > Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> > Kommunikationssysteme (KOM)
>> > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> > Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
>> > mailto:he= nning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>> >
>> >
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>



--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_____________________= __________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307ac4e5c9ae2404cbf8ba18-- From hrogge@googlemail.com Sat Oct 13 17:07:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7017421F8498 for ; Sat, 13 Oct 2012 17:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+jTRnU5mMqg for ; Sat, 13 Oct 2012 17:07:39 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0B221F847C for ; Sat, 13 Oct 2012 17:07:39 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3799714pad.31 for ; Sat, 13 Oct 2012 17:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=oet4ityUNSTf+A04spBawA9T+Y468QRNL8nMLuMByM0=; b=vyO3uyVuoRh+IG+bwpScnFacDbQzUJQoAeogaSJTBzl3+oB1KnY6/aTHX/M56zaSCW Q5TA4Q8VWHLU0Y9Jo9rmhy+e+fCBF+0stkX9gDEiAC3ljiZs0UU+XhwU+eqKAFVLsh6Q 3tCp1Xm3QwNGVIMOposGh9KyoGeA+h86+SVOyBVL7B0leYTv92rlzLpFnKGfiST8wAiS KGM/5NaU+uxS4GuC8CyLP4xIlivEuTh9DECUxSojMBe3KCE2S90yRT0iKlQQG2+uVAoo 53Je9JuVu8vEg8iJlXxpl+h+YTMK1Bjd+/6+wCjLNBcGSPmhj7+EiKFJ+VNeAKGbl9bi dvsQ== Received: by 10.68.221.166 with SMTP id qf6mr25304896pbc.54.1350173258896; Sat, 13 Oct 2012 17:07:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sat, 13 Oct 2012 17:07:18 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sun, 14 Oct 2012 02:07:18 +0200 Message-ID: To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 00:07:40 -0000 I will not be able to attend the coming IETF. Henning Rogge On Sun, Oct 14, 2012 at 12:57 AM, Joseph Macker wrote: > Henning: > > I remember similar offline discussion in Paris related to this and whethe= r > it would be a good idea to split out. This would be a good agenda item > discussion in my opinion also. > > -Joe > > > > On Sat, Oct 13, 2012 at 5:18 PM, Henning Rogge > wrote: >> >> Interesting question... the last time we worked on the draft the >> discussion bogged down with the question if this is the "right way" to >> do ETX. >> >> Maybe a split would be a good idea, we could have an informal document >> specifying the strategy we are using at Freifunk/Funkfeuer for ETX. >> And then we could work on how to transform this into a good OLSRv2 >> metric. >> >> Henning Rogge >> >> On Sat, Oct 13, 2012 at 5:37 PM, Ulrich Herberg >> wrote: >> > I think this draft is indeed interesting, and I wonder if there is any >> > work >> > planned to continue it. It seems to be a bit of a mixture between >> > specifying >> > how to use ETX in OLSRv2, and a deployment experience of ETX with OLSR >> > in >> > the FunkFeuer network. Is that the right way to go forward, or should >> > that >> > not better be separated in two drafts? >> > >> > Ulrich >> > >> > >> > On Sat, Oct 13, 2012 at 5:41 AM, Abdussalam Baryun >> > wrote: >> >> >> >> I think some people in WG are interested also in Funkfeuer routing >> >> metric [1], it was mentioned in MANET meeting 84. I hope we will see >> >> the draft [2] to be accepted as a MANET WG draft shortly for >> >> informational about Funkfeuer. >> >> >> >> AB>suggest for title> >> >> Packet Sequence Number based ETX Metric for Funkfeuer Networking. >> >> >> >> AB> suggest the Abstract> >> >> This document specifies the ETX metric and its usage in Funkfeuer's >> >> OLSRv2 Routers. >> >> >> >> I recommend to include this draft [2] or a renewal in the Agenda 85, >> >> if the authors are welling to present it. >> >> >> >> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12077.html >> >> [2] http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 >> >> >> >> AB >> >> ++ >> >> On 10/12/12, Henning Rogge wrote: >> >> > On 10/12/2012 09:53 AM, Abdussalam Baryun wrote: >> >> >> +1 >> >> >> >> >> >> It is an excellent draft/work, I support the draft and your proces= s. >> >> >> Thanks to all: authors, you and the WG, >> >> > >> >> > The document will be a great help as a pointer for people who still >> >> > arguing the use of link metrics. Good to see it here. >> >> > >> >> > Henning Rogge >> >> > >> >> > >> >> > -- >> >> > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> >> > Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> >> > Kommunikationssysteme (KOM) >> >> > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> >> > Telefon +49 228 9435-961, Fax +49 228 9435 685 >> >> > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.= de >> >> > >> >> > >> >> _______________________________________________ >> >> manet mailing list >> >> manet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> > >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> > >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Sat Oct 13 18:13:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C371F041F for ; Sat, 13 Oct 2012 18:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDltJBGBwN6I for ; Sat, 13 Oct 2012 18:13:34 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D418A1F041C for ; Sat, 13 Oct 2012 18:13:33 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5169400vcb.31 for ; Sat, 13 Oct 2012 18:13:33 -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=hu6sVN3oVzEa6tZKbjYUtOdn3HObsJhubCOQyXE7h3Q=; b=15tSO1Fi3wQNlqN+3ZwfZyfMEehH+T5+vpaEWp6J/naZA27WKLhfIiJtS519/LZ9Eo UHFai6TnDPh7U/W1YTE6b3XIcDixfbKhrKbF9uqcbo8Hwfxji/RYvoY5zPJlOslrlxIm ro3LW8PkzW9T0cdeJFfAZBL1yq4yjUPUJgddA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hu6sVN3oVzEa6tZKbjYUtOdn3HObsJhubCOQyXE7h3Q=; b=i8bjBg3AUVim1vkVGUYJXbRD+iPQP9HkREiJ3QskRAmt+G0Yuj3GgOVDpJevGQ3ddN oVQaGkBpAYblvH4RqYw16hBY9lB9KQYUdpkJCvWZC9PY+M7OrKtROgIG+Mzhv5myFPr0 ILpVUJALsJmhmNG5iDWx5Ieu9tzmhHV8qNV7XhOjoMq7YuQKtBic7jlUtoJjTppviCEV 37lPqt8HaFenAjge+/F1QxyrUzSWyLf4p8o+2bBH1+sHzQEMKatCLA0LxaR517fyYDQw t0rBLNzvOpWLPQSZhudFhTbXTkKNBTTLACNJog9bkgC4vkCSvNDgi0dH1+SHQ6y1Uq+s IgUg== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr3861269vdv.20.1350177213331; Sat, 13 Oct 2012 18:13:33 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Sat, 13 Oct 2012 18:13:33 -0700 (PDT) In-Reply-To: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> Date: Sat, 13 Oct 2012 18:13:33 -0700 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: multipart/alternative; boundary=bcaec50162bd2f3ac904cbfaa152 X-Gm-Message-State: ALoCoQm3UOgsgeYVZQraoTnXRHz/RRqkVLgUX6Ud7/zIstMtedGbxMpV3T9mZgi0gHPstvZf2kUo Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 01:13:35 -0000 --bcaec50162bd2f3ac904cbfaa152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi C=E9dric, On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet wrot= e: > [...] > > > The distinction between MANET and LLNs seems to be vanish here. > This brings us back to the summer discussion between what is a MANET and > what is a LLN that did not really fostered on a consensus. > WG chairs could help there, as it is their related scope. > I am not suggesting to revive a discussion of the definition of a MANET vs LLN. I did not bring up this discussion. All I am saying is that MANET is chartered to come up with a reactive protocol. And I believe it should be allowed to mention where a protocol is used in deployments. > My vision is that LLNs are more constrained than MANET for the following > criterion : Power consumption, Loss of the media, Computation capability, > Throughput. > What do you think ? > My vision is also that the level of constraints of LLNs should not be > considered in a MANET protocol. > Do you agree ? > Since you ask here...In my personal opinion, LLNs are a 100% subset of a MANET. Both are usually multi-hop, often wireless, with constrained routers, in many cases incoming packets leave a router on the same interface that they have been received on, and the topology is dynamic. MANETs, IMO, have a larger range of "constrained routers", from very constrained routers (e.g. LLN) to somewhat constrained routers (e.g. community networks) to non-constrained routers (e.g. certain military deployments). LLN is focused on extremely constrained devices. However, I don't say that we should revisit the way how the Routing Area distributed the tasks in the WGs, nor do I suggest to change the charters. > > I'm trying to figure out if LOADng is efficient over a mains-powered > computer using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide > range would be magical !). > I cannot answer this question, as I have not deployed LOADng on a 8K/48K RAM/ROM device. Those who have deployments and are willing to disclose details, may have more details. Just one comment: I have implemented numerous ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest to implement and has the least lines of code (by far) compared to all these other protocols that I have implemented. If you can run any of these beforementioned protocols on such a device, you can certainly run LOADng on it. > > I see in the interop report > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repor= t-02 in > section 3 : > > [...] > > So my first guess is that LOADng is suitable for what I called > "mains-powered computer using Wifi" ? > I think Jiazi has already replied to that in a later mail. Interop !=3D performance test. LOADng (like any other MANET protocol) can run on any medium. Testing it on wifi is a simple thing to do. Interop tests are solely to find out if messages can be parsed correctly, and if the implementations behave according to the specification. As Jiazi pointed out correctly, I don't understand why we have this discussion before you have seen the latest LOADng revision. Best Ulrich --bcaec50162bd2f3ac904cbfaa152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi C=E9dric,

On Sat, Oct 13, 2012 at 11:1= 6 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:
=
[...]

The distinction between MANET and LLNs seems to be vanish here.<= /div>
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.
<= /div>


I am not suggest= ing to revive a discussion of the definition of a MANET vs LLN. I did not b= ring up this discussion. All I am saying is that MANET is chartered to come= up with a reactive protocol. And I believe it should be allowed to mention= where a protocol is used in deployments.=A0


=A0
=
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?


Since you ask here...In my personal opinion, =A0LLNs are a = 100% subset of a MANET. Both are usually multi-hop, often wireless, with co= nstrained routers, in many cases incoming packets leave a router on the sam= e interface that they have been received on, and the topology is dynamic. M= ANETs, IMO, have a larger range of "constrained routers", from ve= ry constrained routers (e.g. LLN) to somewhat constrained routers (e.g. com= munity networks) to non-constrained routers (e.g. certain military deployme= nts). LLN is focused on extremely constrained devices.
However, I don't say that we should revisit the way how the Routin= g Area distributed the tasks in the WGs, nor do I suggest to change the cha= rters.


=A0

I'm trying to figure out if LOADng is efficient over a mains-power= ed computer using Wifi, a 8K/48K RAM/ROM device, =A0or both (cover such a w= ide range would be magical !).

I cannot answer this question, as I have not deployed LOADng= on a 8K/48K RAM/ROM device. Those who have deployments and are willing to = disclose details, may have more details. Just one comment: I have implement= ed numerous ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by= far the simplest to implement and has the least lines of code (by far) com= pared to all these other protocols that I have implemented. If you can run = any of these beforementioned protocols on such a device, you can certainly = run LOADng on it.

=A0

[...]
So my first guess is that LOADng is suitable for what I called "m= ains-powered computer using Wifi" ?


I think Jiazi has already replie= d to that in a later mail. Interop !=3D performance test. LOADng (like any = other MANET protocol) can run on any medium. Testing it on wifi is a simple= thing to do. Interop tests are solely to find out if messages can be parse= d correctly, and if the implementations behave according to the specificati= on.=A0

As Jiazi pointed out correctly, I don't understand = why we have this discussion before you have seen the latest LOADng revision= .=A0

Best
Ulrich
=A0
--bcaec50162bd2f3ac904cbfaa152-- From ulrich@herberg.name Sat Oct 13 18:16:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916C221F845A for ; Sat, 13 Oct 2012 18:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXyZe1UxdX12 for ; Sat, 13 Oct 2012 18:16:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E253621F8458 for ; Sat, 13 Oct 2012 18:16:01 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5170204vcb.31 for ; Sat, 13 Oct 2012 18:16:01 -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=ntCYl+o451mZ7lf64Q1uV/zfCcFlyOgaNm8kyhuaDxU=; b=1wpkOWitM+1qggfJkP0E3vOmt2fxxH/DLF0fADbHLN7sPLzk0Ft1S4is1dXCudUYDd IEJ0A2vYKpV82sa3K2eqcMru9qvq0PMbSQR6kUVB+CIzBt1TOMKHVfI/M9nsYCvr+uu+ YRNDvx+CWlvSXczTCAen5PAGgWKPQdwqcAN5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ntCYl+o451mZ7lf64Q1uV/zfCcFlyOgaNm8kyhuaDxU=; b=mbchjHMU39DCRmHpWZ/9UyNZvm3ziAZxnjQXKcxfSlZxCM6lRIhXRZIVqE7VDV9bSO 7Ibu+plBJ/9WgdttVRJKLoHMffAeZb9XR2iev3yOY2d+MJrVkzCJ1fXqI4/BuKaqh2eZ utYqBFE+wdqU3Op2Phzt/KyB64j1Pod/YbmUyEY3Sgv1vifhiGGOeS7lvK/llld4inys KdW09syKbksXeKneNU/XA763dmRYNmfGL5LVwPzCk8NHeKmenjmS+1qz6MTsGi++JA+U IEXBJgr/m51HHojTXDNhiHZGlqyQZZu68QWFW9kCyotcb24GyePsgSL/4e6Ke7a0DPFJ yUkw== MIME-Version: 1.0 Received: by 10.52.67.44 with SMTP id k12mr3792640vdt.15.1350177361364; Sat, 13 Oct 2012 18:16:01 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Sat, 13 Oct 2012 18:16:01 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> Date: Sat, 13 Oct 2012 18:16:01 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=20cf307abeb502068b04cbfaaa14 X-Gm-Message-State: ALoCoQm5gYD3MdVF/2YQvJeujKJz8N3HpP4ykMGLktNfrH2eOIrNF+R9tT0rvW4EN+2mYyYuMI03 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 01:16:02 -0000 --20cf307abeb502068b04cbfaaa14 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur) wrote: > [...] > I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, if > we come up with a MANET reactive protocol, it is only logical that for some > LLNs the reactive MANET protocol would be suitable as well; but clearly, > MANET should cover the general case of MANETs. > > > JP> So in this case, I would suggest to explicitly exclude all LLNs > coverage from the Load ID, and have it covered in ROLL. Does that make > sense ? > I don't understand what you are saying here. That has not been proposed anywhere in this discussion. [...] > Right, and I don't see why there would be overlap. > > > JP> As long as you agree with the previous statement, we're fine. > > Good. Best Ulrich --20cf307abeb502068b04cbfaaa14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,

On Sat, Oct 13, 2012 at 9:48 AM, J= P Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
[...]
I repeat what Adrian said: some if not all LLNs are MANETs. Therefore,= if we come up with a MANET reactive protocol, it is only logical that for = some LLNs the reactive MANET protocol would be suitable as well; but clearl= y, MANET should cover the general case of MANETs.

JP> So in this case, I would suggest to explicitly exclude al= l LLNs coverage from the Load ID, and have it covered in ROLL. Does that ma= ke sense ?


I don't understand what you are saying here. That has not be= en proposed anywhere in this discussion.


=A0[...]
Right, and I don't see why there would be overlap.

JP> As long as you agree with the previous statement, we'= re fine.


Good.

Best
Ulrich=A0

--20cf307abeb502068b04cbfaaa14-- From jvasseur@cisco.com Sat Oct 13 23:58:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19ACB21F84A1 for ; Sat, 13 Oct 2012 23:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNrGE-arQX8z for ; Sat, 13 Oct 2012 23:58:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3D17C21F8466 for ; Sat, 13 Oct 2012 23:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4613; q=dns/txt; s=iport; t=1350197914; x=1351407514; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7K3XpuwPAnmt0LX3p0695/pal55EoA2ng3WjPzj3TIM=; b=CABtto7zqz6NKmc/Col5BGkL5tmVqtgXITZosYwXqZ8BajxWNvnIzVl4 CmTPPkAY/IneVFNwE6KAC1bfpGNRPSc4PAqMo0hUqUMJQuAahEALa1uZt CnC1rT9GlmRC2WP4pVCGBBsOYYqy00OoYtTR6bNmzWLydJS1C+BZA/yOG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAO9helCtJXHA/2dsb2JhbAA/Br9wgQiCIQEBBBIBZhACAQgEHh0HMhQRAgQOBQgah2KdJp8Hi1kmhTdgA4gjnA6Ba4Jtghc X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208,217";a="131147246" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 14 Oct 2012 06:58:32 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9E6wWrP019932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 06:58:32 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 01:58:32 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqVmoxQdayxYbx0aw5eRdXfbe8w== Date: Sun, 14 Oct 2012 06:58:31 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD992C@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--38.305900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FD992Cxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 06:58:40 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FD992Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote: Hi JP, On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur) > wrote: [...] I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, if w= e come up with a MANET reactive protocol, it is only logical that for some = LLNs the reactive MANET protocol would be suitable as well; but clearly, MA= NET should cover the general case of MANETs. JP> So in this case, I would suggest to explicitly exclude all LLNs coverag= e from the Load ID, and have it covered in ROLL. Does that make sense ? I don't understand what you are saying here. That has not been proposed any= where in this discussion. JP> All I am saying here is that the chairs agreed to avoid overlap, not un= usual at the IETF. Since ROLLE is covering LLNs (that's *the* charter), and= we will not cover other types of network that are MANET but not LLNs, the future reacti= ve protocol designed by MANET should explicitly not cover LLNs. This will a= void overlaps. [...] Right, and I don't see why there would be overlap. JP> As long as you agree with the previous statement, we're fine. Good. Best Ulrich --_000_03B78081B371D44390ED6E7BADBB4A7721FD992Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote:

Hi JP,

On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
[...]
I repeat what Adrian said: some if not all LLNs are MANETs. Therefore,= if we come up with a MANET reactive protocol, it is only logical that for = some LLNs the reactive MANET protocol would be suitable as well; but clearl= y, MANET should cover the general case of MANETs.

JP> So in this case, I would suggest to explicitly exclude all LLNs= coverage from the Load ID, and have it covered in ROLL. Does that make sen= se ?


I don't understand what you are saying here. That has not been propose= d anywhere in this discussion.


JP> All I am saying here is that the chairs agreed to avoid overlap= , not unusual at the IETF. Since ROLLE is covering LLNs (that's *the* chart= er), and we will not
cover other types of network that are MANET but not LLNs, the future r= eactive protocol designed by MANET should explicitly not cover LLNs. This w= ill avoid overlaps.


 [...]
Right, and I don't see why there would be overlap.

JP> As long as you agree with the previous statement, we're fine.


Good.

Best
Ulrich 


--_000_03B78081B371D44390ED6E7BADBB4A7721FD992Cxmbrcdx02ciscoc_-- From jvasseur@cisco.com Sun Oct 14 00:07:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4FF21F84D6 for ; Sun, 14 Oct 2012 00:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v32G2ItULXSX for ; Sun, 14 Oct 2012 00:07:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 51CE321F84B2 for ; Sun, 14 Oct 2012 00:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12444; q=dns/txt; s=iport; t=1350198445; x=1351408045; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3WQ9A2dqWGEcyd1jxhR6dM9+6/LUEnGhl2qRkKYOEwA=; b=Wz1xMrYJGWkC4l3+Oi4o0js0JH5SmbSlQ8N2yYNlKizswDfq3xAWC2IP WmsCdNATABO5Vd/vnB9P7RL9+o8JWKL+IfAjM7gr5tBOC9RZjxKit2VeQ 2IKvA7wWxHvoXEEDDahqpL7X0ppdpVojugJwXOriyo2M1X0zEkBaBaPIx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAPxjelCtJXG+/2dsb2JhbABFtxEBiF6BCIIhAQEEAQEBDwFbAgkQAgEIIh0HJwsUEQIEDgUIDAUJh2ILnRufBotZGgGFQmADlwGNMIFrgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208,217";a="131369088" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 14 Oct 2012 07:07:24 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9E77O9n007853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 07:07:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 02:07:23 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Sun, 14 Oct 2012 07:07:23 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--40.749700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FD99E1xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 07:07:26 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FD99E1xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: Hi C=E9dric, On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet > wrote: [...] The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. I am not suggesting to revive a discussion of the definition of a MANET vs = LLN. JP> Mei neither - this is why, if you suggest to indicate the applicability= of the protocol in the document which makes total sense, the WG should exc= lude LLNs from this ID explicitly. I did not bring up this discussion. All I am saying is that MANET is charte= red to come up with a reactive protocol. And I believe it should be allowed= to mention where a protocol is used in deployments. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? Since you ask here...In my personal opinion, LLNs are a 100% subset of a M= ANET. Both are usually multi-hop, often wireless, with constrained routers,= in many cases incoming packets leave a router on the same interface that t= hey have been received on, and the topology is dynamic. JP> Well, in this case, pushing your reasoning a bit further, this may very= well apply to OSPF, ISIS, =85 too. I clearly do not think that LLNs are 100% subset of MANET; there is a treme= ndous difference between several dozens of highly constrained fixed routers= interconnected by very lossy links providing a few KBits/s and several hundreds of routers= with high mobility interconnected by Wifi links. MANETs, IMO, have a larger range of "constrained routers", from very constr= ained routers (e.g. LLN) to somewhat constrained routers (e.g. community ne= tworks) to non-constrained routers (e.g. certain military deployments). LLN= is focused on extremely constrained devices. However, I don't say that we should revisit the way how the Routing Area di= stributed the tasks in the WGs, nor do I suggest to change the charters. JP> IF that were the case, we would not have formed two WG but one. I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I cannot answer this question, as I have not deployed LOADng on a 8K/48K RA= M/ROM device. Those who have deployments and are willing to disclose detail= s, may have more details. Just one comment: I have implemented numerous ad-= hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simple= st to implement and has the least lines of code (by far) compared to all th= ese other protocols that I have implemented. If you can run any of these be= forementioned protocols on such a device, you can certainly run LOADng on i= t. JP> I wish life was so simple =85 The argument around simplicity is a recur= ring one. And unfortunately, simple protocols do not always WORK =85 I coul= d actually show you, taking real-life networks (no simulation), how a (simple) reactive rou= ting protocol would break in a LLN. I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : [...] So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? I think Jiazi has already replied to that in a later mail. Interop !=3D per= formance test. LOADng (like any other MANET protocol) can run on any medium= . Testing it on wifi is a simple thing to do. Interop tests are solely to f= ind out if messages can be parsed correctly, and if the implementations beh= ave according to the specification. As Jiazi pointed out correctly, I don't understand why we have this discuss= ion before you have seen the latest LOADng revision. Best Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FD99E1xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote:

Hi C=E9dric,

On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
[...]

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.


I am not suggesting to revive a discussion of the definition of a MANE= T vs LLN.

JP> Mei neither - this is why, if you suggest to indicate the appli= cability of the protocol in the document which makes total sense, the WG sh= ould exclude LLNs from
this ID explicitly.

I did not bring up this discussion. All I am saying is that MANET is c= hartered to come up with a reactive protocol. And I believe it should be al= lowed to mention where a protocol is used in deployments. 


 
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?


Since you ask here...In my personal opinion,  LLNs are a 100% sub= set of a MANET. Both are usually multi-hop, often wireless, with constraine= d routers, in many cases incoming packets leave a router on the same interf= ace that they have been received on, and the topology is dynamic.

JP> Well, in this case, pushing your reasoning a bit further, this = may very well apply to OSPF, ISIS, =85 too.
I clearly do not think that LLNs are 100% subset of MANET; there is a = tremendous difference between several dozens of highly constrained fixed ro= uters interconnected
by very lossy links providing a few KBits/s and several hundreds of ro= uters with high mobility interconnected by Wifi links.

MANETs, IMO, have a larger range of "constrained routers", f= rom very constrained routers (e.g. LLN) to somewhat constrained routers (e.= g. community networks) to non-constrained routers (e.g. certain military de= ployments). LLN is focused on extremely constrained devices.
However, I don't say that we should revisit the way how the Routing Ar= ea distributed the tasks in the WGs, nor do I suggest to change the charter= s.


JP> IF that were the case, we would not have formed two WG but one.=


 

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).

I cannot answer this question, as I have not deployed LOADng on a 8K/4= 8K RAM/ROM device. Those who have deployments and are willing to disclose d= etails, may have more details. Just one comment: I have implemented numerou= s ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest to implement and has the le= ast lines of code (by far) compared to all these other protocols that I hav= e implemented. If you can run any of these beforementioned protocols on suc= h a device, you can certainly run LOADng on it.

JP> I wish life was so simple =85 The argument around simplicity is= a recurring one. And unfortunately, simple protocols do not always WORK = =85 I could actually show
you, taking real-life networks (no simulation), how a (simple) reactiv= e routing protocol would break in a LLN.


 


I think Jiazi has already replied to that in a later mail. Interop != =3D performance test. LOADng (like any other MANET protocol) can run on any= medium. Testing it on wifi is a simple thing to do. Interop tests are sole= ly to find out if messages can be parsed correctly, and if the implementations behave according to the specificatio= n. 

As Jiazi pointed out correctly, I don't understand why we have this di= scussion before you have seen the latest LOADng revision. 

Best
Ulrich
 
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7721FD99E1xmbrcdx02ciscoc_-- From teco@inf-net.nl Sun Oct 14 00:07:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F5921F84EF for ; Sun, 14 Oct 2012 00:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQuUVY+F7vzW for ; Sun, 14 Oct 2012 00:07:37 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB9D21F84EB for ; Sun, 14 Oct 2012 00:07:36 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2361879wgb.13 for ; Sun, 14 Oct 2012 00:07:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=PwCn+zPMoTsBe4Ek6+QPPETRo4nAl3DXf4r2tQ6T8NQ=; b=ISvvdw/TZ65ZhPmM6tbWLdCbUGJgMcj2aGqrCDvjUkYC/MNcw6lhTMXlRvWGI0u5yx wXuZlHUboGF218/Tgo6uothV8ifexL/wWb5pPm9B5Mxur+Xvi0wnkibj7+0oqJJf7ozl aAiMoB3UKcTRrYj2hhXDM7uzW4kwRSi0u8xEBJcP1gkd1i83wjRHXiKOGe1+HANrZvor ceSq6SG9MaKn/StWihKiT0CRNY/SocEE5hS+ZcxnEUFVo/MPE2srbWEGMHU2XBcIy3wX ta59uhqJPY+/xVWvd4UAWVKlUbsX+0AWVwS+rBKkfPGWFZa5y22UEm1xhM7f/pG2mQ5W IUXw== Received: by 10.180.108.45 with SMTP id hh13mr16014427wib.15.1350198455184; Sun, 14 Oct 2012 00:07:35 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:976:62b6:de73:ec3b? ([2001:470:7a9b:1:976:62b6:de73:ec3b]) by mx.google.com with ESMTPS id eq2sm8054235wib.1.2012.10.14.00.07.33 (version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 00:07:34 -0700 (PDT) References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD992C@xmb-rcd-x02.ci sco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD992C@xmb-rcd-x02.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-724EDEB6-C658-4C38-A0D8-5E78F407892D Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A403) From: Teco Boot Date: Sun, 14 Oct 2012 09:07:32 +0200 To: "JP Vasseur (jvasseur)" X-Gm-Message-State: ALoCoQmI0VBSOC0iJ/Grim8EOEywJPLdWyMnPQdE6GnvRMxigLr9MiXrORFQ5qDPPjd+GdxE4l+q Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 07:07:38 -0000 --Apple-Mail-724EDEB6-C658-4C38-A0D8-5E78F407892D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I have seen consensus we should not have this discussion right now.=20 Also, part of the discussion should be in ROLL.=20 So I silently ignore all of it :-) Nice weekend.=20 Teco Op 14 okt. 2012 om 08:58 heeft "JP Vasseur (jvasseur)" h= et volgende geschreven: > Hi Ulrich, >=20 > On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote: >=20 >> Hi JP, >>=20 >> On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur) wrote: >>>> [...] >>>> I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, i= f we come up with a MANET reactive protocol, it is only logical that for som= e LLNs the reactive MANET protocol would be suitable as well; but clearly, M= ANET should cover the general case of MANETs. >>>=20 >>> JP> So in this case, I would suggest to explicitly exclude all LLNs cove= rage from the Load ID, and have it covered in ROLL. Does that make sense ? >>=20 >>=20 >> I don't understand what you are saying here. That has not been proposed a= nywhere in this discussion. >=20 > JP> All I am saying here is that the chairs agreed to avoid overlap, not u= nusual at the IETF. Since ROLLE is covering LLNs (that's *the* charter), and= we will not > cover other types of network that are MANET but not LLNs, the future react= ive protocol designed by MANET should explicitly not cover LLNs. This will a= void overlaps. >=20 >>=20 >> [...] >>>> Right, and I don't see why there would be overlap. >>>=20 >>> JP> As long as you agree with the previous statement, we're fine. >>=20 >> Good. >>=20 >> Best >> Ulrich=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-724EDEB6-C658-4C38-A0D8-5E78F407892D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I have seen consensus we should not ha= ve this discussion right now. 

Also, part of t= he discussion should be in ROLL. 

So I silentl= y ignore all of it :-)

Nice weekend. 
Teco

Op 14 okt. 2012 om 08:58 heeft "JP Vasseur (= jvasseur)" <jvasseur@cisco.com&= gt; het volgende geschreven:

Hi Ulrich,

On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote:

Hi JP,

On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvas= seur) <jvasseur@cisco.c= om> wrote:
[...]
I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, i= f we come up with a MANET reactive protocol, it is only logical that for som= e LLNs the reactive MANET protocol would be suitable as well; but clearly, M= ANET should cover the general case of MANETs.

JP> So in this case, I would suggest to explicitly exclude all LLNs c= overage from the Load ID, and have it covered in ROLL. Does that make sense ?=


I don't understand what you are saying here. That has not been proposed= anywhere in this discussion.


JP> All I am saying here is that the chairs agreed to avoid overlap,= not unusual at the IETF. Since ROLLE is covering LLNs (that's *the* charter= ), and we will not
cover other types of network that are MANET but not LLNs, the future re= active protocol designed by MANET should explicitly not cover LLNs. This wil= l avoid overlaps.


 [...]
Right, and I don't see why there would be overlap.

JP> As long as you agree with the previous statement, we're fine.


Good.

Best
Ulrich 


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-724EDEB6-C658-4C38-A0D8-5E78F407892D-- From ietf@thomasclausen.org Sun Oct 14 00:46:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8CF21F84DA for ; Sun, 14 Oct 2012 00:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDR6ptd2xLEt for ; Sun, 14 Oct 2012 00:46:20 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 03FA421F84D6 for ; Sun, 14 Oct 2012 00:46:20 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8738EA36D2 for ; Sun, 14 Oct 2012 00:46:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DD3F51BC1B55; Sun, 14 Oct 2012 00:46:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.10.6] (37-8-188-28.coucou-networks.fr [37.8.188.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9D5E61BC1A13; Sun, 14 Oct 2012 00:46:13 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Heide Clausen In-Reply-To: Date: Sun, 14 Oct 2012 09:46:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84665BD8-B7A3-42D0-9C35-C8AB9240C641@thomasclausen.org> References: To: Henning Rogge X-Mailer: Apple Mail (2.1498) Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 07:46:20 -0000 On Oct 13, 2012, at 23:18 , Henning Rogge wrote: > Interesting question... the last time we worked on the draft the > discussion bogged down with the question if this is the "right way" to > do ETX. >=20 > Maybe a split would be a good idea, we could have an informal document > specifying the strategy we are using at Freifunk/Funkfeuer for ETX. > And then we could work on how to transform this into a good OLSRv2 > metric. >=20 I do not know if a split is the right thing to do - then again, I do not = know that it isn't either.=20 I think that what the previous version of the I-D failed to do, and what = caused the bogged-down discussion, was to frame properly what the = content was about.=20 I think that producing an informational RFC saying something of the = kind: "This is one way of doing ETX, specifically the one way that has = shown to work=20 well in a large deployment in continuous operation. It is = probably not the only way, and perhaps not the best way, of doing ETX, but this is one = way that's proven to=20 work well" Would be quite useful. I don't know if one "best way of calculating ETX" exists -- I do know = that there's a saying that can be adapted to be appropriate here: "Best = is the enemy of good". Thomas > Henning Rogge >=20 > On Sat, Oct 13, 2012 at 5:37 PM, Ulrich Herberg = wrote: >> I think this draft is indeed interesting, and I wonder if there is = any work >> planned to continue it. It seems to be a bit of a mixture between = specifying >> how to use ETX in OLSRv2, and a deployment experience of ETX with = OLSR in >> the FunkFeuer network. Is that the right way to go forward, or should = that >> not better be separated in two drafts? >>=20 >> Ulrich >>=20 >>=20 >> On Sat, Oct 13, 2012 at 5:41 AM, Abdussalam Baryun >> wrote: >>>=20 >>> I think some people in WG are interested also in Funkfeuer routing >>> metric [1], it was mentioned in MANET meeting 84. I hope we will see >>> the draft [2] to be accepted as a MANET WG draft shortly for >>> informational about Funkfeuer. >>>=20 >>> AB>suggest for title> >>> Packet Sequence Number based ETX Metric for Funkfeuer Networking. >>>=20 >>> AB> suggest the Abstract> >>> This document specifies the ETX metric and its usage in Funkfeuer's >>> OLSRv2 Routers. >>>=20 >>> I recommend to include this draft [2] or a renewal in the Agenda 85, >>> if the authors are welling to present it. >>>=20 >>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12077.html >>> [2] http://tools.ietf.org/html/draft-funkfeuer-manet-olsrv2-etx-01 >>>=20 >>> AB >>> ++ >>> On 10/12/12, Henning Rogge wrote: >>>> On 10/12/2012 09:53 AM, Abdussalam Baryun wrote: >>>>> +1 >>>>>=20 >>>>> It is an excellent draft/work, I support the draft and your = process. >>>>> Thanks to all: authors, you and the WG, >>>>=20 >>>> The document will be a great help as a pointer for people who still >>>> arguing the use of link metrics. Good to see it here. >>>>=20 >>>> Henning Rogge >>>>=20 >>>>=20 >>>> -- >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) >>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sun Oct 14 00:49:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131A121F84A2 for ; Sun, 14 Oct 2012 00:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWKPmPk3VMQk for ; Sun, 14 Oct 2012 00:49:25 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68E4621F849D for ; Sun, 14 Oct 2012 00:49:25 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2022141dan.31 for ; Sun, 14 Oct 2012 00:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=AWdsJ4ZxaExzZ4SNTwnVWxzNZlrdlRwkmaG53wdddmI=; b=f0iCyaI8mUO4x6R9QHPRMxkw+Z8eYIgItu+73hifX0lmnPJpAbpKWTTA70A0j8JGJP kOaBVeYrbZrH6UVeFJSxrPccwt/VwBotkoRNVMnuWPWNbCRcbyEqDsxjiYEozLCynkLa n6neiitSINvNB2SvqyvFvLhHZ5H/iv3BjLdWHW9Rfu51GToD6V86mqdifWm5Y4vXDUX7 xkDn88NyDn5LIOt5zx/1WhZfINvRTJ3lmgdNPWFpZtXuDU3LaeenH3/RmCJFLbiHI7b1 YPHb2fe0wLy9lNai2lvFUxUHFVGX+k1rv+DSM8GpFhlGMDWCwbNh1n/rmLnUBU/BceoD 0MJA== Received: by 10.66.77.70 with SMTP id q6mr24082800paw.24.1350200965049; Sun, 14 Oct 2012 00:49:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sun, 14 Oct 2012 00:49:04 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Sun, 14 Oct 2012 09:49:04 +0200 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 07:49:26 -0000 Hi, On Sun, Oct 14, 2012 at 9:07 AM, JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: > > Since you ask here...In my personal opinion, LLNs are a 100% subset of= a > > MANET. Both are usually multi-hop, often wireless, with constrained rou= ters, > > in many cases incoming packets leave a router on the same interface tha= t > > they have been received on, and the topology is dynamic. > > > Well, in this case, pushing your reasoning a bit further, this may very > well apply to OSPF, ISIS, =85 too. OLSR is a normal linkstate protocol which has been optimized for the mobile/adhoc/instable-link case. > I clearly do not think that LLNs are 100% subset of MANET; there is a > tremendous difference between several dozens of highly constrained fixed > routers interconnected > by very lossy links providing a few KBits/s and several hundreds of route= rs > with high mobility interconnected by Wifi links. We have been thinking about running something based on OLSR on a VHF radio... which has a channel capacity of up to 8 kBit/s. I also had talks with one of the authors at the ROLL group who suggested that RIPPLE could replace OLSR for city-wide wifi-based mesh networks. the ROLL group just focus much more on a very specialized area of adhoc networks, which make them accept some optimizations which would be not acceptable for MANET. > > MANETs, IMO, have a larger range of "constrained routers", from very > > constrained routers (e.g. LLN) to somewhat constrained routers (e.g. > > community networks) to non-constrained routers (e.g. certain military > > deployments). LLN is focused on extremely constrained devices. > > However, I don't say that we should revisit the way how the Routing Are= a > > distributed the tasks in the WGs, nor do I suggest to change the charte= rs. > > > IF that were the case, we would not have formed two WG but one. I think thats a totally different discussion. > > As Jiazi pointed out correctly, I don't understand why we have this > > discussion before you have seen the latest LOADng revision. I support this. I was present at one discussion about LOADng and we had quite an interesting talk about gateways and how to integrate them. This shows (in my opinion) that the focus of LOADng at the IETF will be broader than just LLNs. Lets wait until we have a new personal draft, then we can decide if it fits MANET. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Sun Oct 14 00:49:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C184721F84EF for ; Sun, 14 Oct 2012 00:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNX+iQXn2ERD for ; Sun, 14 Oct 2012 00:49:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C365921F84EE for ; Sun, 14 Oct 2012 00:49:31 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4782400vbb.31 for ; Sun, 14 Oct 2012 00:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vplTsbsT6kjAruwW+F30Bf3Z5+c1bODAN5YZRkx/ELE=; b=u1G3qtXLETtfNc6SNzQ+33gEKqMbQ1RMyvNIoURizik+xXlEiM3B1VyNwGHfiJ/CcM FIncFzzmE3qi/bIeqonmHN8BQyl+wj4FX8mh8VVMxs72fF0G/K0UdejE6MYDBkinvPkY l27aV939lIrCg33B4xiy5IJUw8nh3WlF1S/Q2zaIw3VBqMJDUuhZt6Lz0nWlTh6VJ9H2 9PWUJVjFDQYlQq0jiBgn48zkuLEZNz/ye+w8PT/lCE+ZtFhZco78bk3PJ2uILo/bJML8 O5WEVPcBdVvPFZOEo1jQY8ADS6J0ENQbUCos6gtPzs2OMtNI6TCxWtcaQ/BgXvCwb4dn XMfw== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr4028461vdj.99.1350200971231; Sun, 14 Oct 2012 00:49:31 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sun, 14 Oct 2012 00:49:30 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD992C@xmb-rcd-x02.cisco.com> Date: Sun, 14 Oct 2012 09:49:30 +0200 Message-ID: From: Abdussalam Baryun To: " List" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 07:49:32 -0000 I agree with Teco, Stan, Macker, Cedric, and JP, regarding excluding LLNs from drafts related to Mobile Ad Hoc NETworking, or within MANET discussions. As I posted before, we should not see the *draft-author-lln-loadng* in MANET meeting IETF85. I beleive we should not discuss the LOADng individual draft further, we already gave it enough attention and meeting-time. In the past the authors of LOADng waisted the time of Face-to-Face meetings, because they choosed the wrong channel to present their LLN-document and ideas, even though the IETF participants gave them the chance to present in MANET WG Agenda-slots, but that should not continue, because we already have more important work scheduled with milestones. The strange thing is WHY the document of LOADng was proposed by the authors to be a MANET document in the IETF 84 MANET WG meeting, while we already have ROLL WG that is responsible for such LLN Routing standards? I recommend that all participants, including MANET and ROLL chairs agreeing to control/organise face-to-face meetings to avoid that in the future meetings including the 85 meeting (if you cannot help it please do free-discussions out the meeting rooms or on the WGs-mailing-lists). AB On 10/14/12, Teco Boot wrote: > I have seen consensus we should not have this discussion right now. > > Also, part of the discussion should be in ROLL. > > So I silently ignore all of it :-) > > Nice weekend. > Teco > > Op 14 okt. 2012 om 08:58 heeft "JP Vasseur (jvasseur)" > het volgende geschreven: > >> Hi Ulrich, >> >> On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote: >> >>> Hi JP, >>> >>> On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur) >>> wrote: >>>>> [...] >>>>> I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, >>>>> if we come up with a MANET reactive protocol, it is only logical that >>>>> for some LLNs the reactive MANET protocol would be suitable as well; >>>>> but clearly, MANET should cover the general case of MANETs. >>>> >>>> JP> So in this case, I would suggest to explicitly exclude all LLNs >>>> coverage from the Load ID, and have it covered in ROLL. Does that make >>>> sense ? >>> >>> >>> I don't understand what you are saying here. That has not been proposed >>> anywhere in this discussion. >> >> JP> All I am saying here is that the chairs agreed to avoid overlap, not >> unusual at the IETF. Since ROLLE is covering LLNs (that's *the* charter), >> and we will not >> cover other types of network that are MANET but not LLNs, the future >> reactive protocol designed by MANET should explicitly not cover LLNs. This >> will avoid overlaps. >> >>> >>> [...] >>>>> Right, and I don't see why there would be overlap. >>>> >>>> JP> As long as you agree with the previous statement, we're fine. >>> >>> Good. >>> >>> Best >>> Ulrich From abdussalambaryun@gmail.com Sun Oct 14 01:00:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA4A21F84DD for ; Sun, 14 Oct 2012 01:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-pnyBofsnAa for ; Sun, 14 Oct 2012 01:00:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65C5921F847F for ; Sun, 14 Oct 2012 01:00:45 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4786185vbb.31 for ; Sun, 14 Oct 2012 01:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=l6Wx5meq0U3AoBDQOFRTBlzXxHXXmRoXDOTF4n99tUQ=; b=zxHRFNaW1ZSorvyQ+YsfWaAnWFWGAekCiBbiKl9MmcvdiBMtmnGaQJK20V2O+o1Mt9 N/T3HOuJ7kkcLTHpgLW1gKPftqKoLgZwO+Sn/gdvtoqJu6Qy0L8pNzu13utGAymeSuRK igq6mJgMcUWVLewotCOyzW1/2ZcLphDdgTCcoNRH16Ivl9cS6JjhpV7ImgHfYuZ7qZBK jyt4GblaHYHGntnQwf1hi84+IsrGDZI6GXzRpRESbN4t7vH2OnmWJiV0TwL6rjDMeOOV cHSsTLlWLw0VQFlfR0XfqgXNV7BeXWwVziPAW0XCAkR2zg8qDmSOtyM8F5drYyINp032 +Tog== MIME-Version: 1.0 Received: by 10.220.142.8 with SMTP id o8mr5015985vcu.23.1350201644676; Sun, 14 Oct 2012 01:00:44 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sun, 14 Oct 2012 01:00:44 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> Date: Sun, 14 Oct 2012 10:00:44 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:00:46 -0000 Why wait for the new version, the authors of LOADng already proposed their LLN-document asking to become MANET document in the 84 meeting, please refer to the last meeting. It is not right to think that authors just will change words from LLN to be replaced by MANET as if they are the same networks. Also we should notice that LOADng is not better performance than RPL for specific networks as *LLNs*. If it is we report the facts. Participants respect the ROLL WG to do a good job and if we see any better routing function, we report to the ROLL WG on their list or meetings, because we are all in IETF as a team. AB On 10/14/12, Henning Rogge wrote: > Hi, > > On Sun, Oct 14, 2012 at 9:07 AM, JP Vasseur (jvasseur) > wrote: >> Hi Ulrich, >> >> On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: >> > Since you ask here...In my personal opinion, LLNs are a 100% subset o= f >> > a >> > MANET. Both are usually multi-hop, often wireless, with constrained >> > routers, >> > in many cases incoming packets leave a router on the same interface >> > that >> > they have been received on, and the topology is dynamic. >> >> >> Well, in this case, pushing your reasoning a bit further, this may very >> well apply to OSPF, ISIS, =85 too. > > OLSR is a normal linkstate protocol which has been optimized for the > mobile/adhoc/instable-link case. > >> I clearly do not think that LLNs are 100% subset of MANET; there is a >> tremendous difference between several dozens of highly constrained fixed >> routers interconnected >> by very lossy links providing a few KBits/s and several hundreds of >> routers >> with high mobility interconnected by Wifi links. > > We have been thinking about running something based on OLSR on a VHF > radio... which has a channel capacity of up to 8 kBit/s. I also had > talks with one of the authors at the ROLL group who suggested that > RIPPLE could replace OLSR for city-wide wifi-based mesh networks. > > the ROLL group just focus much more on a very specialized area of > adhoc networks, which make them accept some optimizations which would > be not acceptable for MANET. > >> > MANETs, IMO, have a larger range of "constrained routers", from very >> > constrained routers (e.g. LLN) to somewhat constrained routers (e.g. >> > community networks) to non-constrained routers (e.g. certain military >> > deployments). LLN is focused on extremely constrained devices. >> > However, I don't say that we should revisit the way how the Routing >> > Area >> > distributed the tasks in the WGs, nor do I suggest to change the >> > charters. >> >> >> IF that were the case, we would not have formed two WG but one. > > I think thats a totally different discussion. > >> > As Jiazi pointed out correctly, I don't understand why we have this >> > discussion before you have seen the latest LOADng revision. > > I support this. I was present at one discussion about LOADng and we > had quite an interesting talk about gateways and how to integrate > them. This shows (in my opinion) that the focus of LOADng at the IETF > will be broader than just LLNs. > > Lets wait until we have a new personal draft, then we can decide if it > fits MANET. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From hrogge@googlemail.com Sun Oct 14 01:09:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7668D21F84CF for ; Sun, 14 Oct 2012 01:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uM-9SMlgQb0 for ; Sun, 14 Oct 2012 01:09:24 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29FD321F84CD for ; Sun, 14 Oct 2012 01:09:24 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4028277pbb.31 for ; Sun, 14 Oct 2012 01:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NTH4InxFRTk09Q5jba5SqizaUUocSpWSr6v3yEXJk3A=; b=wUirHdBAu9eoULHmyU4jjx2I9IpHSRSXpt8sRwEzfdcMCfLGA7uZV1vvSCiD07XVCu xowPF7Ab0dPvsVuqH8l6InWp4BgCj6Y0tc6bcGG2ZzT5FqiOHRoeQxgdsOjvhp48uNWI p+qPdOzmSumy00H2emqzQsz+e8SrVSUqckO4FW6AmAH03e7CfD4UX8DHTIFcSA1gxQT0 uGKTIjM369avIAG4+gosu/7awnhtQPNfaS9edJSNL78ZyPfMO42EC3ssz9hWQcalBOVL gzV0f2BFFtBzh8CUG5Z5PwnCstfmGfH4fY9CwSVTj4GWNqgu2H2wxEx+NjDXDGm4XkRX 1cDg== Received: by 10.66.85.227 with SMTP id k3mr23762167paz.79.1350202163908; Sun, 14 Oct 2012 01:09:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sun, 14 Oct 2012 01:09:03 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Sun, 14 Oct 2012 10:09:03 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:09:25 -0000 On Sun, Oct 14, 2012 at 10:00 AM, Abdussalam Baryun wrote: > Why wait for the new version, the authors of LOADng already proposed > their LLN-document asking to become MANET document in the 84 meeting, > please refer to the last meeting. And I think the reason why it has NOT been adapted was that it sounded too LLN-focused. So the authors agreed they need to do more work on it. > It is not right to think that > authors just will change words from LLN to be replaced by MANET as if > they are the same networks. > Also we should notice that LOADng is not > better performance than RPL for specific networks as *LLNs*. If it is > we report the facts. Are you aware of some comparison between RPL and LOADng based on testing? If not, this makes absolutely no sense. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Sun Oct 14 01:20:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364A321F8498 for ; Sun, 14 Oct 2012 01:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZEZHxKscgEE for ; Sun, 14 Oct 2012 01:20:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B629B21F84D4 for ; Sun, 14 Oct 2012 01:20:50 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4793383vbb.31 for ; Sun, 14 Oct 2012 01:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=zZCJkTLYG0UDf5dFIIb7hsjZjjsXbxp9UZj5Jrent7I=; b=O7SqfdJ3UXvWwSqVMDkyywNkmLxuqz/UcymvMvF3z8D7DSSTlR0hX7yqpLA1Kk7UYF OO1cor5rTU20HSvUygoVayYGsd1NiWcsrpOb/pFOCbrkFaUWglcmI0HzEfwT4Dcr9Rx8 nrJMqz1hf3v0HScNQOL5Jgeb7q1g/pdS5V47jl4/BySJjEL2ZdIXo77m1jc/Qd1GnU5R UXoM/5KIYtquN3LvBIaBXZs1vdRVXAPWHmlR/I3n1JTQKQmsg7PJ87qaXcvrGEnEf0xG Cw5VghJ+hkeW54ORr5YbvANR+fjg+1RqM0MykDZbGaXaXiGqwnGwyLUa9psXcquuDdKA P6GA== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr4141820vdv.20.1350202850494; Sun, 14 Oct 2012 01:20:50 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sun, 14 Oct 2012 01:20:50 -0700 (PDT) Date: Sun, 14 Oct 2012 10:20:50 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:20:57 -0000 On 10/14/12, Henning Rogge wrote: > Hi, > > We have been thinking about running something based on OLSR on a VHF > radio... which has a channel capacity of up to 8 kBit/s. I also had > talks with one of the authors at the ROLL group who suggested that > RIPPLE could replace OLSR for city-wide wifi-based mesh networks. Good practices and tests with results are important, which we will need in IETF, hope no one says I don't/cannt present my results. RPL is better for LLNs, and OLSR is better for City Wide Area Networks. > > the ROLL group just focus much more on a very specialized area of > adhoc networks, which make them accept some optimizations which would > be not acceptable for MANET. > LLN can be ad-hoc or not, but MANETs MUST be ad-hoc, but MANET can be constrained or not, but LLNs MUST be constrained. IMHO, MANETs are also specialized not only LLNs. AB From hrogge@googlemail.com Sun Oct 14 01:24:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3021F849D for ; Sun, 14 Oct 2012 01:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP9WjAc9mNfK for ; Sun, 14 Oct 2012 01:24:10 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E7C3021F8469 for ; Sun, 14 Oct 2012 01:24:04 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2029829dan.31 for ; Sun, 14 Oct 2012 01:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MrglxK8Rk3fprjxpnu9olwXxI44x3e87L1cRorP4XLA=; b=f8cfk7a0B8RYIyGMjseeLqNj2lnFwEslxSkF50+epV/y3UTjVEi3z8qDRk++Bs1Bf+ vosipD6QXpzIOzRikwIL2x+/drqtnNa++qor4L5CgLSuxTDaA84NpIUEdLOnxVdllpmF SMhZc60N57RPo4Ad6LQUO81th3g9F/Z0lNe7XW+G6Po/Tc4RRM99C5nIZaeKQrihLnAd nSz4olaCSknDzx8QGI0GIQQW73Bc6HQ4fxKPHimBIYM1ssLz3TEmcOYQlkdMLkFhU/5K EfIclO63lxxpiqw4NzRExLr+PQrBVzUwkbLZ0ea3rYPqNMZdAKakFvae9abicvZZDt/L MnUg== Received: by 10.68.242.9 with SMTP id wm9mr27495980pbc.62.1350203044532; Sun, 14 Oct 2012 01:24:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sun, 14 Oct 2012 01:23:44 -0700 (PDT) In-Reply-To: <84665BD8-B7A3-42D0-9C35-C8AB9240C641@thomasclausen.org> References: <84665BD8-B7A3-42D0-9C35-C8AB9240C641@thomasclausen.org> From: Henning Rogge Date: Sun, 14 Oct 2012 10:23:44 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:24:11 -0000 On Sun, Oct 14, 2012 at 9:46 AM, Thomas Heide Clausen wrote: > > On Oct 13, 2012, at 23:18 , Henning Rogge wrote: > >> Interesting question... the last time we worked on the draft the >> discussion bogged down with the question if this is the "right way" to >> do ETX. >> >> Maybe a split would be a good idea, we could have an informal document >> specifying the strategy we are using at Freifunk/Funkfeuer for ETX. >> And then we could work on how to transform this into a good OLSRv2 >> metric. >> > > I do not know if a split is the right thing to do - then again, I do not know that it isn't either. Maybe instead of splitting it into two Drafts, splitting the draft into two parts... one explaining what is used in the Freifunk/Funkfeuer networks currently and another one that suggests a way to use this strategy for OLSRv2 metrics. > I think that what the previous version of the I-D failed to do, and what caused the bogged-down discussion, was to frame properly what the content was about. > > I think that producing an informational RFC saying something of the kind: > > "This is one way of doing ETX, specifically the one way that has shown to work > well in a large deployment in continuous operation. It is probably not the only way, > and perhaps not the best way, of doing ETX, but this is one way that's proven to > work well" > > Would be quite useful. Another reason why it bogged down was the introduction of the new TLV to have a "out-of-band" channel between both end of the link for the routing metric calculation. The current Freifunk/Funkfeuer metric cannot be done without one. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Sun Oct 14 01:26:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05EC21F849D for ; Sun, 14 Oct 2012 01:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y71OQwhu8X5H for ; Sun, 14 Oct 2012 01:26:23 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62F1D21F849B for ; Sun, 14 Oct 2012 01:26:23 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3946969pad.31 for ; Sun, 14 Oct 2012 01:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IgcU9s/7/nF07zvhILuhJ7JB6oubaQOY4w8P3g4EpW4=; b=vWHfS+C8vwHpkkCfOe0jhSEl124sifbbSMvJ8bNJIYROeFm4L8T9CNf52mbG6Sg7bv 7c3jGQZMtdsc6fztQc7yGiptovoHZx6vhqDbV51aef6xI5f6+ye4m45+i1ZYUzDfi8HS FE9t9ZqUk7QVkOYbCoTHN4OjCdcz4Kvuww9udXhMwx+saYiuL+cAMl3rTWOOf+7T0odA kvDOGuMJ1Hgk/aZpYNnmlhWnUXSnGnK3UlFxZZVn7nX2EkFPBTFHtZ2pyNa81ObJUafc UzroRP8wMQvhzAj5ilQ991M89T7++LYzFSVn749YIvjrWa2iyagmehw0elG3GKIaskyx s8tA== Received: by 10.68.242.9 with SMTP id wm9mr27505719pbc.62.1350203183119; Sun, 14 Oct 2012 01:26:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sun, 14 Oct 2012 01:26:02 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sun, 14 Oct 2012 10:26:02 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:26:23 -0000 On Sun, Oct 14, 2012 at 10:20 AM, Abdussalam Baryun wrote: > On 10/14/12, Henning Rogge wrote: >> the ROLL group just focus much more on a very specialized area of >> adhoc networks, which make them accept some optimizations which would >> be not acceptable for MANET. >> > > LLN can be ad-hoc or not, but MANETs MUST be ad-hoc, but MANET can be > constrained or not, but LLNs MUST be constrained. IMHO, MANETs are > also specialized not only LLNs. Most of the Community Mesh networks use MANET routing protocols despite not being adhoc. They are still considered as MANET. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Sun Oct 14 01:28:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBEC21F84E4 for ; Sun, 14 Oct 2012 01:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4gSFEqh7Yxq for ; Sun, 14 Oct 2012 01:28:22 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A989321F849D for ; Sun, 14 Oct 2012 01:28:22 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id AACF9A36DA for ; Sun, 14 Oct 2012 01:28:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 907181C072A; Sun, 14 Oct 2012 01:28:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.20.10.6] (37-8-188-28.coucou-networks.fr [37.8.188.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C218E1C0562; Sun, 14 Oct 2012 01:28:18 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Heide Clausen In-Reply-To: Date: Sun, 14 Oct 2012 10:28:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B25D644-2E12-4091-A7B9-98D055C0C28D@thomasclausen.org> References: <84665BD8-B7A3-42D0-9C35-C8AB9240C641@thomasclausen.org> To: Henning Rogge X-Mailer: Apple Mail (2.1498) Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:28:23 -0000 On Oct 14, 2012, at 10:23 , Henning Rogge wrote: > On Sun, Oct 14, 2012 at 9:46 AM, Thomas Heide Clausen > wrote: >>=20 >> On Oct 13, 2012, at 23:18 , Henning Rogge = wrote: >>=20 >>> Interesting question... the last time we worked on the draft the >>> discussion bogged down with the question if this is the "right way" = to >>> do ETX. >>>=20 >>> Maybe a split would be a good idea, we could have an informal = document >>> specifying the strategy we are using at Freifunk/Funkfeuer for ETX. >>> And then we could work on how to transform this into a good OLSRv2 >>> metric. >>>=20 >>=20 >> I do not know if a split is the right thing to do - then again, I do = not know that it isn't either. >=20 > Maybe instead of splitting it into two Drafts, splitting the draft > into two parts... one explaining what is used in the > Freifunk/Funkfeuer networks currently and another one that suggests a > way to use this strategy for OLSRv2 metrics. >=20 >> I think that what the previous version of the I-D failed to do, and = what caused the bogged-down discussion, was to frame properly what the = content was about. >>=20 >> I think that producing an informational RFC saying something of the = kind: >>=20 >> "This is one way of doing ETX, specifically the one way that = has shown to work >> well in a large deployment in continuous operation. It is = probably not the only way, >> and perhaps not the best way, of doing ETX, but this is one = way that's proven to >> work well" >>=20 >> Would be quite useful. >=20 > Another reason why it bogged down was the introduction of the new TLV > to have a "out-of-band" channel between both end of the link for the > routing metric calculation. The current Freifunk/Funkfeuer metric > cannot be done without one. >=20 Yes, but that would (IMO) be fair enough in the "this is one way of = doing ETX that we've got operational experience with as working - but, = not the only one". The only snag would be that care should be made that the defined TLV = would be "flexible" enough to support other such signaling, but I do not = see that as a huge problem.... Thomas > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From hrogge@googlemail.com Sun Oct 14 01:31:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3BF21F84DD for ; Sun, 14 Oct 2012 01:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8ijLNxZCS4s for ; Sun, 14 Oct 2012 01:31:29 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89FC521F846B for ; Sun, 14 Oct 2012 01:31:29 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3948392pad.31 for ; Sun, 14 Oct 2012 01:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yPY4sbBfEsrSsGbHlYAFFGSNICmSBX2p6XlBYwms+Ig=; b=Z6xvlRYaODI/aSTe55gvJssb01Ld8cq8cTtQcUk9PJoSu3RT4Q78k6zag3QSTBknBg Mm9umxPfm0JmSYMb5lyo3W8V8g4LZ8HmYGYKjlKgy3sJ75YxfW0GgF7g6TB4NFqMsKUE 6VWui3rrEYMKm6N2gQmYQxsAvfJOt6ShEedGYz9LOwK9cJ8BjrCdSX3zYbs/CWvZZ+F8 RJikxhUZIIIoy8EpFqdtM21C+23nQN148w7gQkQDIea4J6ue4RvNnDHSsK6l4UJJONbN 878kvTwxzbfwrI8IeRKL9C+1oTFJDwMB5F5h/b9IiMaZVYd6tgPkr2OUTAhNEMVKjbHM HEaA== Received: by 10.68.233.196 with SMTP id ty4mr27526783pbc.23.1350203489176; Sun, 14 Oct 2012 01:31:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sun, 14 Oct 2012 01:31:09 -0700 (PDT) In-Reply-To: <1B25D644-2E12-4091-A7B9-98D055C0C28D@thomasclausen.org> References: <84665BD8-B7A3-42D0-9C35-C8AB9240C641@thomasclausen.org> <1B25D644-2E12-4091-A7B9-98D055C0C28D@thomasclausen.org> From: Henning Rogge Date: Sun, 14 Oct 2012 10:31:09 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:31:31 -0000 On Sun, Oct 14, 2012 at 10:28 AM, Thomas Heide Clausen wrote: >> Another reason why it bogged down was the introduction of the new TLV >> to have a "out-of-band" channel between both end of the link for the >> routing metric calculation. The current Freifunk/Funkfeuer metric >> cannot be done without one. >> > > Yes, but that would (IMO) be fair enough in the "this is one way of doing ETX that we've got operational experience with as working - but, not the only one". Okay. > The only snag would be that care should be made that the defined TLV would be "flexible" enough to support other such signaling, but I do not see that as a huge problem.... My suggestion was to make it "content defined by metric with same extension type". Which means that the algorithm calculating the metric TLV with extension type X can decide to use the "Internal Metric Data" TLV with any kind of data and length. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Sun Oct 14 01:32:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A492021F8532 for ; Sun, 14 Oct 2012 01:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU4RCxRQLsUX for ; Sun, 14 Oct 2012 01:32:09 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EEC0921F852A for ; Sun, 14 Oct 2012 01:32:08 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E82BDA3700 for ; Sun, 14 Oct 2012 01:32:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9511C1C0072; Sun, 14 Oct 2012 01:32:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.20.10.6] (37-8-188-28.coucou-networks.fr [37.8.188.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 959C21C0056; Sun, 14 Oct 2012 01:32:06 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Heide Clausen In-Reply-To: Date: Sun, 14 Oct 2012 10:32:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35FE0C81-457C-4A05-B2F4-F54F7F6E1F9A@thomasclausen.org> References: <84665BD8-B7A3-42D0-9C35-C8AB9240C641@thomasclausen.org> <1B25D644-2E12-4091-A7B9-98D055C0C28D@thomasclausen.org> To: Henning Rogge X-Mailer: Apple Mail (2.1498) Cc: manet@ietf.org Subject: Re: [manet] MANET protocols in the community network as Funkfeuer. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:32:09 -0000 On Oct 14, 2012, at 10:31 , Henning Rogge wrote: > On Sun, Oct 14, 2012 at 10:28 AM, Thomas Heide Clausen > wrote: >>> Another reason why it bogged down was the introduction of the new = TLV >>> to have a "out-of-band" channel between both end of the link for the >>> routing metric calculation. The current Freifunk/Funkfeuer metric >>> cannot be done without one. >>>=20 >>=20 >> Yes, but that would (IMO) be fair enough in the "this is one way of = doing ETX that we've got operational experience with as working - but, = not the only one". >=20 > Okay. >=20 >> The only snag would be that care should be made that the defined TLV = would be "flexible" enough to support other such signaling, but I do not = see that as a huge problem.... >=20 > My suggestion was to make it "content defined by metric with same > extension type". Which means that the algorithm calculating the metric > TLV with extension type X can decide to use the "Internal Metric Data" > TLV with any kind of data and length. Which would be one workable option, indeed. Thomas > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From internet-drafts@ietf.org Sun Oct 14 01:32:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4338621F8549; Sun, 14 Oct 2012 01:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cwixDXxsQVh; Sun, 14 Oct 2012 01:32:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D808121F8543; Sun, 14 Oct 2012 01:32:10 -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: 4.34 Message-ID: <20121014083210.15023.95664.idtracker@ietfa.amsl.com> Date: Sun, 14 Oct 2012 01:32:10 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:32:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : The Optimized Link State Routing Protocol version 2 Author(s) : Thomas Heide Clausen Christopher Dearlove Philippe Jacquet Ulrich Herberg Filename : draft-ietf-manet-olsrv2-17.txt Pages : 110 Date : 2012-10-14 Abstract: This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Sun Oct 14 01:39:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1737A21F849C for ; Sun, 14 Oct 2012 01:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKrzqRoMNmum for ; Sun, 14 Oct 2012 01:39:25 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68721F8496 for ; Sun, 14 Oct 2012 01:39:25 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7621383iec.31 for ; Sun, 14 Oct 2012 01:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cA/jnqI61AICzFcQGAYPrPz4gi5sfx33LzCLT234cQc=; b=uew+x2QKPJkhVL0/Ix5I7X8/uO+A9NWwCy+TnKEgXATltfYmiwBYOOoEBfO6k6p6lL dpUhwtsswurYRSKg4Ru7Osv8uL+JvFCb95QtVkv6KcTu2y9zbdZp0G3jg0Ub2PbhFW6b L2w3dFb4j8BOoIlKtBe3BHCuz/2cyW8rr53w1cSFKuT0Gri6yotOIytj0tPgwc9R9hHI xLdVOPU9OBt+Qf5Qm3O2/3Nrk8bZZkBj7TF9wAQwFegiReNoaaHAF3ZjGwo/eqOngnFB WVAr5/D4n9Ou1BjT1ZsBZ7MGkZFBqigR1LnEzdIiu1GQrc3qkYp300OP9FX+a8kCN5cE mWuA== MIME-Version: 1.0 Received: by 10.50.179.33 with SMTP id dd1mr6171473igc.31.1350203964944; Sun, 14 Oct 2012 01:39:24 -0700 (PDT) Received: by 10.64.25.46 with HTTP; Sun, 14 Oct 2012 01:39:24 -0700 (PDT) Date: Sun, 14 Oct 2012 10:39:24 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: [manet] All Wireless Mesh Networks are MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 08:39:26 -0000 Hi Henning, My understanding of Wireless Mesh Networks (WMN) that they are ad hoc networks, I read that in the literatures, but not sure why a non-ad-hoc network is called MANET in industry. But agree that any network that runs MANET routings and networking SHOULD be called MANET AB On 10/14/12, Henning Rogge wrote: > On Sun, Oct 14, 2012 at 10:20 AM, Abdussalam Baryun > wrote: >> On 10/14/12, Henning Rogge wrote: >>> the ROLL group just focus much more on a very specialized area of >>> adhoc networks, which make them accept some optimizations which would >>> be not acceptable for MANET. >>> >> >> LLN can be ad-hoc or not, but MANETs MUST be ad-hoc, but MANET can be >> constrained or not, but LLNs MUST be constrained. IMHO, MANETs are >> also specialized not only LLNs. > > Most of the Community Mesh networks use MANET routing protocols > despite not being adhoc. They are still considered as MANET. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From drdanhe@gmail.com Sun Oct 14 02:26:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCD21F84F2 for ; Sun, 14 Oct 2012 02:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-pi676ai67b for ; Sun, 14 Oct 2012 02:26:29 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A1D0321F84EE for ; Sun, 14 Oct 2012 02:26:28 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so797210wib.13 for ; Sun, 14 Oct 2012 02:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LAawcNbBbSYQgMQyOGgyVBgiIJSMBTRMy4mdh2E2K2s=; b=aZu8pY2q/yagQkoO8WKbulCgBRHrzqINNVaPLgY039y0HCrt3YuZeoegmtUPzZmw+G 6IhXdCTzKJVIXNX5uEAeU7lTGZnes7ZWi34OADdzIouY8VoK7KuywgV7l7g+1GfyUpyy h8TyfrWLteVG/EMh7t2n51QHabi3a5hddMSMc2QoK+FL38lY7o1c2kDZEaWg4984+HtP xOBlnsLWqJyAH+BfXIbAHJNhxi7uhT87WZOHt7xn9eW1FbEIYbVHoerM8TgizYwIVnda Bfg6B4gOQKuGCZ6YyVYIaDfdgrtTUKszxHAFNvFKbBcGHEmZUj85E8eUNWMOBOQnMfQZ O7NA== MIME-Version: 1.0 Received: by 10.216.140.11 with SMTP id d11mr5044609wej.29.1350206787367; Sun, 14 Oct 2012 02:26:27 -0700 (PDT) Received: by 10.194.59.71 with HTTP; Sun, 14 Oct 2012 02:26:27 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD992C@xmb-rcd-x02.cisco.com> Date: Sun, 14 Oct 2012 10:26:27 +0100 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=0016e6ddab7bef32e204cc01831b Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 09:26:33 -0000 --0016e6ddab7bef32e204cc01831b Content-Type: text/plain; charset=ISO-8859-1 As far as I understood, LLN is performance tweaking in MANET. I don't see why LLN and MANET can't form into two WGs if they have better focus individually. In IETF WGs, "SIP-related" technologies have 12 working groups. It makes no sense "against LOADng" to present in MANET meeting. LLN and MANET are largely overlapping. if WG charters want to avoid this kind of overlap, it is always good that we should invite LOADng authors to give a presentation on MANET meeting if the time is allowed. There is no absolutely white and black. Any "recommendation" should be given to technical impact not personally! Best Regards, Dan On 14 October 2012 08:49, Abdussalam Baryun wrote: > I agree with Teco, Stan, Macker, Cedric, and JP, regarding excluding > LLNs from drafts related to Mobile Ad Hoc NETworking, or within MANET > discussions. As I posted before, we should not see the > *draft-author-lln-loadng* in MANET meeting IETF85. > > I beleive we should not discuss the LOADng individual draft further, > we already gave it enough attention and meeting-time. In the past the > authors of LOADng waisted the time of Face-to-Face meetings, because > they choosed the wrong channel to present their LLN-document and > ideas, even though the IETF participants gave them the chance to > present in MANET WG Agenda-slots, but that should not continue, > because we already have more important work scheduled with milestones. > > The strange thing is WHY the document of LOADng was proposed by the > authors to be a MANET document in the IETF 84 MANET WG meeting, while > we already have ROLL WG that is responsible for such LLN Routing > standards? > I recommend that all participants, including MANET and ROLL chairs > agreeing to control/organise face-to-face meetings to avoid that in > the future meetings including the 85 meeting (if you cannot help it > please do free-discussions out the meeting rooms or on the > WGs-mailing-lists). > > AB > > On 10/14/12, Teco Boot wrote: > > I have seen consensus we should not have this discussion right now. > > > > Also, part of the discussion should be in ROLL. > > > > So I silently ignore all of it :-) > > > > Nice weekend. > > Teco > > > > Op 14 okt. 2012 om 08:58 heeft "JP Vasseur (jvasseur)" < > jvasseur@cisco.com> > > het volgende geschreven: > > > >> Hi Ulrich, > >> > >> On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote: > >> > >>> Hi JP, > >>> > >>> On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur) > >>> wrote: > >>>>> [...] > >>>>> I repeat what Adrian said: some if not all LLNs are MANETs. > Therefore, > >>>>> if we come up with a MANET reactive protocol, it is only logical that > >>>>> for some LLNs the reactive MANET protocol would be suitable as well; > >>>>> but clearly, MANET should cover the general case of MANETs. > >>>> > >>>> JP> So in this case, I would suggest to explicitly exclude all LLNs > >>>> coverage from the Load ID, and have it covered in ROLL. Does that make > >>>> sense ? > >>> > >>> > >>> I don't understand what you are saying here. That has not been proposed > >>> anywhere in this discussion. > >> > >> JP> All I am saying here is that the chairs agreed to avoid overlap, not > >> unusual at the IETF. Since ROLLE is covering LLNs (that's *the* > charter), > >> and we will not > >> cover other types of network that are MANET but not LLNs, the future > >> reactive protocol designed by MANET should explicitly not cover LLNs. > This > >> will avoid overlaps. > >> > >>> > >>> [...] > >>>>> Right, and I don't see why there would be overlap. > >>>> > >>>> JP> As long as you agree with the previous statement, we're fine. > >>> > >>> Good. > >>> > >>> Best > >>> Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Dan He --------------------- Tel: +44-788-686-3428 --0016e6ddab7bef32e204cc01831b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As far as I understood, LLN is performance tweaking in MANET.
I don'= t see why LLN and MANET can't form into two WGs if they
have better = focus individually. In IETF WGs, "SIP-related" technologies
have 12 working groups.

It makes no sense=A0 "against LOADng&qu= ot; to present in MANET meeting.
LLN and MANET are largely overlapping.= =A0 if WG charters want to avoid
this kind of overlap,=A0 it is always g= ood that we should invite LOADng authors
to give a presentation on MANET meeting if the time is=A0 allowed.

= There is no absolutely white and black. Any "recommendation" shou= ld
be given to technical impact not personally!

Best Regards,

Dan
=A0

On 14 October 2012 08:49, = Abdussalam Baryun <abdussalambaryun@gmail.com> wrot= e:
I agree with Teco, Stan, Macker, Cedric, and= JP, regarding excluding
LLNs from drafts related to Mobile Ad Hoc NETworking, or within MANET
discussions. As I posted before, we should not see the
*draft-author-lln-loadng* in MANET meeting IETF85.

I beleive we should not discuss the LOADng individual draft further,
we already gave it enough attention and meeting-time. In the past the
authors of LOADng waisted the time of Face-to-Face meetings, because
they choosed the wrong channel to present their LLN-document and
ideas, even though the IETF participants gave them the chance to
present in MANET WG Agenda-slots, but that should not continue,
because we already have more important work scheduled with milestones.

The strange thing is WHY the document of LOADng was proposed by the
authors to be a MANET document in the IETF 84 MANET WG meeting, while
we already have ROLL WG that is responsible for such LLN Routing
standards?
I recommend that all participants, including MANET and ROLL chairs
agreeing to control/organise face-to-face meetings to avoid that in
the future meetings including the 85 meeting (if you cannot help it
please do free-discussions out the meeting rooms or on the
WGs-mailing-lists).

AB

On 10/14/12, Teco Boot <teco@inf-net.= nl> wrote:
> I have seen consensus we should not have this discussion right now. >
> Also, part of the discussion should be in ROLL.
>
> So I silently ignore all of it :-)
>
> Nice weekend.
> Teco
>
> Op 14 okt. 2012 om 08:58 heeft "JP Vasseur (jvasseur)" <<= a href=3D"mailto:jvasseur@cisco.com">jvasseur@cisco.com>
> het volgende geschreven:
>
>> Hi Ulrich,
>>
>> On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote:
>>
>>> Hi JP,
>>>
>>> On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur)
>>> <jvasseur@cisco.com> wrote:
>>>>> [...]
>>>>> I repeat what Adrian said: some if not all LLNs are MA= NETs. Therefore,
>>>>> if we come up with a MANET reactive protocol, it is on= ly logical that
>>>>> for some LLNs the reactive MANET protocol would be sui= table as well;
>>>>> but clearly, MANET should cover the general case of MA= NETs.
>>>>
>>>> JP> So in this case, I would suggest to explicitly excl= ude all LLNs
>>>> coverage from the Load ID, and have it covered in ROLL. Do= es that make
>>>> sense ?
>>>
>>>
>>> I don't understand what you are saying here. That has not = been proposed
>>> anywhere in this discussion.
>>
>> JP> All I am saying here is that the chairs agreed to avoid ove= rlap, not
>> unusual at the IETF. Since ROLLE is covering LLNs (that's *the= * charter),
>> and we will not
>> cover other types of network that are MANET but not LLNs, the futu= re
>> reactive protocol designed by MANET should explicitly not cover LL= Ns. This
>> will avoid overlaps.
>>
>>>
>>> =A0[...]
>>>>> Right, and I don't see why there would be overlap.=
>>>>
>>>> JP> As long as you agree with the previous statement, w= e're fine.
>>>
>>> Good.
>>>
>>> Best
>>> Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--
Dan He
-= --------------------
Tel: +44-788-686-3428

--0016e6ddab7bef32e204cc01831b-- From hrogge@googlemail.com Sun Oct 14 03:01:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D34821F84E4 for ; Sun, 14 Oct 2012 03:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD9p7+cBtl2B for ; Sun, 14 Oct 2012 03:01:30 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id E581821F84F3 for ; Sun, 14 Oct 2012 03:01:29 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3975883pad.31 for ; Sun, 14 Oct 2012 03:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1KaA/yQuWA4fwSX/CBR/Cd6VQr5M09uLrX0t7b9CjBo=; b=Uwryq7be3oE5I++8wt31dwkFYlFqJFQhCQRz42nB0M3ZDMbzadDDO8Ze+x3YBEr9Sh qXXwN7oBC07Pzz73+J/EFeBPWGM8sNve1WpTrw+5XwnJn357wBjBVNw96ZJNqWk9JAog HT9uXEdUFDcUWp0GNR+TmNQqa0KS5DUwu94erxLQHWhgXrdZeQTZydxyZEavYehih5T5 +KkA1xyU0HZyTUX/Ti6o0EkhTQ2Xn2zEDb/OsIB3G7Tz6hKGQljBk/Qs+yRSnrZQFJ1d 337i5Akqs9xzF55i4vYVDGRIv24a0YWIyzOcJIl9NYlLDlViq01imEw0KSCrucEHcAvT 14Xw== Received: by 10.66.84.229 with SMTP id c5mr24234023paz.76.1350208886973; Sun, 14 Oct 2012 03:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Sun, 14 Oct 2012 03:01:06 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> <6ADE64B6-D14D-422D-9F1F-3C58A5E3FD46@inf-net.nl> <99CD3D34-84B8-43B5-9F68-122B397E3BD9@inf-net.nl> From: Henning Rogge Date: Sun, 14 Oct 2012 12:01:06 +0200 Message-ID: To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 10:01:30 -0000 I think the idea is not bad. IF we decide to use a special codepoint for "unknown TLV value", using "length = 0" would give us a generic way for doing it for all kind of additional metric TLVs... instead of doing this "what to use for UNKNOWN" brainstorming again. It also makes it easier to include the UNKNOWN codepoint into metrics which have no bits/values left. Henning Rogge On Sat, Oct 13, 2012 at 5:06 PM, Bo Berry wrote: > Teco > Thanks, this helps. So let's see what others think. > Have a great wkend. > > -Bo > > > On Oct 13, 2012, at 10:50 AM, Teco Boot wrote: > >> >> Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: >> >>> Teco, >>> I do not understand it and it's not been described in a manner >>> that I can. But if we can not understand it, we will not be >>> successful describing it such that it can be useful. >>> >>> If you can provide meaningful, descriptive text, that would help. >>> At this time, "prepare for data items that can fall back to unknown" >>> does not help me. What do you propose as optional data items >>> and how do you propose, by what mechanism, they fall back? Do >>> they fall back in the radio or router, or both? >> >> The optional Data Item TLVs for Neighbor Up are in the draft: >> - IPv4 Address >> - IPv6 Address >> - Maximum Data Rate >> - Current Data Rate >> - Latency >> - Expected Forwarding Time >> - Resources >> - Relative Link Factor >> - Credit Window Status >> Neighbor Up messages would be send by router, although the draft >> mentions the router can send it also. >> Relative Link Factor should be Relative Link Quality (posted before, >> I think). In Neighbor Update, Expected Forwarding Time is missing. >> >> My comment is on the protocol. Optional data item TLVs can be present, >> or not. There was a proposal for TLV with an UNKNOWN codepoint, for RLQ. >> I don't see much difference in UNKNOWN and not sending the TLV. Then, >> this UNKNOWN applies to all optional Data Item TLVs. So if we just >> add a mechanism that enables sending UNKNOWN for all optional Data >> Item TLVs, we are done. Addresses have the drop already. The other >> TLVs can have the length=0. That's all. I provided the text already. >> >> I can't be more clear. Sorry. >> >> Teco >> >>> >>> >>> -Bo >>> >>> >>> >>> On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: >>> >>>> DLEP is (mainly) getting the neighbor information base from radio to >>>> router, as accurate as possible. It is up to the router to use this for >>>> route calculation. >>>> >>>> This discussion is not about using RFC 5444. >>>> >>>> It is about transfer of "hey there, I don't have this info anymore". >>>> Bo and Stan say, this is not needed. Others say, there is a need for it. >>>> I agree with the others, because I cannot see a reason a radio is only >>>> allowed *once* during neighbor_up state to miss data items. We better >>>> prepare for data items that can fall back to unknown. I say: let's allow >>>> this for all optional data items. >>>> >>>> Teco >>>> >>>> >>>> Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende geschreven: >>>> >>>>> I agree we should design for the present MANET technologies and >>>>> future, for the protocol completion. Do you mean router-state as the >>>>> DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don't >>>>> understand why we need to consider router states. >>>>> >>>>> DLEP considers the session between server and client states, other >>>>> states are not inscope. For simplicity, DLEP should be abstract from >>>>> MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an >>>>> optional future interaction may be useful but complicated (will need >>>>> RFC5444). >>>>> >>>>> AB >>>>> >>>>> On 10/13/12, Teco Boot wrote: >>>>>> >>>>> My point is that the DLEP protocol should be "complete", in that the >>>>> radio is able to get the router in a certain state, in another state >>>>> and get back in the earlier state. RLQ is just an example. >>>>> >>>>> If you think this makes no sense with the radios you have seen up to >>>>> now, you could be right. Tomorrow, you could have a different opinion. >>>>> I saw on this mailing list some of us see already the requirement the >>>>> protocol shall be "complete". >>>> >>> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Sun Oct 14 04:51:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73421F84FF for ; Sun, 14 Oct 2012 04:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWs-mKUnYKkN for ; Sun, 14 Oct 2012 04:51:33 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D6BD021F84F6 for ; Sun, 14 Oct 2012 04:51:33 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8B931A3848 for ; Sun, 14 Oct 2012 04:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E17431BC880D; Sun, 14 Oct 2012 04:51:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.12.131] (unknown [194.182.142.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A034C1BC880C; Sun, 14 Oct 2012 04:51:31 -0700 (PDT) References: <20121014083210.15023.95664.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20121014083210.15023.95664.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3E1A43EF-789E-4DE3-AA1B-E67BA445E044@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Sun, 14 Oct 2012 13:51:29 +0200 To: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 11:51:34 -0000 For information, this revision contains clarifications as requested by the I= ESG during their review of the document. There are no functional changes to t= he protocol. The SEC AD has made comments, which have so far not been reflected in the do= cument, but will be reflected in a future revision, following (ongoing) disc= ussions between the authors, the SEC AD and Adrian. Best, Thomas Sent from my iPad On 14 oct. 2012, at 10:32, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. >=20 > Title : The Optimized Link State Routing Protocol version 2 > Author(s) : Thomas Heide Clausen > Christopher Dearlove > Philippe Jacquet > Ulrich Herberg > Filename : draft-ietf-manet-olsrv2-17.txt > Pages : 110 > Date : 2012-10-14 >=20 > Abstract: > This specification describes version 2 of the Optimized Link State > Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-17 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sun Oct 14 05:10:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C2621F850B for ; Sun, 14 Oct 2012 05:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB0FgVrUNLnD for ; Sun, 14 Oct 2012 05:10:19 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05F5B21F84FC for ; Sun, 14 Oct 2012 05:10:18 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7717862iec.31 for ; Sun, 14 Oct 2012 05:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q1WVvF6dezLHXJarrGt2HMPABzvkOXkRwzr9ojHqRmI=; b=UXnrJE12REqb7khRh4DUcaWls08I964g0H+GL7BTPtQ8wU7YE+ssVB23hj2MVn5S/X q2XyLP8aYuDL1BmxIGHdSWguUCicdyOkYLfIAqiPk06htn8TCDrXqIRxON9ham8EvZj+ /VrX3jT3sY8PtlahI7BFunkqIHuf+GMsyxEK4Pb+qqVlUOOYHDiorrpCFsGplML6c4Uu puJ6ZRpBZk9B22rr1YDswz7aVyiBJKJWj/ebOw3Q1LI6IiZTQXqmlLKhwKJSpvWrL1oM p3w3xd0lNTP5smo1KKdEJSTF5J+t/9DpoFjJ4Z5PvHevUJBWgBJ5raTdQvv8JihECmmr FWbA== MIME-Version: 1.0 Received: by 10.50.214.10 with SMTP id nw10mr6421896igc.31.1350216612925; Sun, 14 Oct 2012 05:10:12 -0700 (PDT) Received: by 10.64.25.46 with HTTP; Sun, 14 Oct 2012 05:10:12 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD3388@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD5949@xmb-rcd-x02.cisco.com> <521D8379-4FAE-4A1F-83BD-8B7E61B850FB@herberg.name> <03B78081B371D44390ED6E7BADBB4A7721FD5E91@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FD992C@xmb-rcd-x02.cisco.com> Date: Sun, 14 Oct 2012 13:10:12 +0100 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=14dae934113d95527304cc03cd9a Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 12:10:20 -0000 --14dae934113d95527304cc03cd9a Content-Type: text/plain; charset=ISO-8859-1 never personal, but making sure to have efficient meeting procedure to get good outcomes from IETF WGs meetings, and spend/enjoy effictive time in meetings. AB On Sun, Oct 14, 2012 at 10:26 AM, Daniel He wrote: > As far as I understood, LLN is performance tweaking in MANET. > I don't see why LLN and MANET can't form into two WGs if they > have better focus individually. In IETF WGs, "SIP-related" technologies > have 12 working groups. > > It makes no sense "against LOADng" to present in MANET meeting. > LLN and MANET are largely overlapping. if WG charters want to avoid > this kind of overlap, it is always good that we should invite LOADng > authors > to give a presentation on MANET meeting if the time is allowed. > > There is no absolutely white and black. Any "recommendation" should > be given to technical impact not personally! > > Best Regards, > > Dan > > > On 14 October 2012 08:49, Abdussalam Baryun wrote: > >> I agree with Teco, Stan, Macker, Cedric, and JP, regarding excluding >> LLNs from drafts related to Mobile Ad Hoc NETworking, or within MANET >> discussions. As I posted before, we should not see the >> *draft-author-lln-loadng* in MANET meeting IETF85. >> >> I beleive we should not discuss the LOADng individual draft further, >> we already gave it enough attention and meeting-time. In the past the >> authors of LOADng waisted the time of Face-to-Face meetings, because >> they choosed the wrong channel to present their LLN-document and >> ideas, even though the IETF participants gave them the chance to >> present in MANET WG Agenda-slots, but that should not continue, >> because we already have more important work scheduled with milestones. >> >> The strange thing is WHY the document of LOADng was proposed by the >> authors to be a MANET document in the IETF 84 MANET WG meeting, while >> we already have ROLL WG that is responsible for such LLN Routing >> standards? >> I recommend that all participants, including MANET and ROLL chairs >> agreeing to control/organise face-to-face meetings to avoid that in >> the future meetings including the 85 meeting (if you cannot help it >> please do free-discussions out the meeting rooms or on the >> WGs-mailing-lists). >> >> AB >> >> On 10/14/12, Teco Boot wrote: >> > I have seen consensus we should not have this discussion right now. >> > >> > Also, part of the discussion should be in ROLL. >> > >> > So I silently ignore all of it :-) >> > >> > Nice weekend. >> > Teco >> > >> > Op 14 okt. 2012 om 08:58 heeft "JP Vasseur (jvasseur)" < >> jvasseur@cisco.com> >> > het volgende geschreven: >> > >> >> Hi Ulrich, >> >> >> >> On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote: >> >> >> >>> Hi JP, >> >>> >> >>> On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur) >> >>> wrote: >> >>>>> [...] >> >>>>> I repeat what Adrian said: some if not all LLNs are MANETs. >> Therefore, >> >>>>> if we come up with a MANET reactive protocol, it is only logical >> that >> >>>>> for some LLNs the reactive MANET protocol would be suitable as well; >> >>>>> but clearly, MANET should cover the general case of MANETs. >> >>>> >> >>>> JP> So in this case, I would suggest to explicitly exclude all LLNs >> >>>> coverage from the Load ID, and have it covered in ROLL. Does that >> make >> >>>> sense ? >> >>> >> >>> >> >>> I don't understand what you are saying here. That has not been >> proposed >> >>> anywhere in this discussion. >> >> >> >> JP> All I am saying here is that the chairs agreed to avoid overlap, >> not >> >> unusual at the IETF. Since ROLLE is covering LLNs (that's *the* >> charter), >> >> and we will not >> >> cover other types of network that are MANET but not LLNs, the future >> >> reactive protocol designed by MANET should explicitly not cover LLNs. >> This >> >> will avoid overlaps. >> >> >> >>> >> >>> [...] >> >>>>> Right, and I don't see why there would be overlap. >> >>>> >> >>>> JP> As long as you agree with the previous statement, we're fine. >> >>> >> >>> Good. >> >>> >> >>> Best >> >>> Ulrich >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > > -- > Dan He > --------------------- > Tel: +44-788-686-3428 > > --14dae934113d95527304cc03cd9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
never personal, but making sure to have efficient meeting procedure to= get good outcomes from IETF WGs meetings, and spend/enjoy effictive time i= n meetings.
=A0
AB

On Sun, Oct 14, 2012 at 10:26 AM, Daniel He <drdanhe@gmail.com> wrote:
As far as I understood, LLN is performance tweaking in MANET.
I don'= t see why LLN and MANET can't form into two WGs if they
have better = focus individually. In IETF WGs, "SIP-related" technologies
have 12 working groups.

It makes no sense=A0 "against LOADng&qu= ot; to present in MANET meeting.
LLN and MANET are largely overlapping.= =A0 if WG charters want to avoid
this kind of overlap,=A0 it is always g= ood that we should invite LOADng authors
to give a presentation on MANET meeting if the time is=A0 allowed.

= There is no absolutely white and black. Any "recommendation" shou= ld
be given to technical impact not personally!

Best Regards,

Dan
=A0

On = 14 October 2012 08:49, Abdussalam Baryun <abdussalambaryun@gmail.= com> wrote:
I agree with Teco, Stan= , Macker, Cedric, and JP, regarding excluding
LLNs from drafts related to Mobile Ad Hoc NETworking, or within MANET
discussions. As I posted before, we should not see the
*draft-author-lln-loadng* in MANET meeting IETF85.

I beleive we should not discuss the LOADng individual draft further,
we already gave it enough attention and meeting-time. In the past the
authors of LOADng waisted the time of Face-to-Face meetings, because
they choosed the wrong channel to present their LLN-document and
ideas, even though the IETF participants gave them the chance to
present in MANET WG Agenda-slots, but that should not continue,
because we already have more important work scheduled with milestones.

The strange thing is WHY the document of LOADng was proposed by the
authors to be a MANET document in the IETF 84 MANET WG meeting, while
we already have ROLL WG that is responsible for such LLN Routing
standards?
I recommend that all participants, including MANET and ROLL chairs
agreeing to control/organise face-to-face meetings to avoid that in
the future meetings including the 85 meeting (if you cannot help it
please do free-discussions out the meeting rooms or on the
WGs-mailing-lists).

AB

On 10/14/12, Teco Boot <teco@inf-net.nl> wrote:
> I have seen consensus we should not have this discussion right now. >
> Also, part of the discussion should be in ROLL.
>
> So I silently ignore all of it :-)
>
> Nice weekend.
> Teco
>
> Op 14 okt. 2012 om 08:58 heeft "JP Vasseur (jvasseur)" <<= a href=3D"mailto:jvasseur@cisco.com" target=3D"_blank">jvasseur@cisco.com>
> het volgende geschreven:
>
>> Hi Ulrich,
>>
>> On Oct 14, 2012, at 3:16 AM, Ulrich Herberg wrote:
>>
>>> Hi JP,
>>>
>>> On Sat, Oct 13, 2012 at 9:48 AM, JP Vasseur (jvasseur)
>>> <jv= asseur@cisco.com> wrote:
>>>>> [...]
>>>>> I repeat what Adrian said: some if not all LLNs are MA= NETs. Therefore,
>>>>> if we come up with a MANET reactive protocol, it is on= ly logical that
>>>>> for some LLNs the reactive MANET protocol would be sui= table as well;
>>>>> but clearly, MANET should cover the general case of MA= NETs.
>>>>
>>>> JP> So in this case, I would suggest to explicitly excl= ude all LLNs
>>>> coverage from the Load ID, and have it covered in ROLL. Do= es that make
>>>> sense ?
>>>
>>>
>>> I don't understand what you are saying here. That has not = been proposed
>>> anywhere in this discussion.
>>
>> JP> All I am saying here is that the chairs agreed to avoid ove= rlap, not
>> unusual at the IETF. Since ROLLE is covering LLNs (that's *the= * charter),
>> and we will not
>> cover other types of network that are MANET but not LLNs, the futu= re
>> reactive protocol designed by MANET should explicitly not cover LL= Ns. This
>> will avoid overlaps.
>>
>>>
>>> =A0[...]
>>>>> Right, and I don't see why there would be overlap.=
>>>>
>>>> JP> As long as you agree with the previous statement, w= e're fine.
>>>
>>> Good.
>>>
>>> Best
>>> Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--
Dan He
---------------------Tel: +44-788-686-3428


--14dae934113d95527304cc03cd9a-- From abdussalambaryun@gmail.com Sun Oct 14 05:23:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989EC21F846A for ; Sun, 14 Oct 2012 05:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ve0vJhSxUb0 for ; Sun, 14 Oct 2012 05:23:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6D3421F8464 for ; Sun, 14 Oct 2012 05:23:58 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7725621iec.31 for ; Sun, 14 Oct 2012 05:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kkmtz2EK12bQVsMr9pPnomBYxJ3ItEE3fHhOLwpxzrA=; b=r4kvaBOgDVJQ/2HF+2xtQhqVtX3/tLiemCXFeuQG576wGUU72Ua8U5mV/xcTbuRraN 5TjmhkmQQqNcvIeG/g+AjiAIJRNx10cOj7t3U96K3XUeKbE5JtXg2n/az1iF3BNIrGy6 KVoG5Zh56YvqgGyE/PKHVhUJty16dmCAm6e6Hihcj3o9eN77op3LsNQRonXm4Ls/X8+y XkPqrnAL+pCNv0FdtLtw2BdgmQbbhSemo2G4/l+FMqMMUvv82vGc/pUuWIq06DzY4cjv QhG429uhuI50Gn47ervQNV0Txjgq8DuIMujbLcW1zNjzjiyHuegjV+B2joJYehcvMQoB sk+Q== MIME-Version: 1.0 Received: by 10.50.179.33 with SMTP id dd1mr6460498igc.31.1350217438323; Sun, 14 Oct 2012 05:23:58 -0700 (PDT) Received: by 10.64.25.46 with HTTP; Sun, 14 Oct 2012 05:23:58 -0700 (PDT) In-Reply-To: <3E1A43EF-789E-4DE3-AA1B-E67BA445E044@thomasclausen.org> References: <20121014083210.15023.95664.idtracker@ietfa.amsl.com> <3E1A43EF-789E-4DE3-AA1B-E67BA445E044@thomasclausen.org> Date: Sun, 14 Oct 2012 13:23:58 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=f46d0447a10fc7e44f04cc03fe92 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 12:23:59 -0000 --f46d0447a10fc7e44f04cc03fe92 Content-Type: text/plain; charset=ISO-8859-1 Thanks to inform us, however, I recommend to reduce the number of revision if possible, and we get more feedback from IESG each DISCUSS position, before re-issuing I-Ds. AB On Sun, Oct 14, 2012 at 12:51 PM, Thomas Heide Clausen < ietf@thomasclausen.org> wrote: > For information, this revision contains clarifications as requested by the > IESG during their review of the document. There are no functional changes > to the protocol. > > The SEC AD has made comments, which have so far not been reflected in the > document, but will be reflected in a future revision, following (ongoing) > discussions between the authors, the SEC AD and Adrian. > > Best, > > Thomas > > Sent from my iPad > > On 14 oct. 2012, at 10:32, internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > > > Title : The Optimized Link State Routing Protocol version 2 > > Author(s) : Thomas Heide Clausen > > Christopher Dearlove > > Philippe Jacquet > > Ulrich Herberg > > Filename : draft-ietf-manet-olsrv2-17.txt > > Pages : 110 > > Date : 2012-10-14 > > > > Abstract: > > This specification describes version 2 of the Optimized Link State > > Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-17 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d0447a10fc7e44f04cc03fe92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks to inform us, however, I recommend to reduce the number of revi= sion if possible, and we get more feedback from IESG each DISCUSS position,= =A0before re-issuing I-Ds.
=A0
AB
On Sun, Oct 14, 2012 at 12:51 PM, Thomas Heide Clausen &l= t;ietf@thomascl= ausen.org> wrote:
For information, this revision contains clarifications as requested by the = IESG during their review of the document. There are no functional changes t= o the protocol.

The SEC AD has made comments, which have so far not been reflected in the d= ocument, but will be reflected in a future revision, following (ongoing) di= scussions between the authors, the SEC AD and Adrian.

Best,

Thomas

Sent from my iPad

On 14 oct. 2012, at 10:32, inte= rnet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF.
>
> =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : The Optimized Link State Routing Pr= otocol version 2
> =A0 =A0Author(s) =A0 =A0 =A0 : Thomas Heide Clausen
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christopher Dearlov= e
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Philippe Jacquet > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ulrich Herberg
> =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-manet-olsrv2-17.txt
> =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 110
> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-14
>
> Abstract:
> =A0 This specification describes version 2 of the Optimized Link State=
> =A0 Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-o= lsrv2-17
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d0447a10fc7e44f04cc03fe92-- From abdussalambaryun@gmail.com Sun Oct 14 05:32:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C2D21F8522 for ; Sun, 14 Oct 2012 05:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUe-xwgoKNMr for ; Sun, 14 Oct 2012 05:32:52 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89A1F21F851C for ; Sun, 14 Oct 2012 05:32:52 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so3566244iad.31 for ; Sun, 14 Oct 2012 05:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IU66NCSwYjk9cUsZiozwY40HKLzJasMidS5DoYqj5gc=; b=C+TJDZbK3E1grZ/6Tkt5OQimgTN8EDowUrscyVRXPHWsnhaDvuZLTL04oj03eUCK2i Y7FjxALnv4lWdivGFGPNsHKjbTcmZmWyE9a7FaJorE9rGWaNzKLVPztCNUDPGEuT6r3H xb6jm3Iksjtm7MNynCuWOFUC4DXJZjdR1BkukgE7o4/VG3skh/Utbo7RGUTthheOKwEX aHfCTPVhtWbN3sA5JA0T2cxnDjUT65QcCNaGv/mReVPExsl/ZtdoghwSbafmK+mMVs2E m2RAZimf+b+kyiCZFw8b5g5D38eW+cbyR7q0ukB/9hwW+sUtDJ/4gMgh8xdnPYHm96aN Vj6A== MIME-Version: 1.0 Received: by 10.50.181.202 with SMTP id dy10mr6432094igc.14.1350217971915; Sun, 14 Oct 2012 05:32:51 -0700 (PDT) Received: by 10.64.25.46 with HTTP; Sun, 14 Oct 2012 05:32:51 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4005CE@xmb-aln-x03.cisco.com> <8B4AE4AA-C622-4E6C-AC8B-2DC6988B1C1F@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400979@xmb-aln-x03.cisco.com> <9A1307AA-8336-4789-B54A-D70F4F6D94DF@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F400BBD@xmb-aln-x03.cisco.com> <4BD1A7E4-8DED-4554-9812-28001A437BEF@thomasclausen.org> <08BD1049-0406-4FD6-BE76-AFC64C6080D9@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB6385C@ROCMXUS20.cs.myharris.net> <50767689.6040202@fkie.fraunhofer.de> <747F4E74-5EEF-40FE-B5B9-4D21E150F34B@cisco.com> <5076B0FE.4080400@fkie.fraunhofer.de> <818D827A-B53C-4BE3-9AF4-9E8B9BB447D9@cisco.com> <5076B2B5.8040403@fkie.fraunhofer.de> <5076B7A0.2050206@fkie.fraunhofer.de> <0E04853A-D125-47DD-848A-C567F9A07030@cisco.com> <718523FC-4C01-4540-B9D3-D2D9E81B8898@cisco.com> <13044204616BFB43BC7F6B4EC6B015123FB63C7B@ROCMXUS20.cs.myharris.net> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F403F9E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404442@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404628@xmb-aln-x03.cisco.com> <6E423A63-5D0C-47A3-9EC2-C035A462DB66@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404D84@xmb-aln-x03.cisco.com> <1A1AB74D-6CCC-42EA-AC25-6B7E58925E21@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F405888@xmb-aln-x03.cisco.com> <6ADE64B6-D14D-422D-9F1F-3C58A5E3FD46@inf-net.nl> <6D3A0272-0072-4F8A-9F50-17399CA76AED@cisco.com> <99CD3D34-84B8-43B5-9F68-122B397E3BD9@inf-net.nl> Date: Sun, 14 Oct 2012 13:32:51 +0100 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: multipart/alternative; boundary=14dae934038f95da2004cc041e59 Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 12:32:53 -0000 --14dae934038f95da2004cc041e59 Content-Type: text/plain; charset=ISO-8859-1 +1 support to the below input, and without any router state reflect on dlep-server. AB On Sat, Oct 13, 2012 at 4:06 PM, Bo Berry wrote: > Teco > Thanks, this helps. So let's see what others think. > Have a great wkend. > > -Bo > > > On Oct 13, 2012, at 10:50 AM, Teco Boot wrote: > > > > > Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: > > > >> Teco, > >> I do not understand it and it's not been described in a manner > >> that I can. But if we can not understand it, we will not be > >> successful describing it such that it can be useful. > >> > >> If you can provide meaningful, descriptive text, that would help. > >> At this time, "prepare for data items that can fall back to unknown" > >> does not help me. What do you propose as optional data items > >> and how do you propose, by what mechanism, they fall back? Do > >> they fall back in the radio or router, or both? > > > > The optional Data Item TLVs for Neighbor Up are in the draft: > > - IPv4 Address > > - IPv6 Address > > - Maximum Data Rate > > - Current Data Rate > > - Latency > > - Expected Forwarding Time > > - Resources > > - Relative Link Factor > > - Credit Window Status > > Neighbor Up messages would be send by router, although the draft > > mentions the router can send it also. > > Relative Link Factor should be Relative Link Quality (posted before, > > I think). In Neighbor Update, Expected Forwarding Time is missing. > > > > My comment is on the protocol. Optional data item TLVs can be present, > > or not. There was a proposal for TLV with an UNKNOWN codepoint, for RLQ. > > I don't see much difference in UNKNOWN and not sending the TLV. Then, > > this UNKNOWN applies to all optional Data Item TLVs. So if we just > > add a mechanism that enables sending UNKNOWN for all optional Data > > Item TLVs, we are done. Addresses have the drop already. The other > > TLVs can have the length=0. That's all. I provided the text already. > > > > I can't be more clear. Sorry. > > > > Teco > > > > > --14dae934038f95da2004cc041e59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 support to the below input,
=A0
and without any= router state reflect on dlep-server.
=A0
AB

On Sat, Oct 13, 2012 at 4:06 PM, Bo Berry <b= oberry@cisco.com> wrote:
Teco
Thanks, this helps. =A0So let's see what others think.
Have a great wkend.

-Bo


On Oct 13, 2012, at 10:50 AM, Teco Boot wrote:

>
> Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven:
>
>> Teco,
>> I do not understand it and it's not been described in a manner=
>> that I can. =A0But if we can not understand it, we will not be
>> successful describing it such that it can be useful.
>>
>> If you can provide meaningful, descriptive text, that would help.<= br> >> At this time, "prepare for data items that can fall back to u= nknown"
>> does not help me. =A0What do you propose as optional data items >> and how do you propose, by what mechanism, they fall back? =A0Do >> they fall back in the radio or router, or both?
>
> The optional Data Item TLVs for Neighbor Up are in the draft:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- IPv4 Address
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- IPv6 Address
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- Maximum Data Rate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- Current Data Rate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- Latency
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- Expected Forwarding Time
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- Resources
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- Relative Link Factor
> =A0 =A0 =A0 =A0 =A0 =A0 =A0- Credit Window Status
> Neighbor Up messages would be send by router, although the draft
> mentions the router can send it also.
> Relative Link Factor should be Relative Link Quality (posted before, > I think). In Neighbor Update, Expected Forwarding Time is missing.
>
> My comment is on the protocol. Optional data item TLVs can be present,=
> or not. There was a proposal for TLV with an UNKNOWN codepoint, for RL= Q.
> I don't see much difference in UNKNOWN and not sending the TLV. Th= en,
> this UNKNOWN applies to all optional Data Item TLVs. So if we just
> add a mechanism that enables sending UNKNOWN for all optional Data
> Item TLVs, we are done. Addresses have the drop already. The other
> TLVs can have the length=3D0. That's all. I provided the text alre= ady.
>
> I can't be more clear. Sorry.
>
> Teco
>


--14dae934038f95da2004cc041e59-- From abdussalambaryun@gmail.com Sun Oct 14 07:58:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E326A21F8452 for ; Sun, 14 Oct 2012 07:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkGFoU3JoRr4 for ; Sun, 14 Oct 2012 07:58:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 331C121F8459 for ; Sun, 14 Oct 2012 07:58:24 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4952416vbb.31 for ; Sun, 14 Oct 2012 07:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bEmvpidsRaUYUjs+aeEIf2OJb6r0Xl4Qx0/O5pa06Fk=; b=LdAcScnvGS3yXK9dzWtC+FGyE+ONtFK2yvHISbJ1y2n9f0pKzn50NYOcvm/+CoNUZl qh9AKCQ5tsAmmmTYAT5FSgcfZXA+d3ISsK0Lq0Wy8RAC1Z2cpPxlBEJrltlS4y4zaXTa KKqmWn3G5JGdQyuXNwVRDKvZOA6aMt5+HBQHUHIdHyv60IUu0FLPE1tuHaa4OkonZotO JumpV+eXOeA+nRNnx1TmXplrE2KFjVV2sER0QBHzfYtoGn3Sf/IuSeCZ8/0lJDBOWRcG UjjfI8PFWO1Z95nmOXIs1fW/IB/xZ3R4GX7dvbzdCH3G7T9aRzKT56aINpgCnKSzbNmS 2Q4w== MIME-Version: 1.0 Received: by 10.58.12.231 with SMTP id b7mr5538887vec.28.1350226703436; Sun, 14 Oct 2012 07:58:23 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sun, 14 Oct 2012 07:58:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Oct 2012 15:58:23 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b41bf32064a8604cc06271d Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 14:58:26 -0000 --047d7b41bf32064a8604cc06271d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 13, 2012 at 4:57 PM, Ulrich Herberg wrote: Sub: Re: [manet] MANET meeting at IETF85 > I repeat what Adrian said: some if not all LLNs are MANETs. Therefore, if > we come up with a MANET reactive protocol, it is only logical that for some > LLNs the reactive MANET protocol would be suitable as well; but clearly, > MANET should cover the general case of MANETs. > > I agree with statement: some LLNs are MANETs, and not most LLNs are MANET. However, I agree with > our WG need producing a single reactive protocol for MANETs, not for *some* MANETs. WG need to be clear that the protocol you work on is applicable across ALL MANETs not some MANETs [1]. JP> Working chair-hat on, if we have two WGs going in opposite directions for LLNs, we clearly have an overlap - this is what the chairs of ROLL and MANET want to avoid. UH>Right, and I don't see why there would be overlap. AB> I see there was an overlap when there was a claim that MANET routing are better than RPL performance in ROLL meetings, and resulted to an I-D draft [2] produced for RPL experience, with authors discussing their observation without their recommendations for RPL specification RFC6550. IMO, MANET routings are not best solutions for LLNs. The RPL [RFC6550] is the best solution so far that IETF has produced for such specific MANETs that are LLNs. [1] said at : draft-lln-loadng 15min slot Agenda, minutes of MANET-WG IETF84. [2] http://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-04 AB --047d7b41bf32064a8604cc06271d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 13, 2012 at 4:57 PM, Ulrich Herberg = <ulrich@herberg.name> wrote:
Sub: Re: [manet] MANET meeting at IETF85
I repeat what Adrian said: so= me if not all LLNs are MANETs. Therefore, if we come up with a MANET reacti= ve protocol, it is only logical that for some LLNs the reactive MANET proto= col would be suitable as well; but clearly, MANET should cover the general = case of MANETs.
=A0
=A0
I agree with statement:= some LLNs are MANETs, and not most LLNs are MANET. <some if not all LL= Ns.....The *IF* word does not mean guaranteed/confirmed>
However, I agree with > our WG need producing a single reactive pro= tocol for MANETs, not for *some* MANETs. WG need to be clear that the proto= col you work on is applicable across ALL MANETs not some MANETs [1].
=A0
JP> Working chair-hat on, if we have two WGs goi= ng in opposite directions for LLNs, we clearly have an overlap - this is wh= at the chairs of ROLL and MANET
want to avoid.

UH&= gt;Right, and I don't see why there would be overlap.
=A0
AB> I see there was an overlap when there was a claim= that MANET routing are better than RPL performance in ROLL meetings, and r= esulted to=A0an I-D draft [2]=A0produced for RPL experience, with authors d= iscussing their observation without their=A0recommendations for RPL specifi= cation RFC6550.
=A0
IMO, MANET routings are not best solutions for LLNs. The= RPL [RFC6550] is the best solution so far that IETF has produced for such = specific MANETs that are LLNs.
[1] said at : draft-lln-loadng 15min slot Agenda, minutes= of MANET-WG IETF84.
AB
--047d7b41bf32064a8604cc06271d-- From ulrich@herberg.name Sun Oct 14 08:12:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D821F84B2 for ; Sun, 14 Oct 2012 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa7Zw+SzUICJ for ; Sun, 14 Oct 2012 08:12:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4741621F845E for ; Sun, 14 Oct 2012 08:12:44 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4163226pbb.31 for ; Sun, 14 Oct 2012 08:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=41gXjcwJEnX7jkzjL+y34iFDgT+WxkHd9USvP72m5LY=; b=z21ueVwNZyEgmsLgUXJMjJRIyAiGf8g56bvK7UaStiyrpQaCMICJSvyeXnKpno/0Fl ymmuR3BbgcTsqgW+WNynp1S72v1nFSk8HypMTK4Dmg5UkxBVRGEBBwh94TJKCuIhu9BQ GlW8rUDCSWAEnSVRYFwwIE4Wob3rMifNBp98Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=41gXjcwJEnX7jkzjL+y34iFDgT+WxkHd9USvP72m5LY=; b=eieyKVkfICPcfZ/GK7+EUA/27NLz6xdFg/TDym1g3Yq/g5Zh2zw5TXcRM69G7jG5ZQ tZXbr5xfTdF4Be8PQkQBXHJEGjx7d9uXTdT0Wl1gQzaCl5j7LNxXhH11zUhuYuHPINXe S0/zRlaXjE7mQDQkrdW+UVy7Tqe3SltvHbRJg6cwdu1FUq7SlUxcXfbZchdMwJRXJHaK O7FXLebJLR8EGL2awPsumCroBr7Xh4AXf/Qv89OV6Tj+oiNgmIHL+1BA7nZmtnLbpjAF 1g/qWh2fgONXwOnM0RZmSqK39c49NaD+/vSrInmWO5LNS2JiNl1gy/5H51OnY6Ub5DJU Phow== Received: by 10.66.88.40 with SMTP id bd8mr26041886pab.36.1350227564593; Sun, 14 Oct 2012 08:12:44 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id vc2sm318674pbc.64.2012.10.14.08.12.42 (version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 08:12:43 -0700 (PDT) References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2DABBA38-1C3B-4D7A-BF41-080C8146C9EE Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Sun, 14 Oct 2012 08:12:43 -0700 To: "JP Vasseur (jvasseur)" X-Gm-Message-State: ALoCoQlP8QxOYoIKCe+UbexNk1szMYPYixXTMA1P9vihB9Rp4+xH/7L4bFcTqAGqicZc5CBJUPmg Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 15:12:46 -0000 --Apple-Mail-2DABBA38-1C3B-4D7A-BF41-080C8146C9EE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi JP, On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" wrote= : > Hi Ulrich, >=20 > On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: >=20 >> Hi C=C3=A9dric, >>=20 >> On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet w= rote: >>> [...] >>>=20 >>> The distinction between MANET and LLNs seems to be vanish here. >>> This brings us back to the summer discussion between what is a MANET and= what is a LLN that did not really fostered on a consensus. >>> WG chairs could help there, as it is their related scope. >>=20 >>=20 >> I am not suggesting to revive a discussion of the definition of a MANET v= s LLN. >=20 > JP> Mei neither - this is why, if you suggest to indicate the applicabilit= y of the protocol in the document which makes total sense, the WG should exc= lude LLNs from > this ID explicitly. I disagree. How can we exclude it from the document when it is as a matter o= f fact used in LLNs? I am just saying that if LOADng is to be accepted by t= he WG, it has been clearly expressed in the last meeting that it is too focu= sed on LLNs, and should instead focus on the general MANET case. I agree wit= h that. Mentioning one, out of many use cases, in particular when people act= ually deploy it in that use cases seems just fair, and does not cause any ov= erlap between two working groups. >=20 >> I did not bring up this discussion. All I am saying is that MANET is char= tered to come up with a reactive protocol. And I believe it should be allowe= d to mention where a protocol is used in deployments.=20 >>=20 >>=20 >> =20 >>> My vision is that LLNs are more constrained than MANET for the following= criterion : Power consumption, Loss of the media, Computation capability, T= hroughput. >>> What do you think ? >>> My vision is also that the level of constraints of LLNs should not be co= nsidered in a MANET protocol. >>> Do you agree ? >>=20 >>=20 >> Since you ask here...In my personal opinion, LLNs are a 100% subset of a= MANET. Both are usually multi-hop, often wireless, with constrained routers= , in many cases incoming packets leave a router on the same interface that t= hey have been received on, and the topology is dynamic. >=20 > JP> Well, in this case, pushing your reasoning a bit further, this may ver= y well apply to OSPF, ISIS, =E2=80=A6 too. These protocos don't cope well with lossy channels and dynamic topology chan= ges. > I clearly do not think that LLNs are 100% subset of MANET; there is a trem= endous difference between several dozens of highly constrained fixed routers= interconnected > by very lossy links providing a few KBits/s and several hundreds of router= s with high mobility interconnected by Wifi links. Nobody ever said that MANETs are interconnected by wifi only, or anything ab= out limited size of the network (quite the contrary, they are intended to be= very large). Also, MANETs such as Funkfeuer are non-mobile. >=20 >> MANETs, IMO, have a larger range of "constrained routers", from very cons= trained routers (e.g. LLN) to somewhat constrained routers (e.g. community n= etworks) to non-constrained routers (e.g. certain military deployments). LLN= is focused on extremely constrained devices. >> However, I don't say that we should revisit the way how the Routing Area d= istributed the tasks in the WGs, nor do I suggest to change the charters. >=20 > JP> IF that were the case, we would not have formed two WG but one. I don't want to go in there. >=20 >>=20 >> =20 >>>=20 >>> I'm trying to figure out if LOADng is efficient over a mains-powered com= puter using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range= would be magical !). >>=20 >> I cannot answer this question, as I have not deployed LOADng on a 8K/48K R= AM/ROM device. Those who have deployments and are willing to disclose detail= s, may have more details. Just one comment: I have implemented numerous ad-h= oc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest= to implement and has the least lines of code (by far) compared to all these= other protocols that I have implemented. If you can run any of these before= mentioned protocols on such a device, you can certainly run LOADng on it. >=20 > JP> I wish life was so simple =E2=80=A6 The argument around simplicity is a= recurring one. And unfortunately, simple protocols do not always WORK =E2=80= =A6 I could actually show > you, taking real-life networks (no simulation), how a (simple) reactive ro= uting protocol would break in a LLN. As a matter of fact, there are large-scale deployments of LOADng by industry= . If LOADng was not working, I doubt that there would be any money spent on t= hat. And your last argument is not helpful; I am convinced that for any Standards= Track routing protool, I can show you scenarios where it breaks (whereas in= other scenarios it works fine).=20 Best Ulrich >=20 >>=20 >> =20 >>>=20 >>> I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-= loadng-interoperability-report-02 in section 3 : >>> [...] >>> So my first guess is that LOADng is suitable for what I called "mains-po= wered computer using Wifi" ? >>=20 >>=20 >> I think Jiazi has already replied to that in a later mail. Interop !=3D p= erformance test. LOADng (like any other MANET protocol) can run on any mediu= m. Testing it on wifi is a simple thing to do. Interop tests are solely to f= ind out if messages can be parsed correctly, and if the implementations beha= ve according to the specification.=20 >>=20 >> As Jiazi pointed out correctly, I don't understand why we have this discu= ssion before you have seen the latest LOADng revision.=20 >>=20 >> Best >> Ulrich >> =20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-2DABBA38-1C3B-4D7A-BF41-080C8146C9EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi JP,

On Oct 14, 2012, at 0:07= , "JP Vasseur (jvasseur)" <jvasseur= @cisco.com> wrote:

Hi Ulrich,

On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote:

Hi C=C3=A9dric,

On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet <c.chauvenet= @watteco.com> wrote:
[...]

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET an= d what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.


I am not suggesting to revive a discussion of the definition of a MANET= vs LLN.

JP> Mei neither - this is why, if you suggest to indicate the applic= ability of the protocol in the document which makes total sense, the WG shou= ld exclude LLNs from
this ID explicitly.

=

I disagree. How can we exclude it from the document when= it is as a matter of fact used in LLNs?  I am just saying that if LOAD= ng is to be accepted by the WG, it has been clearly expressed in the last me= eting that it is too focused on LLNs, and should instead focus on the genera= l MANET case. I agree with that. Mentioning one, out of many use cases, in p= articular when people actually deploy it in that use cases seems just fair, a= nd does not cause any overlap between two working groups.




I did not bring up this discussion. All I am saying is that MANET is ch= artered to come up with a reactive protocol. And I believe it should be allo= wed to mention where a protocol is used in deployments. 


 
My vision is that LLNs are more constrained than MANET for the followin= g criterion : Power consumption, Loss of the media, Computation capability, T= hroughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be c= onsidered in a MANET protocol.
Do you agree ?


Since you ask here...In my personal opinion,  LLNs are a 100% subs= et of a MANET. Both are usually multi-hop, often wireless, with constrained r= outers, in many cases incoming packets leave a router on the same interface t= hat they have been received on, and the topology is dynamic.

JP> Well, in this case, pushing your reasoning a bit further, this m= ay very well apply to OSPF, ISIS, =E2=80=A6 too.


These protocos don't cope well w= ith lossy channels and dynamic topology changes.

I clearly do not think that LLNs are 100% subset of MANET; there is a t= remendous difference between several dozens of highly constrained fixed rout= ers interconnected
by very lossy links providing a few KBits/s and several hundreds of rou= ters with high mobility interconnected by Wifi links.

Nobody ever said that MANETs are interconn= ected by wifi only, or anything about limited size of the network (quite the= contrary, they are intended to be very large). Also, MANETs such as Funkfeu= er are non-mobile.



MANETs, IMO, have a larger range of "constrained routers", from very co= nstrained routers (e.g. LLN) to somewhat constrained routers (e.g. community= networks) to non-constrained routers (e.g. certain military deployments). L= LN is focused on extremely constrained devices.
However, I don't say that we should revisit the way how the Routing Are= a distributed the tasks in the WGs, nor do I suggest to change the charters.=


JP> IF that were the case, we would not have formed two WG but one.<= /div>


I don= 't want to go in there.




 

I'm trying to figure out if LOADng is efficient over a mains-powered co= mputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wide= range would be magical !).

I cannot answer this question, as I have not deployed LOADng on a 8K/48= K RAM/ROM device. Those who have deployments and are willing to disclose det= ails, may have more details. Just one comment: I have implemented numerous a= d-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest to implement and has the lea= st lines of code (by far) compared to all these other protocols that I have i= mplemented. If you can run any of these beforementioned protocols on such a d= evice, you can certainly run LOADng on it.

JP> I wish life was so simple =E2=80=A6 The argument around simplici= ty is a recurring one. And unfortunately, simple protocols do not always WOR= K =E2=80=A6 I could actually show
you, taking real-life networks (no simulation), how a (simple) reactive= routing protocol would break in a LLN.
=


As a matter of fact, there are large-scal= e deployments of LOADng by industry. If LOADng was not working, I doubt that= there would be any money spent on that.
And your last argument is= not helpful; I am convinced that for any Standards Track routing protool, I= can show you scenarios where it breaks (whereas in other scenarios it works= fine). 

Best
Ulrich

<= /div>




 

[...]
So my first guess is that LOADng is suitable for what I called "mains-p= owered computer using Wifi" ?


I think Jiazi has already replied to that in a later mail. Interop !=3D= performance test. LOADng (like any other MANET protocol) can run on any med= ium. Testing it on wifi is a simple thing to do. Interop tests are solely to= find out if messages can be parsed correctly, and if the implementations behave according to the specification= . 

As Jiazi pointed out correctly, I don't understand why we have this dis= cussion before you have seen the latest LOADng revision. 

Best
Ulrich
 
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org= /mailman/listinfo/manet

= --Apple-Mail-2DABBA38-1C3B-4D7A-BF41-080C8146C9EE-- From jvasseur@cisco.com Sun Oct 14 09:14:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC921F8459 for ; Sun, 14 Oct 2012 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2lFNg+bep3S for ; Sun, 14 Oct 2012 09:14:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 67B1D21F842B for ; Sun, 14 Oct 2012 09:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19720; q=dns/txt; s=iport; t=1350231242; x=1351440842; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rZSVZRdSV1/7ntH+HhPaYLu+ymADsiKamsQj0rEQV4Y=; b=S8ztjbRJ4YzmFGhbCSlMbRK6PGcLUexwFwPgtD+ZEKE9Z/nOuCy5LMVT TE2eVtLoZX+oTly0VKmTP4imPNJgU+Hd4fML9drzbQJmOS8U1pPxQvxi0 vNuq8KEv6hNBP0Kwfo2kPSLW/0Ys520pOzoHy7GDS2UvSWnJCV8argBrJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAL/jelCtJV2b/2dsb2JhbABEtxEBiF+BCIIhAQEEAQEBDwFbAgkQAgEIIh0HJwsUEQIEDgUIDAUJh2ILnQueb4tZFAYBhUJgA5cBjTCBa4JtgVoJNA X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208,217";a="131437895" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 14 Oct 2012 16:14:01 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9EGE1KL013267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 16:14:01 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 11:14:00 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Sun, 14 Oct 2012 16:13:59 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--48.551800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FDC303xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 16:14:05 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FDC303xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 14, 2012, at 5:12 PM, Ulrich Herberg wrote: Hi JP, On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" > wrote: Hi Ulrich, On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: Hi C=E9dric, On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet > wrote: [...] The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. I am not suggesting to revive a discussion of the definition of a MANET vs = LLN. JP> Mei neither - this is why, if you suggest to indicate the applicability= of the protocol in the document which makes total sense, the WG should exc= lude LLNs from this ID explicitly. I disagree. How can we exclude it from the document when it is as a matter = of fact used in LLNs? I am just saying that if LOADng is to be accepted by= the WG, it has been clearly expressed in the last meeting that it is too f= ocused on LLNs, and should instead focus on the general MANET case. I agree= with that. Mentioning one, out of many use cases, in particular when peopl= e actually deploy it in that use cases seems just fair, and does not cause = any overlap between two working groups. JP> This is your interpretation of the last discussion - please discuss wit= h the WG chairs of ROLL and MANET. We have the mandate to design one protoc= ol for LLN at the IETF, which leads to no overlap. If you think that the protocol = designed by the IETF (RPL) does meet the requirements, and you would like t= o see some improvements, then you are extremely welcome in ROLL, to keep improving it.= As a matter of fact, there are now several large scale deployments in prod= uction but again we can keep improving it. The "too focussed" is your interpretation, = I do no agree with it at all. Actually there are papers available showing w= hy using Load-ng may lead to serious issues in LLNs; we need to be cautious and conscious on= these issues for the best of the Internet. I did not bring up this discussion. All I am saying is that MANET is charte= red to come up with a reactive protocol. And I believe it should be allowed= to mention where a protocol is used in deployments. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? Since you ask here...In my personal opinion, LLNs are a 100% subset of a M= ANET. Both are usually multi-hop, often wireless, with constrained routers,= in many cases incoming packets leave a router on the same interface that t= hey have been received on, and the topology is dynamic. JP> Well, in this case, pushing your reasoning a bit further, this may very= well apply to OSPF, ISIS, =85 too. These protocos don't cope well with lossy channels and dynamic topology cha= nges. JP> I am sure that yo understood the analogy, I was not proposing to use OS= PF and ISIS =85 these were example to show that your characterization was n= ot a compelling argument. I clearly do not think that LLNs are 100% subset of MANET; there is a treme= ndous difference between several dozens of highly constrained fixed routers= interconnected by very lossy links providing a few KBits/s and several hundreds of routers= with high mobility interconnected by Wifi links. Nobody ever said that MANETs are interconnected by wifi only, or anything a= bout limited size of the network (quite the contrary, they are intended to = be very large). Also, MANETs such as Funkfeuer are non-mobile. JP> I was giving an example ... MANETs, IMO, have a larger range of "constrained routers", from very constr= ained routers (e.g. LLN) to somewhat constrained routers (e.g. community ne= tworks) to non-constrained routers (e.g. certain military deployments). LLN= is focused on extremely constrained devices. However, I don't say that we should revisit the way how the Routing Area di= stributed the tasks in the WGs, nor do I suggest to change the charters. JP> IF that were the case, we would not have formed two WG but one. I don't want to go in there. I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I cannot answer this question, as I have not deployed LOADng on a 8K/48K RA= M/ROM device. Those who have deployments and are willing to disclose detail= s, may have more details. Just one comment: I have implemented numerous ad-= hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simple= st to implement and has the least lines of code (by far) compared to all th= ese other protocols that I have implemented. If you can run any of these be= forementioned protocols on such a device, you can certainly run LOADng on i= t. JP> I wish life was so simple =85 The argument around simplicity is a recur= ring one. And unfortunately, simple protocols do not always WORK =85 I coul= d actually show you, taking real-life networks (no simulation), how a (simple) reactive rou= ting protocol would break in a LLN. As a matter of fact, there are large-scale deployments of LOADng by industr= y. If LOADng was not working, I doubt that there would be any money spent o= n that. And your last argument is not helpful; I am convinced that for any Standard= s Track routing protool, I can show you scenarios where it breaks (whereas = in other scenarios it works fine). JP> Then let's justify carefully why and when the current standard does not= meet the requirements, see how we can improve it if needed and then in a s= econd step seek of another protocol if required. Once again I am ONLY referring to LLN= s, not other types of networks. Best Regards. JP. Best Ulrich I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : [...] So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? I think Jiazi has already replied to that in a later mail. Interop !=3D per= formance test. LOADng (like any other MANET protocol) can run on any medium= . Testing it on wifi is a simple thing to do. Interop tests are solely to f= ind out if messages can be parsed correctly, and if the implementations beh= ave according to the specification. As Jiazi pointed out correctly, I don't understand why we have this discuss= ion before you have seen the latest LOADng revision. Best Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FDC303xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <66C16151F1989D4590D173CE9DCF6F00@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 14, 2012, at 5:12 PM, Ulrich Herberg wrote:

Hi JP,

On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Hi Ulrich,

On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote:

Hi C=E9dric,

On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
[...]

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.


I am not suggesting to revive a discussion of the definition of a MANE= T vs LLN.

JP> Mei neither - this is why, if you suggest to indicate the appli= cability of the protocol in the document which makes total sense, the WG sh= ould exclude LLNs from
this ID explicitly.


I disagree. How can we exclude it from the document when it is as a ma= tter of fact used in LLNs?  I am just saying that if LOADng is to be a= ccepted by the WG, it has been clearly expressed in the last meeting that i= t is too focused on LLNs, and should instead focus on the general MANET case. I agree with that. Mentioning one= , out of many use cases, in particular when people actually deploy it in th= at use cases seems just fair, and does not cause any overlap between two wo= rking groups.

JP> This is your interpretation of the last discussion - please dis= cuss with the WG chairs of ROLL and MANET. We have the mandate to design on= e protocol for
LLN at the IETF, which leads to no overlap. If you think that the prot= ocol designed by the IETF (RPL) does meet the requirements, and you would l= ike to see some
improvements, then you are extremely welcome in ROLL, to keep improvin= g it. As a matter of fact, there are now several large scale deployments in= production but
again we can keep improving it. The "too focussed" is your i= nterpretation, I do no agree with it at all. Actually there are papers avai= lable showing why using Load-ng
may lead to serious issues in LLNs; we need to be cautious and conscio= us on these issues for the best of the Internet.





I did not bring up this discussion. All I am saying is that MANET is c= hartered to come up with a reactive protocol. And I believe it should be al= lowed to mention where a protocol is used in deployments. 


 
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?


Since you ask here...In my personal opinion,  LLNs are a 100% sub= set of a MANET. Both are usually multi-hop, often wireless, with constraine= d routers, in many cases incoming packets leave a router on the same interf= ace that they have been received on, and the topology is dynamic.

JP> Well, in this case, pushing your reasoning a bit further, this = may very well apply to OSPF, ISIS, =85 too.


These protocos don't cope well with lossy channels and dynamic topolog= y changes.

JP> I am sure that yo understood the analogy, I was not proposing t= o use OSPF and ISIS =85 these were example to show that your characterizati= on was not a compelling
argument.


I clearly do not think that LLNs are 100% subset of MANET; there is a = tremendous difference between several dozens of highly constrained fixed ro= uters interconnected
by very lossy links providing a few KBits/s and several hundreds of ro= uters with high mobility interconnected by Wifi links.

Nobody ever said that MANETs are interconnected by wifi only, or anyth= ing about limited size of the network (quite the contrary, they are intende= d to be very large). Also, MANETs such as Funkfeuer are non-mobile.


JP> I was giving an example ...



MANETs, IMO, have a larger range of "constrained routers", f= rom very constrained routers (e.g. LLN) to somewhat constrained routers (e.= g. community networks) to non-constrained routers (e.g. certain military de= ployments). LLN is focused on extremely constrained devices.
However, I don't say that we should revisit the way how the Routing Ar= ea distributed the tasks in the WGs, nor do I suggest to change the charter= s.


JP> IF that were the case, we would not have formed two WG but one.=


I don't want to go in there.




 

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).

I cannot answer this question, as I have not deployed LOADng on a 8K/4= 8K RAM/ROM device. Those who have deployments and are willing to disclose d= etails, may have more details. Just one comment: I have implemented numerou= s ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest to implement and has the le= ast lines of code (by far) compared to all these other protocols that I hav= e implemented. If you can run any of these beforementioned protocols on suc= h a device, you can certainly run LOADng on it.

JP> I wish life was so simple =85 The argument around simplicity is= a recurring one. And unfortunately, simple protocols do not always WORK = =85 I could actually show
you, taking real-life networks (no simulation), how a (simple) reactiv= e routing protocol would break in a LLN.


As a matter of fact, there are large-scale deployments of LOADng by in= dustry. If LOADng was not working, I doubt that there would be any money sp= ent on that.
And your last argument is not helpful; I am convinced that for any Sta= ndards Track routing protool, I can show you scenarios where it breaks (whe= reas in other scenarios it works fine). 

JP> Then let's justify carefully why and when the current standard = does not meet the requirements, see how we can improve it if needed and the= n in a second step
seek of another protocol if required. Once again I am ONLY referring t= o LLNs, not other types of networks.

Best Regards.

JP.


Best
Ulrich





 


I think Jiazi has already replied to that in a later mail. Interop != =3D performance test. LOADng (like any other MANET protocol) can run on any= medium. Testing it on wifi is a simple thing to do. Interop tests are sole= ly to find out if messages can be parsed correctly, and if the implementations behave according to the specificatio= n. 

As Jiazi pointed out correctly, I don't understand why we have this di= scussion before you have seen the latest LOADng revision. 

Best
Ulrich
 
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A7721FDC303xmbrcdx02ciscoc_-- From sratliff@cisco.com Sun Oct 14 16:52:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA1721F853F for ; Sun, 14 Oct 2012 16:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwdf7M95-QhL for ; Sun, 14 Oct 2012 16:52:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 716AF21F853E for ; Sun, 14 Oct 2012 16:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8614; q=dns/txt; s=iport; t=1350258767; x=1351468367; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ugbhnyKllVoz2Lg0iC0bfQCkvfMIUuRcOiKtuRfgGCo=; b=mcGLHEgouqqo+U2TId34oHEOzOdyCAx9WXiZyozzG+m42PAk/zFWuKS/ 7Mg6RGUk3vVX/wK7TKf8RVVyioepLm7lt1PyVx+N9coDwN/Z24f4BLhlL fV3bgwm+lxlGKFPUAHLxlsNbORn6LYFYOBsef/mcoHxpn/vrupyuxzOgY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMNPe1CtJV2c/2dsb2JhbABFtxQBiF+BCIIgAQEBAwEBAQEPAVsLEAIBCCIdBycLFBECBA4FCAEZh1wGC50ZnnqLWYVdYAOXAY0wgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,584,1344211200"; d="scan'208,217";a="131525944" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 14 Oct 2012 23:52:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9ENqRfJ030786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 23:52:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 18:52:27 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-17.txt Thread-Index: AQHNqeaAQt30JmGHYEug61NNK5qhMpe5BIOAgAAJEwCAAMBbAA== Date: Sun, 14 Oct 2012 23:52:26 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CDA0@xmb-aln-x03.cisco.com> References: <20121014083210.15023.95664.idtracker@ietfa.amsl.com> <3E1A43EF-789E-4DE3-AA1B-E67BA445E044@thomasclausen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--45.883600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CDA0xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 23:52:48 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CDA0xmbalnx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Abdussalam, This is just how the IETF process works. As a function of the AD review, so= me clarifications to the text were requested. The way to deal with that is = to submit an updated version=85 Essentially what this means is that the authors have responded to AD issues= , and the draft is progressing. The additional version notwithstanding, thi= s reflects progress, and i thank the authors for working the issues through= . Regards, Stan On Oct 14, 2012, at 8:23 AM, Abdussalam Baryun wrote: Thanks to inform us, however, I recommend to reduce the number of revision = if possible, and we get more feedback from IESG each DISCUSS position, befo= re re-issuing I-Ds. AB On Sun, Oct 14, 2012 at 12:51 PM, Thomas Heide Clausen > wrote: For information, this revision contains clarifications as requested by the = IESG during their review of the document. There are no functional changes t= o the protocol. The SEC AD has made comments, which have so far not been reflected in the d= ocument, but will be reflected in a future revision, following (ongoing) di= scussions between the authors, the SEC AD and Adrian. Best, Thomas Sent from my iPad On 14 oct. 2012, at 10:32, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of = the IETF. > > Title : The Optimized Link State Routing Protocol version 2 > Author(s) : Thomas Heide Clausen > Christopher Dearlove > Philippe Jacquet > Ulrich Herberg > Filename : draft-ietf-manet-olsrv2-17.txt > Pages : 110 > Date : 2012-10-14 > > Abstract: > This specification describes version 2 of the Optimized Link State > Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-17 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CDA0xmbalnx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <23FD7EEF482C3A4D81EF4EA73CA178FA@cisco.com> Content-Transfer-Encoding: quoted-printable Abdussalam, 

This is just how the IETF process works. As a function of the AD revie= w, some clarifications to the text were requested. The way to deal with tha= t is to submit an updated version=85 
Essentially what this means is that the authors have responded to AD i= ssues, and the draft is progressing. The additional version notwithstanding= , this reflects progress, and i thank the authors for working the issues th= rough. 

Regards,
Stan

On Oct 14, 2012, at 8:23 AM, Abdussalam Baryun wrote:

Thanks to inform us, however, I recommend to reduce the number of revi= sion if possible, and we get more feedback from IESG each DISCUSS position,=  before re-issuing I-Ds.
 
AB
On Sun, Oct 14, 2012 at 12:51 PM, Thomas Heide C= lausen <ietf@thomas= clausen.org> wrote:
For information, this revision contains clarifications as requested by the = IESG during their review of the document. There are no functional changes t= o the protocol.

The SEC AD has made comments, which have so far not been reflected in the d= ocument, but will be reflected in a future revision, following (ongoing) di= scussions between the authors, the SEC AD and Adrian.

Best,

Thomas

Sent from my iPad

On 14 oct. 2012, at 10:32, inte= rnet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF.
>
>    Title           : The Optimized = Link State Routing Protocol version 2
>    Author(s)       : Thomas Heide Clausen
>                     =      Christopher Dearlove
>                     =      Philippe Jacquet
>                     =      Ulrich Herberg
>    Filename        : draft-ietf-manet-ol= srv2-17.txt
>    Pages           : 110
>    Date            : 2012-10-1= 4
>
> Abstract:
>   This specification describes version 2 of the Optimized Link St= ate
>   Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).<= br> >
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-17
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

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

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CDA0xmbalnx03ciscoc_-- From jpmacker@gmail.com Sun Oct 14 16:54:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1A21F8510 for ; Sun, 14 Oct 2012 16:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN-cYrN7ARmP for ; Sun, 14 Oct 2012 16:54:45 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9C21F8499 for ; Sun, 14 Oct 2012 16:54:45 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so5410234oag.31 for ; Sun, 14 Oct 2012 16:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=TCXOq/nK/8jR6KeiYSZUd8MaJA2fj0cYxuqUew9We74=; b=NGWImh5oLJfoaJrhHaAy0p/gzAa1WwTdQOGfSqaffmyiaMTX+Kjkgu07np6qBlxPs1 eKxh6ifaGta9jgF0N2r7I9EqttHqrnLvBoUzdYmuXL9NSXngIjnmflqyKwoRFOvmm37Y ITwRFv+pL+4s9WKrnVC45SYiH3Rh/50C5sQK2yIt+MrQDLZdcx07zvK78NzpzLC98Q+x JPAZFc1N90VaY/bQO6154PVzM73rUyD1psXXABmNCVTD3aMKBgMaG61j76psG8Ig5yEF BcSEb0abxRBjOJrfvak/MTqkeDrMWjgJeyWaMiAq9E/M35C8r7hqxRL29aH+iRuJSneA yrTA== Received: by 10.60.169.137 with SMTP id ae9mr8270202oec.91.1350258884778; Sun, 14 Oct 2012 16:54:44 -0700 (PDT) Received: from [10.97.132.205] ([32.149.193.222]) by mx.google.com with ESMTPS id th3sm13405333obb.6.2012.10.14.16.54.42 (version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 16:54:44 -0700 (PDT) References: <20121014083210.15023.95664.idtracker@ietfa.amsl.com> <3E1A43EF-789E-4DE3-AA1B-E67BA445E044@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CDA0@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CDA0@xmb-aln-x03.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-5DB7C74D-E14D-423A-AB81-5B8F80D3599E Content-Transfer-Encoding: 7bit Message-Id: <8DD4084E-1613-42CB-9716-4AD182370592@gmail.com> X-Mailer: iPhone Mail (10A403) From: Joe Macker Date: Sun, 14 Oct 2012 19:55:06 -0400 To: "Stan Ratliff (sratliff)" Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 23:54:46 -0000 --Apple-Mail-5DB7C74D-E14D-423A-AB81-5B8F80D3599E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agreed thanks to authors for work in submitting changes Sent from my iPhone On Oct 14, 2012, at 7:52 PM, "Stan Ratliff (sratliff)" w= rote: > Abdussalam,=20 >=20 > This is just how the IETF process works. As a function of the AD review, s= ome clarifications to the text were requested. The way to deal with that is t= o submit an updated version=E2=80=A6=20 > Essentially what this means is that the authors have responded to AD issue= s, and the draft is progressing. The additional version notwithstanding, thi= s reflects progress, and i thank the authors for working the issues through.= =20 >=20 > Regards, > Stan >=20 > On Oct 14, 2012, at 8:23 AM, Abdussalam Baryun wrote: >=20 >> Thanks to inform us, however, I recommend to reduce the number of revisio= n if possible, and we get more feedback from IESG each DISCUSS position, bef= ore re-issuing I-Ds. >> =20 >> AB >> On Sun, Oct 14, 2012 at 12:51 PM, Thomas Heide Clausen wrote: >>> For information, this revision contains clarifications as requested by t= he IESG during their review of the document. There are no functional changes= to the protocol. >>>=20 >>> The SEC AD has made comments, which have so far not been reflected in th= e document, but will be reflected in a future revision, following (ongoing) d= iscussions between the authors, the SEC AD and Adrian. >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>> Sent from my iPad >>>=20 >>> On 14 oct. 2012, at 10:32, internet-drafts@ietf.org wrote: >>>=20 >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>> > This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF. >>> > >>> > Title : The Optimized Link State Routing Protocol version= 2 >>> > Author(s) : Thomas Heide Clausen >>> > Christopher Dearlove >>> > Philippe Jacquet >>> > Ulrich Herberg >>> > Filename : draft-ietf-manet-olsrv2-17.txt >>> > Pages : 110 >>> > Date : 2012-10-14 >>> > >>> > Abstract: >>> > This specification describes version 2 of the Optimized Link State >>> > Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 >>> > >>> > There's also a htmlized version available at: >>> > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17 >>> > >>> > A diff from the previous version is available at: >>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-17 >>> > >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ >>> > >>> > _______________________________________________ >>> > manet mailing list >>> > manet@ietf.org >>> > https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-5DB7C74D-E14D-423A-AB81-5B8F80D3599E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Agreed thanks to authors for work in s= ubmitting changes

Sent from my iPhone

On Oct 14, 2012, a= t 7:52 PM, "Stan Ratliff (sratliff)" <sratliff@cisco.com> wrote:

=
Abdussalam, 

This is just how the IETF process works. As a function of the AD review= , some clarifications to the text were requested. The way to deal with that i= s to submit an updated version=E2=80=A6 
Essentially what this means is that the authors have responded to AD is= sues, and the draft is progressing. The additional version notwithstanding, t= his reflects progress, and i thank the authors for working the issues throug= h. 

Regards,
Stan

On Oct 14, 2012, at 8:23 AM, Abdussalam Baryun wrote:

Thanks to inform us, however, I recommend to reduce the number of revis= ion if possible, and we get more feedback from IESG each DISCUSS position,&n= bsp;before re-issuing I-Ds.
 
AB
On Sun, Oct 14, 2012 at 12:51 PM, Thomas Heide Cl= ausen <ietf@thomasc= lausen.org> wrote:
For information, this revision contains clarifications as requested by the I= ESG during their review of the document. There are no functional changes to t= he protocol.

The SEC AD has made comments, which have so far not been reflected in the do= cument, but will be reflected in a future revision, following (ongoing) disc= ussions between the authors, the SEC AD and Adrian.

Best,

Thomas

Sent from my iPad

On 14 oct. 2012, at 10:32, inter= net-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
> This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF.
>
>    Title           : The Optimized L= ink State Routing Protocol version 2
>    Author(s)       : Thomas Heide Clausen
>                     &= nbsp;    Christopher Dearlove
>                     &= nbsp;    Philippe Jacquet
>                     &= nbsp;    Ulrich Herberg
>    Filename        : draft-ietf-manet-ols= rv2-17.txt
>    Pages           : 110
>    Date            : 2012-10-14=
>
> Abstract:
>   This specification describes version 2 of the Optimized Link Sta= te
>   Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). >
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-17
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-17
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:/= /ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

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

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-5DB7C74D-E14D-423A-AB81-5B8F80D3599E-- From sratliff@cisco.com Sun Oct 14 17:08:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB6221F8496 for ; Sun, 14 Oct 2012 17:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai+D0zQV+AeC for ; Sun, 14 Oct 2012 17:08:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1844E21F8449 for ; Sun, 14 Oct 2012 17:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6866; q=dns/txt; s=iport; t=1350259712; x=1351469312; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=C2chAxWlQd9/uFS4z/b8jEGxfwMm2sv6tXU09R+qrtA=; b=kEe82ADduM4JBOczqofR4ENJ1GvaVT3ZOooTerUg0VMMbsIaBjJ0ZkWC R7Wv/kh+SDbbviSYmGBZrIcMdQXz0eUxlYdzxOGUAyvBD6D1J0eE5XZSK G3QANckTMQ7F5GpDgjlEPyMa0XD3Z7lv9mEZk8xFWi3Kpnuj123yuDTLZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACJTe1CtJXG9/2dsb2JhbABFv3SBCIIgAQEBAwEBAQEPAVsLBQ0BCA4KCksLJQIECgQFCBqHXAYLnRyeeASLWRSFSWADpDGBa4JtgVoJNA X-IronPort-AV: E=Sophos;i="4.80,584,1344211200"; d="scan'208";a="131470887" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2012 00:08:31 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9F08VO6030396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 00:08:31 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 19:08:30 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4CAAAUlAIAAE+oAgAAjnQCAAAVpAIAAASmAgADq2wCAAELQAIAAFCoAgAAUKgCAAAbRAIAABH6AgAE84wCAAOzCgA== Date: Mon, 15 Oct 2012 00:08:30 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--52.222000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <92615F365C22E040A1F3845CF2460358@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 00:08:33 -0000 I've asked twice now (this email makes attempt number 3) for someone to sug= gest some text to clarify what a router or modem would do with an UNKNOWN m= etric. So far, what I've seen is a potentially new *way* of specifying UNKN= OWN - one that makes more sense than picking some arbitrary code point. But= no actual text to suggest what either of the endpoints would *do* with the= data. Maybe I'm old, feeble, and not very bright - but I'm looking for sug= gestions that start with "A router receiving a metric value of UNKNOWN MUST= =85" or "An implementation receiving an UNKNOWN indication SHOULD=85" or so= mething along those lines. Barring that, the only text I've got to insert i= s what I suggested before:=20 >=20 > "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ i= s supported, but not currently calculable. The authors have no idea under w= hat circumstances this would occur. Routers receiving a value of RLQ_UNKNOW= N are free to take any action deemed appropriate, including (but not limite= d to) ignoring the value, producing log messages, or bursting into flames. = The RLQ_UNKNOWN (TBD) value was added at the request of the working group, = as consensus formed around the key ideas that this MAY allow for innovation= , even though none of the working group members were able to note a set of = circumstances under which this innovation might take place. So, in an effor= t to stop the email storm, the authors added the additional code point." >=20 Stan On Oct 14, 2012, at 6:01 AM, Henning Rogge wrote: > I think the idea is not bad. >=20 > IF we decide to use a special codepoint for "unknown TLV value", using > "length =3D 0" would give us a generic way for doing it for all kind of > additional metric TLVs... instead of doing this "what to use for > UNKNOWN" brainstorming again. >=20 > It also makes it easier to include the UNKNOWN codepoint into metrics > which have no bits/values left. >=20 > Henning Rogge >=20 > On Sat, Oct 13, 2012 at 5:06 PM, Bo Berry wrote: >> Teco >> Thanks, this helps. So let's see what others think. >> Have a great wkend. >>=20 >> -Bo >>=20 >>=20 >> On Oct 13, 2012, at 10:50 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: >>>=20 >>>> Teco, >>>> I do not understand it and it's not been described in a manner >>>> that I can. But if we can not understand it, we will not be >>>> successful describing it such that it can be useful. >>>>=20 >>>> If you can provide meaningful, descriptive text, that would help. >>>> At this time, "prepare for data items that can fall back to unknown" >>>> does not help me. What do you propose as optional data items >>>> and how do you propose, by what mechanism, they fall back? Do >>>> they fall back in the radio or router, or both? >>>=20 >>> The optional Data Item TLVs for Neighbor Up are in the draft: >>> - IPv4 Address >>> - IPv6 Address >>> - Maximum Data Rate >>> - Current Data Rate >>> - Latency >>> - Expected Forwarding Time >>> - Resources >>> - Relative Link Factor >>> - Credit Window Status >>> Neighbor Up messages would be send by router, although the draft >>> mentions the router can send it also. >>> Relative Link Factor should be Relative Link Quality (posted before, >>> I think). In Neighbor Update, Expected Forwarding Time is missing. >>>=20 >>> My comment is on the protocol. Optional data item TLVs can be present, >>> or not. There was a proposal for TLV with an UNKNOWN codepoint, for RLQ= . >>> I don't see much difference in UNKNOWN and not sending the TLV. Then, >>> this UNKNOWN applies to all optional Data Item TLVs. So if we just >>> add a mechanism that enables sending UNKNOWN for all optional Data >>> Item TLVs, we are done. Addresses have the drop already. The other >>> TLVs can have the length=3D0. That's all. I provided the text already. >>>=20 >>> I can't be more clear. Sorry. >>>=20 >>> Teco >>>=20 >>>>=20 >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: >>>>=20 >>>>> DLEP is (mainly) getting the neighbor information base from radio to >>>>> router, as accurate as possible. It is up to the router to use this f= or >>>>> route calculation. >>>>>=20 >>>>> This discussion is not about using RFC 5444. >>>>>=20 >>>>> It is about transfer of "hey there, I don't have this info anymore". >>>>> Bo and Stan say, this is not needed. Others say, there is a need for = it. >>>>> I agree with the others, because I cannot see a reason a radio is onl= y >>>>> allowed *once* during neighbor_up state to miss data items. We better >>>>> prepare for data items that can fall back to unknown. I say: let's al= low >>>>> this for all optional data items. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>> Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende geschr= even: >>>>>=20 >>>>>> I agree we should design for the present MANET technologies and >>>>>> future, for the protocol completion. Do you mean router-state as the >>>>>> DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don'= t >>>>>> understand why we need to consider router states. >>>>>>=20 >>>>>> DLEP considers the session between server and client states, other >>>>>> states are not inscope. For simplicity, DLEP should be abstract from >>>>>> MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an >>>>>> optional future interaction may be useful but complicated (will need >>>>>> RFC5444). >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>> On 10/13/12, Teco Boot wrote: >>>>>>>=20 >>>>>> My point is that the DLEP protocol should be "complete", in that the >>>>>> radio is able to get the router in a certain state, in another state >>>>>> and get back in the earlier state. RLQ is just an example. >>>>>>=20 >>>>>> If you think this makes no sense with the radios you have seen up to >>>>>> now, you could be right. Tomorrow, you could have a different opinio= n. >>>>>> I saw on this mailing list some of us see already the requirement th= e >>>>>> protocol shall be "complete". >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Sun Oct 14 17:57:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC8921F853C for ; Sun, 14 Oct 2012 17:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MNxc7q3SuNZ for ; Sun, 14 Oct 2012 17:57:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4480621F853B for ; Sun, 14 Oct 2012 17:57:13 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so5218312vbb.31 for ; Sun, 14 Oct 2012 17:57:12 -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=+y+o1MuYN8Ergp5eOTgpGzougkvbQs+5ROyUE1uORPQ=; b=jm09BE5FP+OeutTPjC9QyttefZm2JfMOw5Db1U2rxHlXOcxn/rti5c7losm/PfjxWs r4GorW6oxmJbPwwNYQmKPn2bpYmCPTrGJZmllQF6nSyrmiK6ViX5l+GcmUrh6E0hFW7i 8tLmdFiV2pnOAnubxHdIT16yaXInJXlavAx3c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+y+o1MuYN8Ergp5eOTgpGzougkvbQs+5ROyUE1uORPQ=; b=PLpdURyBlrL9pksK/o5ccZZWAG95gsPFZDa/J66GKCdfo7bPRd8SbKWXyhLXgLu/DS r4f4I0ANwfgvS7qDN6CMY0P3hAvvzWlTL9oz/dSPkEiHqGJQL/qdA0DCR2rFSGTQduXZ /KYerGeHcNglaePH1q0bKIu1yx2/Q2lTVOep5UCMmhbDEnb0rNBekW2mLbVJ6XkwOgRH cbwYQyVNJrGDiChVOo/o8nBmXhIezti7U8NNYQLhXI0DX/J1yX5OqR3x3JsjpoqupnH1 lsXxvIut37CTebhN8+RPPDHETBXlTOt2Wpum8gQxsTY2gQV+U2zngmKrxj9FIiB9Mixb dIzg== MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr4822156vdb.95.1350262632680; Sun, 14 Oct 2012 17:57:12 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Sun, 14 Oct 2012 17:57:12 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> Date: Sun, 14 Oct 2012 17:57:12 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=20cf3071c69c930e7504cc0e8450 X-Gm-Message-State: ALoCoQnFe4/jRCmJ7jpqxCkauh0QgVKrlAqR7zes26DqXAzBzmmBnndMm1ZUg4s6Kbez+fFQZMwO Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 00:57:15 -0000 --20cf3071c69c930e7504cc0e8450 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP, I think this discussion diverges into a comparison proactive vs. reactive protocols. I do not doubt that you can show me proof that in certain scenarios, reactive protocols perform poorly. I can do the same exercise for proactive protocols in other scenarios. MANET has gone though that about 10 years ago, and decided that "no-one-size-fits-all", but rather that we were chartered to produce a std. track reactive protocols *and* a std. track proactive protocol. And I think this is the most important argument in this discussion: MANET is chartered to come up with a reactive protocol for MANETs. And I believe it is a good idea to mention in which deployments a specification is used. It was also agreed at the last MANET meeting that if LOADng was to be considered for MANET, it needs to de-emphasize LLNs (which I have not heard anybody disagree with so far). So I don't understand what we are even discussing here. Best regards Ulrich On Sun, Oct 14, 2012 at 9:13 AM, JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > On Oct 14, 2012, at 5:12 PM, Ulrich Herberg wrote: > > Hi JP, > > On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" > wrote: > > Hi Ulrich, > > On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: > > Hi C=E9dric, > > On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet wr= ote: > >> [...] >> >> >> The distinction between MANET and LLNs seems to be vanish here. >> This brings us back to the summer discussion between what is a MANET and >> what is a LLN that did not really fostered on a consensus. >> WG chairs could help there, as it is their related scope. >> > > > I am not suggesting to revive a discussion of the definition of a MANET > vs LLN. > > > JP> Mei neither - this is why, if you suggest to indicate the > applicability of the protocol in the document which makes total sense, th= e > WG should exclude LLNs from > this ID explicitly. > > > > I disagree. How can we exclude it from the document when it is as a > matter of fact used in LLNs? I am just saying that if LOADng is to be > accepted by the WG, it has been clearly expressed in the last meeting tha= t > it is too focused on LLNs, and should instead focus on the general MANET > case. I agree with that. Mentioning one, out of many use cases, in > particular when people actually deploy it in that use cases seems just > fair, and does not cause any overlap between two working groups. > > > JP> This is your interpretation of the last discussion - please discuss > with the WG chairs of ROLL and MANET. We have the mandate to design one > protocol for > LLN at the IETF, which leads to no overlap. If you think that the protoco= l > designed by the IETF (RPL) does meet the requirements, and you would like > to see some > improvements, then you are extremely welcome in ROLL, to keep improving > it. As a matter of fact, there are now several large scale deployments in > production but > again we can keep improving it. The "too focussed" is your interpretation= , > I do no agree with it at all. Actually there are papers available showing > why using Load-ng > may lead to serious issues in LLNs; we need to be cautious and conscious > on these issues for the best of the Internet. > > > > > > I did not bring up this discussion. All I am saying is that MANET is > chartered to come up with a reactive protocol. And I believe it should be > allowed to mention where a protocol is used in deployments. > > > > >> My vision is that LLNs are more constrained than MANET for the >> following criterion : Power consumption, Loss of the media, Computation >> capability, Throughput. >> What do you think ? >> My vision is also that the level of constraints of LLNs should not be >> considered in a MANET protocol. >> Do you agree ? >> > > > Since you ask here...In my personal opinion, LLNs are a 100% subset of > a MANET. Both are usually multi-hop, often wireless, with constrained > routers, in many cases incoming packets leave a router on the same > interface that they have been received on, and the topology is dynamic. > > > JP> Well, in this case, pushing your reasoning a bit further, this may > very well apply to OSPF, ISIS, =85 too. > > > > These protocos don't cope well with lossy channels and dynamic topology > changes. > > > JP> I am sure that yo understood the analogy, I was not proposing to use > OSPF and ISIS =85 these were example to show that your characterization w= as > not a compelling > argument. > > > I clearly do not think that LLNs are 100% subset of MANET; there is a > tremendous difference between several dozens of highly constrained fixed > routers interconnected > by very lossy links providing a few KBits/s and several hundreds of > routers with high mobility interconnected by Wifi links. > > > Nobody ever said that MANETs are interconnected by wifi only, or > anything about limited size of the network (quite the contrary, they are > intended to be very large). Also, MANETs such as Funkfeuer are non-mobile= . > > > JP> I was giving an example ... > > > > MANETs, IMO, have a larger range of "constrained routers", from very > constrained routers (e.g. LLN) to somewhat constrained routers (e.g. > community networks) to non-constrained routers (e.g. certain military > deployments). LLN is focused on extremely constrained devices. > However, I don't say that we should revisit the way how the Routing Area > distributed the tasks in the WGs, nor do I suggest to change the charters= . > > > JP> IF that were the case, we would not have formed two WG but one. > > > > I don't want to go in there. > > > > > > >> >> I'm trying to figure out if LOADng is efficient over a mains-powered >> computer using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wid= e >> range would be magical !). >> > > I cannot answer this question, as I have not deployed LOADng on a 8K/48K > RAM/ROM device. Those who have deployments and are willing to disclose > details, may have more details. Just one comment: I have implemented > numerous ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by > far the simplest to implement and has the least lines of code (by far) > compared to all these other protocols that I have implemented. If you can > run any of these beforementioned protocols on such a device, you can > certainly run LOADng on it. > > > JP> I wish life was so simple =85 The argument around simplicity is a > recurring one. And unfortunately, simple protocols do not always WORK =85= I > could actually show > you, taking real-life networks (no simulation), how a (simple) reactive > routing protocol would break in a LLN. > > > > As a matter of fact, there are large-scale deployments of LOADng by > industry. If LOADng was not working, I doubt that there would be any mone= y > spent on that. > And your last argument is not helpful; I am convinced that for any > Standards Track routing protool, I can show you scenarios where it breaks > (whereas in other scenarios it works fine). > > > JP> Then let's justify carefully why and when the current standard does > not meet the requirements, see how we can improve it if needed and then i= n > a second step > seek of another protocol if required. Once again I am ONLY referring to > LLNs, not other types of networks. > > Best Regards. > > JP. > > > Best > Ulrich > > > > > > > >> >> I see in the interop report >> http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repo= rt-02 in >> section 3 : >> >> [...] >> >> So my first guess is that LOADng is suitable for what I called >> "mains-powered computer using Wifi" ? >> > > > I think Jiazi has already replied to that in a later mail. Interop !=3D > performance test. LOADng (like any other MANET protocol) can run on any > medium. Testing it on wifi is a simple thing to do. Interop tests are > solely to find out if messages can be parsed correctly, and if the > implementations behave according to the specification. > > As Jiazi pointed out correctly, I don't understand why we have this > discussion before you have seen the latest LOADng revision. > > Best > Ulrich > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > --20cf3071c69c930e7504cc0e8450 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP,

I think this discussion diverges into a compariso= n proactive vs. reactive protocols. I do not doubt that you can show me pro= of that in certain scenarios, reactive protocols perform poorly. I can do t= he same exercise for proactive protocols in other scenarios. MANET has gone= though that about 10 years ago, and decided that "no-one-size-fits-al= l", but rather that we were chartered to produce a std. track reactive= protocols *and* a=A0std. track=A0proactive protocol.

And I think this is the most important argument in this= discussion: MANET is chartered to come up with a reactive protocol for MAN= ETs. And I believe it is a good idea to mention in which deployments a spec= ification is used.=A0
It was also agreed at the last MANET meeting that if LOADng was to be = considered for MANET, it needs to de-emphasize LLNs (which I have not heard= anybody disagree with so far). So I don't understand what we are even = discussing here.=A0

Best regards
Ulrich


On Sun, Oct 14, 2012 at 9:13 AM, JP Vasseur (jvasseur) = <jvasseur@cisco.com> wrote:
Hi Ulrich,

On Oct 14, 2012, at 5:12 PM, Ulrich Herberg wrote:

Hi JP,

On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wro= te:

Hi Ulrich,

On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote:

Hi C=E9dric,

On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
[...]

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.


I am not suggesting to revive a discussion of the definition of a MANE= T vs LLN.

JP> Mei neither - this is why, if you suggest to indicate the appli= cability of the protocol in the document which makes total sense, the WG sh= ould exclude LLNs from
this ID explicitly.


I disagree. How can we exclude it from the document when it is as a ma= tter of fact used in LLNs? =A0I am just saying that if LOADng is to be acce= pted by the WG, it has been clearly expressed in the last meeting that it i= s too focused on LLNs, and should instead focus on the general MANET case. I agree with that. Mentioning one= , out of many use cases, in particular when people actually deploy it in th= at use cases seems just fair, and does not cause any overlap between two wo= rking groups.

JP> This is your interpretation of the last discussion - plea= se discuss with the WG chairs of ROLL and MANET. We have the mandate to des= ign one protocol for
LLN at the IETF, which leads to no overlap. If you think that the prot= ocol designed by the IETF (RPL) does meet the requirements, and you would l= ike to see some
improvements, then you are extremely welcome in ROLL, to keep improvin= g it. As a matter of fact, there are now several large scale deployments in= production but
again we can keep improving it. The "too focussed" is your i= nterpretation, I do no agree with it at all. Actually there are papers avai= lable showing why using Load-ng
may lead to serious issues in LLNs; we need to be cautious and conscio= us on these issues for the best of the Internet.





I did not bring up this discussion. All I am saying is that MANET is c= hartered to come up with a reactive protocol. And I believe it should be al= lowed to mention where a protocol is used in deployments.=A0


=A0
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?


Since you ask here...In my personal opinion, =A0LLNs are a 100% subset= of a MANET. Both are usually multi-hop, often wireless, with constrained r= outers, in many cases incoming packets leave a router on the same interface= that they have been received on, and the topology is dynamic.

JP> Well, in this case, pushing your reasoning a bit further, this = may very well apply to OSPF, ISIS, =85 too.


These protocos don't cope well with lossy channels and dynamic top= ology changes.

JP> I am sure that yo understood the analogy, I was not propo= sing to use OSPF and ISIS =85 these were example to show that your characte= rization was not a compelling
argument.


I clearly do not think that LLNs are 100% subset of MANET; there is a = tremendous difference between several dozens of highly constrained fixed ro= uters interconnected
by very lossy links providing a few KBits/s and several hundreds of ro= uters with high mobility interconnected by Wifi links.

Nobody ever said that MANETs are interconnected by wifi only, or anyth= ing about limited size of the network (quite the contrary, they are intende= d to be very large). Also, MANETs such as Funkfeuer are non-mobile.


JP> I was giving an example ...



MANETs, IMO, have a larger range of "constrained routers", f= rom very constrained routers (e.g. LLN) to somewhat constrained routers (e.= g. community networks) to non-constrained routers (e.g. certain military de= ployments). LLN is focused on extremely constrained devices.
However, I don't say that we should revisit the way how the Routin= g Area distributed the tasks in the WGs, nor do I suggest to change the cha= rters.


JP> IF that were the case, we would not have formed two WG but one.=


I don't want to go in there.




=A0

I'm trying to figure out if LOADng is efficient over a mains-power= ed computer using Wifi, a 8K/48K RAM/ROM device, =A0or both (cover such a w= ide range would be magical !).

I cannot answer this question, as I have not deployed LOADng on a 8K/4= 8K RAM/ROM device. Those who have deployments and are willing to disclose d= etails, may have more details. Just one comment: I have implemented numerou= s ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest to implement and has the le= ast lines of code (by far) compared to all these other protocols that I hav= e implemented. If you can run any of these beforementioned protocols on suc= h a device, you can certainly run LOADng on it.

JP> I wish life was so simple =85 The argument around simplicity is= a recurring one. And unfortunately, simple protocols do not always WORK = =85 I could actually show
you, taking real-life networks (no simulation), how a (simple) reactiv= e routing protocol would break in a LLN.


As a matter of fact, there are large-scale deployments of LOADng by in= dustry. If LOADng was not working, I doubt that there would be any money sp= ent on that.
And your last argument is not helpful; I am convinced that for any Sta= ndards Track routing protool, I can show you scenarios where it breaks (whe= reas in other scenarios it works fine).=A0

JP> Then let's justify carefully why and when the current= standard does not meet the requirements, see how we can improve it if need= ed and then in a second step
seek of another protocol if required. Once again I am ONLY referring t= o LLNs, not other types of networks.

Best Regards.

JP.


Best
Ulrich





=A0

[...]
So my first guess is that LOADng is suitable for what I called "m= ains-powered computer using Wifi" ?


I think Jiazi has already replied to that in a later mail. Interop != =3D performance test. LOADng (like any other MANET protocol) can run on any= medium. Testing it on wifi is a simple thing to do. Interop tests are sole= ly to find out if messages can be parsed correctly, and if the implementations behave according to the specificatio= n.=A0

As Jiazi pointed out correctly, I don't understand why we have thi= s discussion before you have seen the latest LOADng revision.=A0

Best
Ulrich
=A0
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--20cf3071c69c930e7504cc0e8450-- From ulrich@herberg.name Sun Oct 14 18:08:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C221F8554 for ; Sun, 14 Oct 2012 18:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2N2nqH+B28w for ; Sun, 14 Oct 2012 18:08:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9BC721F8540 for ; Sun, 14 Oct 2012 18:08:08 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5742797vcb.31 for ; Sun, 14 Oct 2012 18:08:08 -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=PBoy718cNNGu7hYXM0Zqrm0GfND+XLSorFWCB9uzrbA=; b=cHaL0AsE0zc3Arqm9sR6P5Qq+Jv6hVb6QR50AZyfT98PYxSmJZxgT88UNVAvXzJJ2K 0wbohNbGi794fYRwRQ3DEPnnrb2FJVTI6muNj+G5f6gNicmESGmQVR/qeRLXaRv4pVD3 Ua+5jHizZ8DXXeYi1RCC+BNPuWvDCHkVFDZtk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PBoy718cNNGu7hYXM0Zqrm0GfND+XLSorFWCB9uzrbA=; b=Q0la1UM4kNLG82WXIlPrQ6hDFoQQ9PEqYuYp2hMFoIs/wc0vPjhuNed4xZ1na/JH8E 5MB4Ptbyw7HVwblntQb0oR5Qc/HvxCeeZnECPU/tLLs/2dcywHqJ54gUyTbaF/hIrriW k+3AkyHJirezP2IkqigLX5BtMUtKbuTXr6/uPOez70exvBn8VFEB1r3irMJCvvnjGwrO Nc1IL2hGyeq5ViOEriEQnvAouglBk+CllY8J/NT+hQKrd9/WE/ifmVj1j/MvCIPt0Iu7 NN5mKOyPmbXZLvYU7YUFcrRVhXoBZJK1O0Lebv5Xh0wvg8cF5wbYusU8MbMdXYloMm1x ewuw== MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr4676811vdb.33.1350263288217; Sun, 14 Oct 2012 18:08:08 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Sun, 14 Oct 2012 18:08:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Oct 2012 18:08:08 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=bcaec50162b5a5beb804cc0eabf5 X-Gm-Message-State: ALoCoQlq2Rw+Y+auSBnnX7L1KU8CkZOyNr9YoU/kvYyamvyEmqX8MNqLRcEsR2A/BtlCLij8xm9R Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 01:08:09 -0000 --bcaec50162b5a5beb804cc0eabf5 Content-Type: text/plain; charset=ISO-8859-1 Hi AB, On Sun, Oct 14, 2012 at 7:58 AM, Abdussalam Baryun > [...] > > AB> I see there was an overlap when there was a claim that MANET routing > are better than RPL performance in ROLL meetings, > and resulted to an I-D draft [2] produced for RPL experience, with authors > discussing their observation without their recommendations for RPL > specification RFC6550. > I think that this discussion does not fit in the MANET mailing list. MANET has not specified RFC6550. That draft describes the authors' observations of the specification of RFC6550. It does not say that "MANET routing are better than RPL performance". > > IMO, MANET routings are not best solutions for LLNs. The RPL [RFC6550] is > the best solution so far that IETF has produced for such specific MANETs > that are LLNs. > In order to determine the performance or suitability of one protocol in certain scenarios, it would be more helpful to come up with actual results, than just saying "IMO". Best regards Ulrich --bcaec50162b5a5beb804cc0eabf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi AB,

On Sun, Oct 14, 2012 at 7:58 AM, A= bdussalam Baryun=A0
> [...]
=A0
AB> I see there was an overlap when there was a claim= that MANET routing are better than RPL performance in ROLL meetings,=A0
and resulted to=A0an I-D draft [2]=A0produced for RPL experience,= with authors discussing their observation without their=A0recommendations = for RPL specification RFC6550.

= I think that this discussion does not fit in the MANET mailing list. MANET = has not specified RFC6550.
That draft describes the authors' observations of the specificatio= n of RFC6550. It does not say that "MANET routing are better than RPL = performance".

=A0
=A0
IMO, MANET routings are not best solutions for LLNs. The= RPL [RFC6550] is the best solution so far that IETF has produced for such = specific MANETs that are LLNs.

In order to determine the performance or suitability of one protocol in cer= tain scenarios, it would be more helpful to come up with actual results, th= an just saying "IMO".

Best regards
Ulrich
=A0

--bcaec50162b5a5beb804cc0eabf5-- From teco@inf-net.nl Sun Oct 14 22:27:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8153021F852D for ; Sun, 14 Oct 2012 22:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlajVfVazZGc for ; Sun, 14 Oct 2012 22:27:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 25FD921F851E for ; Sun, 14 Oct 2012 22:27:11 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1287112wib.13 for ; Sun, 14 Oct 2012 22:27:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=T+Xg8OrGbjpn2lPPxhtxK9dItx0D0ZxzV8I+6omPxx0=; b=g5ITdoU/54cQzDiHkpZlZf9obQGYuH5/kl+w6HVjQVIYNKhrIgLm2pCV2jUA7Leh8M k/nkOS9ZPJ1duv2rmtdTMAVetC4n3pLE8bxtZLHIoh9IyLUc0/6yUWKuaTM9W2TkRmy3 hI8dtDTHPOf5EitkWkDll7w0zQR6yxmOdrkr8IfLonmxngjKUahpHEIGQC6YB+ngZqEI +WD5AMTfNnKcN/KESK5GO9m0gMEkv2bjSMHjGGeXDKYie8mKxjJvsGljnvfhv2g8WZvI VZmj4PayGg46VHHHbkibSFoBAHnO7ZCEiKjELbiAj9z2npSVVH4woYkCl6dhqTIae8Iy 8BYQ== Received: by 10.216.195.144 with SMTP id p16mr6078747wen.174.1350278830471; Sun, 14 Oct 2012 22:27:10 -0700 (PDT) Received: from [10.87.64.194] ([80.187.201.33]) by mx.google.com with ESMTPS id ct3sm12180325wib.5.2012.10.14.22.27.02 (version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 22:27:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> Date: Mon, 15 Oct 2012 07:27:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68BB4410-3634-4420-AAEA-8F18492C519E@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnKvQjuiHJ+xh/hLMpgg4lySC0dCp3Ho69HvxqLIJpoNpqZSkG5+jyyY0ckAQwLTq8kHW6d Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 05:27:13 -0000 The -03 version only requires the MAC for neighbors. Other data items = are optional. The router should be happy with only having required data = items. The more there is, the happier the router will be. A router that = is connected to a DLEP RFC compliant radio, getting little info, should = not act as crazy as you described. I would say: In general, when a router has received information that a neighbor is = up, it should send out hello messages to make sure the link to that = neighbor is bi-directional. If so, the link can be added in the routing = topology. The router may calculate link metrics for that link, based on = the DLEP provided data items. The router may use other information for = link metric calculation. (no capitals here) I suggested a number of times (>3) a single dynamic, mandatory link = metric. Could be RLQ. But I prefer a wider precision. 0-100 scale is OK, = which is functionally equivalent to 0-255 or 0-(2^24-1). Having a = mandatory fixed MDR at peer discovery (or Neigbor Up) would be OK also. = This would be a way-out of your fear for burning routers. Henning suggested improved up/down state signals, so the router can = learn form radio that link is bi-directional. This would speed up = getting the L3 link up. Router may set link on two-way if radio says so. Teco Op 15 okt. 2012, om 02:08 heeft Stan Ratliff (sratliff) het volgende = geschreven: > I've asked twice now (this email makes attempt number 3) for someone = to suggest some text to clarify what a router or modem would do with an = UNKNOWN metric. So far, what I've seen is a potentially new *way* of = specifying UNKNOWN - one that makes more sense than picking some = arbitrary code point. But no actual text to suggest what either of the = endpoints would *do* with the data. Maybe I'm old, feeble, and not very = bright - but I'm looking for suggestions that start with "A router = receiving a metric value of UNKNOWN MUST=85" or "An implementation = receiving an UNKNOWN indication SHOULD=85" or something along those = lines. Barring that, the only text I've got to insert is what I = suggested before:=20 >>=20 >> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where = RLQ is supported, but not currently calculable. The authors have no idea = under what circumstances this would occur. Routers receiving a value of = RLQ_UNKNOWN are free to take any action deemed appropriate, including = (but not limited to) ignoring the value, producing log messages, or = bursting into flames. The RLQ_UNKNOWN (TBD) value was added at the = request of the working group, as consensus formed around the key ideas = that this MAY allow for innovation, even though none of the working = group members were able to note a set of circumstances under which this = innovation might take place. So, in an effort to stop the email storm, = the authors added the additional code point." >>=20 >=20 > Stan >=20 >=20 > On Oct 14, 2012, at 6:01 AM, Henning Rogge wrote: >=20 >> I think the idea is not bad. >>=20 >> IF we decide to use a special codepoint for "unknown TLV value", = using >> "length =3D 0" would give us a generic way for doing it for all kind = of >> additional metric TLVs... instead of doing this "what to use for >> UNKNOWN" brainstorming again. >>=20 >> It also makes it easier to include the UNKNOWN codepoint into metrics >> which have no bits/values left. >>=20 >> Henning Rogge >>=20 >> On Sat, Oct 13, 2012 at 5:06 PM, Bo Berry wrote: >>> Teco >>> Thanks, this helps. So let's see what others think. >>> Have a great wkend. >>>=20 >>> -Bo >>>=20 >>>=20 >>> On Oct 13, 2012, at 10:50 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: >>>>=20 >>>>> Teco, >>>>> I do not understand it and it's not been described in a manner >>>>> that I can. But if we can not understand it, we will not be >>>>> successful describing it such that it can be useful. >>>>>=20 >>>>> If you can provide meaningful, descriptive text, that would help. >>>>> At this time, "prepare for data items that can fall back to = unknown" >>>>> does not help me. What do you propose as optional data items >>>>> and how do you propose, by what mechanism, they fall back? Do >>>>> they fall back in the radio or router, or both? >>>>=20 >>>> The optional Data Item TLVs for Neighbor Up are in the draft: >>>> - IPv4 Address >>>> - IPv6 Address >>>> - Maximum Data Rate >>>> - Current Data Rate >>>> - Latency >>>> - Expected Forwarding Time >>>> - Resources >>>> - Relative Link Factor >>>> - Credit Window Status >>>> Neighbor Up messages would be send by router, although the draft >>>> mentions the router can send it also. >>>> Relative Link Factor should be Relative Link Quality (posted = before, >>>> I think). In Neighbor Update, Expected Forwarding Time is missing. >>>>=20 >>>> My comment is on the protocol. Optional data item TLVs can be = present, >>>> or not. There was a proposal for TLV with an UNKNOWN codepoint, for = RLQ. >>>> I don't see much difference in UNKNOWN and not sending the TLV. = Then, >>>> this UNKNOWN applies to all optional Data Item TLVs. So if we just >>>> add a mechanism that enables sending UNKNOWN for all optional Data >>>> Item TLVs, we are done. Addresses have the drop already. The other >>>> TLVs can have the length=3D0. That's all. I provided the text = already. >>>>=20 >>>> I can't be more clear. Sorry. >>>>=20 >>>> Teco >>>>=20 >>>>>=20 >>>>>=20 >>>>> -Bo >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: >>>>>=20 >>>>>> DLEP is (mainly) getting the neighbor information base from radio = to >>>>>> router, as accurate as possible. It is up to the router to use = this for >>>>>> route calculation. >>>>>>=20 >>>>>> This discussion is not about using RFC 5444. >>>>>>=20 >>>>>> It is about transfer of "hey there, I don't have this info = anymore". >>>>>> Bo and Stan say, this is not needed. Others say, there is a need = for it. >>>>>> I agree with the others, because I cannot see a reason a radio is = only >>>>>> allowed *once* during neighbor_up state to miss data items. We = better >>>>>> prepare for data items that can fall back to unknown. I say: = let's allow >>>>>> this for all optional data items. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>> Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende = geschreven: >>>>>>=20 >>>>>>> I agree we should design for the present MANET technologies and >>>>>>> future, for the protocol completion. Do you mean router-state as = the >>>>>>> DLEP-server state? IF yes THEN I agree with you. IF not THEN, I = Don't >>>>>>> understand why we need to consider router states. >>>>>>>=20 >>>>>>> DLEP considers the session between server and client states, = other >>>>>>> states are not inscope. For simplicity, DLEP should be abstract = from >>>>>>> MANET-Router's (OLSRv2 or AODVv2) states, decisions or = processes, an >>>>>>> optional future interaction may be useful but complicated (will = need >>>>>>> RFC5444). >>>>>>>=20 >>>>>>> AB >>>>>>>=20 >>>>>>> On 10/13/12, Teco Boot wrote: >>>>>>>>=20 >>>>>>> My point is that the DLEP protocol should be "complete", in that = the >>>>>>> radio is able to get the router in a certain state, in another = state >>>>>>> and get back in the earlier state. RLQ is just an example. >>>>>>>=20 >>>>>>> If you think this makes no sense with the radios you have seen = up to >>>>>>> now, you could be right. Tomorrow, you could have a different = opinion. >>>>>>> I saw on this mailing list some of us see already the = requirement the >>>>>>> protocol shall be "complete". >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Sun Oct 14 22:40:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DD421F8534 for ; Sun, 14 Oct 2012 22:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHX8RtjRVTFx for ; Sun, 14 Oct 2012 22:40:05 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id BC75621F852A for ; Sun, 14 Oct 2012 22:40:03 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TNdPG-0007mQ-8r for manet@ietf.org; Mon, 15 Oct 2012 07:40:02 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TNdPG-0004rx-6D for manet@ietf.org; Mon, 15 Oct 2012 07:40:02 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Oct 2012 07:40:02 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 15 Oct 2012 07:40:01 +0200 Message-ID: <507BA1AA.7080607@fkie.fraunhofer.de> Date: Mon, 15 Oct 2012 07:39:54 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040800020709080803070907" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 15 Oct 2012 05:40:02.0031 (UTC) FILETIME=[85825FF0:01CDAA97] X-Virus-Scanned: yes (ClamAV 0.97.5/15459/Sat Oct 13 14:26:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8875d4c9fcbcf3dc5ce5a7a09af9f425 Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 05:40:06 -0000 --------------ms040800020709080803070907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: > I've asked twice now (this email makes attempt number 3) for someone to= suggest some text to clarify what a router or modem would do with an UNK= NOWN metric. So far, what I've seen is a potentially new *way* of specify= ing UNKNOWN - one that makes more sense than picking some arbitrary code = point. But no actual text to suggest what either of the endpoints would *= do* with the data. Maybe I'm old, feeble, and not very bright - but I'm l= ooking for suggestions that start with "A router receiving a metric value= of UNKNOWN MUST=85" or "An implementation receiving an UNKNOWN indicatio= n SHOULD=85" or something along those lines. Barring that, the only text = I've got to insert is what I suggested before: >> >> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RL= Q is supported, but not currently calculable. The authors have no idea un= der what circumstances this would occur. Routers receiving a value of RLQ= _UNKNOWN are free to take any action deemed appropriate, including (but n= ot limited to) ignoring the value, producing log messages, or bursting in= to flames. The RLQ_UNKNOWN (TBD) value was added at the request of the wo= rking group, as consensus formed around the key ideas that this MAY allow= for innovation, even though none of the working group members were able = to note a set of circumstances under which this innovation might take pla= ce. So, in an effort to stop the email storm, the authors added the addit= ional code point." If we use Teco's suggested solution (using 'length =3D 0' to make an=20 unknown but supported TLV): ---- Radio implementations MAY use a metric TLV without value and length 0 to = signal a not measurable but supported TLV. Most router implementations will process this metric TLV in the same way = as a missing metric TLV. ---- The "will" in the second sentence could also be a "SHOULD" or "MAY", I=20 am not sure about this. "Metric TLV" would be a list of all DLEP TLVs that transport a metric=20 value like RLQ, delay, current/maximum link speed, ... Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040800020709080803070907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTUwNTM5NTlaMCMGCSqGSIb3DQEJBDEWBBTHm5SK6YZKGvd3540tn2ZjKkGGAjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEADvJNAFd9mqMon/Xig5dbLpVFWBYZ6khdE3fqshsT54nN uPXqqxKu8dqCHp/RNPMs9kqlkrIxRdaMbFBbAopyQ28w/CHQT+TMUC8no4Ew1YOJQEBBO5lO fscQoIUKceWWJY9zUlhSSHliVXxgUQ2+LnfxZOpeFBXHnytZOc+NgJyrnYCmrzH9RU3NBJ6e SJ/HqMMSj2YK7nyV7L/uIG4g+yyb324clGcwQEdDVwH3ZZ4fjGVZ/+wX5nJmCtW2WYyyP6Ky q5KF4sZDboL3qeKCwjZMSfVDFNr+u0BIqe8DwxwLHvaAnxtpXyYHyGocAAS6Vu/6wx6nzscm oDGcWQOXQAAAAAAAAA== --------------ms040800020709080803070907-- From jvasseur@cisco.com Sun Oct 14 23:22:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32BA21F85B8 for ; Sun, 14 Oct 2012 23:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saQ7WFZU6piS for ; Sun, 14 Oct 2012 23:22:11 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AD11021F859A for ; Sun, 14 Oct 2012 23:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5555; q=dns/txt; s=iport; t=1350282131; x=1351491731; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WM+84aTUYczzW7Xzvx4eHzlVSZqwEZydy7EZ0o8KH5Y=; b=RhPZ5jZ77fwMFtatfUkOAIZ1P5z7maqgphp7wbwivQrHH1/MtqdhJW9p o6vd2OkZImFmEgzR8q77o0yng96658zZeLttYg1HZZMDOlY3wUKpLu2ga 8XjXHkOyT2j1BgtVBqlRlgfiOINiWKv4C+fWShze2+XyoHlsyS0JfYjco 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPiqe1CtJXG9/2dsb2JhbABFv3eBCIIhAQEEAQEBDwFbCxACAQgiHQcnCxQRAgQOBQgTB4diC50lnxwEi1mFXWADiCOKGJF2gWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208,217";a="131544886" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2012 06:22:11 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9F6MBSf010476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 06:22:11 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 01:22:11 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNqp1oPA/n6cNzGE69RFit48QfDA== Date: Mon, 15 Oct 2012 06:22:10 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE07C5@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--42.742100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FE07C5xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 06:22:12 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FE07C5xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 15, 2012, at 3:08 AM, Ulrich Herberg wrote: Hi AB, On Sun, Oct 14, 2012 at 7:58 AM, Abdussalam Baryun > [...] AB> I see there was an overlap when there was a claim that MANET routing ar= e better than RPL performance in ROLL meetings, and resulted to an I-D draft [2] produced for RPL experience, with authors = discussing their observation without their recommendations for RPL specific= ation RFC6550. I think that this discussion does not fit in the MANET mailing list. MANET = has not specified RFC6550. That draft describes the authors' observations of the specification of RFC6= 550. It does not say that "MANET routing are better than RPL performance". JP> There are papers dong the comparison, if this is what you want, I will = try to see if they can share the result of their research. Agree that this = does not belong to the MANET WG mailing list. IMO, MANET routings are not best solutions for LLNs. The RPL [RFC6550] is t= he best solution so far that IETF has produced for such specific MANETs tha= t are LLNs. In order to determine the performance or suitability of one protocol in cer= tain scenarios, it would be more helpful to come up with actual results, th= an just saying "IMO". JP> There are many facts that can be shared, and will be shared. Thanks. Best Regards. JP. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FE07C5xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 15, 2012, at 3:08 AM, Ulrich Herberg wrote:

Hi AB,

On Sun, Oct 14, 2012 at 7:58 AM, Abdussalam Bary= un 
> [...]
 
AB> I see there was an overlap when there was a claim that MANET ro= uting are better than RPL performance in ROLL meetings, 
and resulted to an I-D draft [2] produced for RPL experience= , with authors discussing their observation without their recommendati= ons for RPL specification RFC6550.

I think that this discussion does not fit in the MANET mailing list. M= ANET has not specified RFC6550.
That draft describes the authors' observations of the specification of= RFC6550. It does not say that "MANET routing are better than RPL perf= ormance".


JP> There are papers dong the comparison, if this is what you want,= I will try to see if they can share the result of their research. Agree th= at this does not belong to the
MANET WG mailing list.

 
 
IMO, MANET routings are not best solutions for LLNs. The RPL [RFC6550]= is the best solution so far that IETF has produced for such specific MANET= s that are LLNs.

In order to determine the performance or suitability of one protocol i= n certain scenarios, it would be more helpful to come up with actual result= s, than just saying "IMO".


JP> There are many facts that can be shared, and will be shared.

Thanks.

Best Regards.

JP.

Best regards
Ulrich
 

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

--_000_03B78081B371D44390ED6E7BADBB4A7721FE07C5xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sun Oct 14 23:28:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7626021F85C3 for ; Sun, 14 Oct 2012 23:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.403 X-Spam-Level: X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9YsDRM0L7tL for ; Sun, 14 Oct 2012 23:28:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC921F85A8 for ; Sun, 14 Oct 2012 23:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25018; q=dns/txt; s=iport; t=1350282496; x=1351492096; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BazFnnvhJMslVO9DMK06RGfJH0dMwQ+1rqVUzoqyw+Y=; b=h1wR2g6XT+oPfZB2yHPlz+NAYowgx35kyhhlP+9UszxPKDp4uqvIZovU fiGO+3GPvBvp/KkWNBDgyWzn0GfpSYmKtViqx5Medj9P4Fc9W75pwWArK CvE8MyOEqdlfBkT/tWtzEEoGiLdmesX6eiihIxQb8BVVBckftAZKveSNy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJ6re1CtJV2Y/2dsb2JhbABFtxYBiGCBCIIhAQEEAQEBDwFYAwIJEAIBCCIdBycLFBECBA4FCAwFCYdiC50qnyCLWRQGAYVCYAOXAY0wgWuCbYFaCTQ X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208,217";a="131325244" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2012 06:28:15 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9F6SFN5016339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 06:28:15 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 01:28:15 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Mon, 15 Oct 2012 06:28:14 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--53.059400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FE083Cxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 06:28:18 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FE083Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 15, 2012, at 2:57 AM, Ulrich Herberg wrote: Hi JP, I think this discussion diverges into a comparison proactive vs. reactive p= rotocols. I do not doubt that you can show me proof that in certain scenari= os, reactive protocols perform poorly. I can do the same exercise for proac= tive protocols in other scenarios. MANET has gone though that about 10 year= s ago, and decided that "no-one-size-fits-all", but rather that we were cha= rtered to produce a std. track reactive protocols *and* a std. track proact= ive protocol. And I think this is the most important argument in this discussion: MANET i= s chartered to come up with a reactive protocol for MANETs. And I believe i= t is a good idea to mention in which deployments a specification is used. JP> Here we do not disagree at all. I am not saying that reactive protocols= are not appropriate in a number of scenario. All I am saying is that *if* = you intent to specify a reactive routing protocol for LLNs, knowing the years of intense work and= efforts of the ROLL WG, then it should be discussed with a wider audience.= On the other hand, if your explicitly exclude LLNs from your protocol in your protocol, = it is no longer required to involve the ROLL WG. The objective is simply to= avoid WG charter overlap but more importantly try to benefit from the benefit of experts in = the area of LLNs to build a good protocol for the Internet. It was also agreed at the last MANET meeting that if LOADng was to be consi= dered for MANET, it needs to de-emphasize LLNs (which I have not heard anyb= ody disagree with so far). So I don't understand what we are even discussin= g here. JP> No, this your recollection of the discussion. "less-focussed" or "de-em= phasize" was I think your interpretation. Mine was "not referring to LLNs" = at all. Otherwise, it should be reviewed by both WGs (to be discussed between chair= s and AD). Thanks. Best Regards. JP. Best regards Ulrich On Sun, Oct 14, 2012 at 9:13 AM, JP Vasseur (jvasseur) > wrote: Hi Ulrich, On Oct 14, 2012, at 5:12 PM, Ulrich Herberg wrote: Hi JP, On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" > wrote: Hi Ulrich, On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: Hi C=E9dric, On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet > wrote: [...] The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. I am not suggesting to revive a discussion of the definition of a MANET vs = LLN. JP> Mei neither - this is why, if you suggest to indicate the applicability= of the protocol in the document which makes total sense, the WG should exc= lude LLNs from this ID explicitly. I disagree. How can we exclude it from the document when it is as a matter = of fact used in LLNs? I am just saying that if LOADng is to be accepted by= the WG, it has been clearly expressed in the last meeting that it is too f= ocused on LLNs, and should instead focus on the general MANET case. I agree= with that. Mentioning one, out of many use cases, in particular when peopl= e actually deploy it in that use cases seems just fair, and does not cause = any overlap between two working groups. JP> This is your interpretation of the last discussion - please discuss wit= h the WG chairs of ROLL and MANET. We have the mandate to design one protoc= ol for LLN at the IETF, which leads to no overlap. If you think that the protocol = designed by the IETF (RPL) does meet the requirements, and you would like t= o see some improvements, then you are extremely welcome in ROLL, to keep improving it.= As a matter of fact, there are now several large scale deployments in prod= uction but again we can keep improving it. The "too focussed" is your interpretation, = I do no agree with it at all. Actually there are papers available showing w= hy using Load-ng may lead to serious issues in LLNs; we need to be cautious and conscious on= these issues for the best of the Internet. I did not bring up this discussion. All I am saying is that MANET is charte= red to come up with a reactive protocol. And I believe it should be allowed= to mention where a protocol is used in deployments. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? Since you ask here...In my personal opinion, LLNs are a 100% subset of a M= ANET. Both are usually multi-hop, often wireless, with constrained routers,= in many cases incoming packets leave a router on the same interface that t= hey have been received on, and the topology is dynamic. JP> Well, in this case, pushing your reasoning a bit further, this may very= well apply to OSPF, ISIS, =85 too. These protocos don't cope well with lossy channels and dynamic topology cha= nges. JP> I am sure that yo understood the analogy, I was not proposing to use OS= PF and ISIS =85 these were example to show that your characterization was n= ot a compelling argument. I clearly do not think that LLNs are 100% subset of MANET; there is a treme= ndous difference between several dozens of highly constrained fixed routers= interconnected by very lossy links providing a few KBits/s and several hundreds of routers= with high mobility interconnected by Wifi links. Nobody ever said that MANETs are interconnected by wifi only, or anything a= bout limited size of the network (quite the contrary, they are intended to = be very large). Also, MANETs such as Funkfeuer are non-mobile. JP> I was giving an example ... MANETs, IMO, have a larger range of "constrained routers", from very constr= ained routers (e.g. LLN) to somewhat constrained routers (e.g. community ne= tworks) to non-constrained routers (e.g. certain military deployments). LLN= is focused on extremely constrained devices. However, I don't say that we should revisit the way how the Routing Area di= stributed the tasks in the WGs, nor do I suggest to change the charters. JP> IF that were the case, we would not have formed two WG but one. I don't want to go in there. I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I cannot answer this question, as I have not deployed LOADng on a 8K/48K RA= M/ROM device. Those who have deployments and are willing to disclose detail= s, may have more details. Just one comment: I have implemented numerous ad-= hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simple= st to implement and has the least lines of code (by far) compared to all th= ese other protocols that I have implemented. If you can run any of these be= forementioned protocols on such a device, you can certainly run LOADng on i= t. JP> I wish life was so simple =85 The argument around simplicity is a recur= ring one. And unfortunately, simple protocols do not always WORK =85 I coul= d actually show you, taking real-life networks (no simulation), how a (simple) reactive rou= ting protocol would break in a LLN. As a matter of fact, there are large-scale deployments of LOADng by industr= y. If LOADng was not working, I doubt that there would be any money spent o= n that. And your last argument is not helpful; I am convinced that for any Standard= s Track routing protool, I can show you scenarios where it breaks (whereas = in other scenarios it works fine). JP> Then let's justify carefully why and when the current standard does not= meet the requirements, see how we can improve it if needed and then in a s= econd step seek of another protocol if required. Once again I am ONLY referring to LLN= s, not other types of networks. Best Regards. JP. Best Ulrich I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : [...] So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? I think Jiazi has already replied to that in a later mail. Interop !=3D per= formance test. LOADng (like any other MANET protocol) can run on any medium= . Testing it on wifi is a simple thing to do. Interop tests are solely to f= ind out if messages can be parsed correctly, and if the implementations beh= ave according to the specification. As Jiazi pointed out correctly, I don't understand why we have this discuss= ion before you have seen the latest LOADng revision. Best Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FE083Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <31B5BFC52DFF1D449671965E045AE2BC@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 15, 2012, at 2:57 AM, Ulrich Herberg wrote:

Hi JP,

I think this discussion diverges into a comparison proactive vs. react= ive protocols. I do not doubt that you can show me proof that in certain sc= enarios, reactive protocols perform poorly. I can do the same exercise for = proactive protocols in other scenarios. MANET has gone though that about 10 years ago, and decided that "no-o= ne-size-fits-all", but rather that we were chartered to produce a std.= track reactive protocols *and* a std. track proactive protocol.<= /div>

And I think this is the most important argument in this discussion: MA= NET is chartered to come up with a reactive protocol for MANETs. And I beli= eve it is a good idea to mention in which deployments a specification is us= ed. 

JP> Here we do not disagree at all. I am not saying that reactive p= rotocols are not appropriate in a number of scenario. All I am saying is th= at *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of intense wor= k and efforts of the ROLL WG, then it should be discussed with a wider audi= ence. On the other
hand, if your explicitly exclude LLNs from your protocol in your proto= col, it is no longer required to involve the ROLL WG. The objective is simp= ly to avoid WG charter
overlap but more importantly try to benefit from the benefit of expert= s in the area of LLNs to build a good protocol for the Internet.

It was also agreed at the last MANET meeting that if LOADng was to be = considered for MANET, it needs to de-emphasize LLNs (which I have not heard= anybody disagree with so far). So I don't understand what we are even disc= ussing here. 

JP> No, this your recollection of the discussion. "less-focuss= ed" or "de-emphasize" was I think your interpretation. Mine = was "not referring to LLNs" at all. 
Otherwise, it should be reviewed by both WGs (to be discussed between = chairs and AD).

Thanks.

Best Regards.

JP.


Best regards
Ulrich


On Sun, Oct 14, 2012 at 9:13 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
Hi Ulrich,

On Oct 14, 2012, at 5:12 PM, Ulrich Herberg wrote:

Hi JP,

On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wro= te:

Hi Ulrich,

On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote:

Hi C=E9dric,

On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
[...]

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.


I am not suggesting to revive a discussion of the definition of a MANE= T vs LLN.

JP> Mei neither - this is why, if you suggest to indicate the appli= cability of the protocol in the document which makes total sense, the WG sh= ould exclude LLNs from
this ID explicitly.


I disagree. How can we exclude it from the document when it is as a ma= tter of fact used in LLNs?  I am just saying that if LOADng is to be a= ccepted by the WG, it has been clearly expressed in the last meeting that i= t is too focused on LLNs, and should instead focus on the general MANET case. I agree with that. Mentioning one= , out of many use cases, in particular when people actually deploy it in th= at use cases seems just fair, and does not cause any overlap between two wo= rking groups.

JP> This is your interpretation of the last discussion - please dis= cuss with the WG chairs of ROLL and MANET. We have the mandate to design on= e protocol for
LLN at the IETF, which leads to no overlap. If you think that the prot= ocol designed by the IETF (RPL) does meet the requirements, and you would l= ike to see some
improvements, then you are extremely welcome in ROLL, to keep improvin= g it. As a matter of fact, there are now several large scale deployments in= production but
again we can keep improving it. The "too focussed" is your i= nterpretation, I do no agree with it at all. Actually there are papers avai= lable showing why using Load-ng
may lead to serious issues in LLNs; we need to be cautious and conscio= us on these issues for the best of the Internet.





I did not bring up this discussion. All I am saying is that MANET is c= hartered to come up with a reactive protocol. And I believe it should be al= lowed to mention where a protocol is used in deployments. 


 
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?


Since you ask here...In my personal opinion,  LLNs are a 100% sub= set of a MANET. Both are usually multi-hop, often wireless, with constraine= d routers, in many cases incoming packets leave a router on the same interf= ace that they have been received on, and the topology is dynamic.

JP> Well, in this case, pushing your reasoning a bit further, this = may very well apply to OSPF, ISIS, =85 too.


These protocos don't cope well with lossy channels and dynamic topolog= y changes.

JP> I am sure that yo understood the analogy, I was not proposing t= o use OSPF and ISIS =85 these were example to show that your characterizati= on was not a compelling
argument.


I clearly do not think that LLNs are 100% subset of MANET; there is a = tremendous difference between several dozens of highly constrained fixed ro= uters interconnected
by very lossy links providing a few KBits/s and several hundreds of ro= uters with high mobility interconnected by Wifi links.

Nobody ever said that MANETs are interconnected by wifi only, or anyth= ing about limited size of the network (quite the contrary, they are intende= d to be very large). Also, MANETs such as Funkfeuer are non-mobile.


JP> I was giving an example ...



MANETs, IMO, have a larger range of "constrained routers", f= rom very constrained routers (e.g. LLN) to somewhat constrained routers (e.= g. community networks) to non-constrained routers (e.g. certain military de= ployments). LLN is focused on extremely constrained devices.
However, I don't say that we should revisit the way how the Routing Ar= ea distributed the tasks in the WGs, nor do I suggest to change the charter= s.


JP> IF that were the case, we would not have formed two WG but one.=


I don't want to go in there.




 

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).

I cannot answer this question, as I have not deployed LOADng on a 8K/4= 8K RAM/ROM device. Those who have deployments and are willing to disclose d= etails, may have more details. Just one comment: I have implemented numerou= s ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest to implement and has the le= ast lines of code (by far) compared to all these other protocols that I hav= e implemented. If you can run any of these beforementioned protocols on suc= h a device, you can certainly run LOADng on it.

JP> I wish life was so simple =85 The argument around simplicity is= a recurring one. And unfortunately, simple protocols do not always WORK = =85 I could actually show
you, taking real-life networks (no simulation), how a (simple) reactiv= e routing protocol would break in a LLN.


As a matter of fact, there are large-scale deployments of LOADng by in= dustry. If LOADng was not working, I doubt that there would be any money sp= ent on that.
And your last argument is not helpful; I am convinced that for any Sta= ndards Track routing protool, I can show you scenarios where it breaks (whe= reas in other scenarios it works fine). 

JP> Then let's justify carefully why and when the current standard = does not meet the requirements, see how we can improve it if needed and the= n in a second step
seek of another protocol if required. Once again I am ONLY referring t= o LLNs, not other types of networks.

Best Regards.

JP.


Best
Ulrich





 


I think Jiazi has already replied to that in a later mail. Interop != =3D performance test. LOADng (like any other MANET protocol) can run on any= medium. Testing it on wifi is a simple thing to do. Interop tests are sole= ly to find out if messages can be parsed correctly, and if the implementations behave according to the specificatio= n. 

As Jiazi pointed out correctly, I don't understand why we have this di= scussion before you have seen the latest LOADng revision. 

Best
Ulrich
 
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--_000_03B78081B371D44390ED6E7BADBB4A7721FE083Cxmbrcdx02ciscoc_-- From c.chauvenet@watteco.com Mon Oct 15 01:45:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44C21F8510 for ; Mon, 15 Oct 2012 01:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iAxQKlYI544 for ; Mon, 15 Oct 2012 01:45:55 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4B23E21F8647 for ; Mon, 15 Oct 2012 01:45:53 -0700 (PDT) Received: from mail30-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Oct 2012 08:45:52 +0000 Received: from mail30-am1 (localhost [127.0.0.1]) by mail30-am1-R.bigfish.com (Postfix) with ESMTP id CB86816021F; Mon, 15 Oct 2012 08:45:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz98dI9371Ic89bhd6eahc85eh1dbaIzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail30-am1 (localhost.localdomain [127.0.0.1]) by mail30-am1 (MessageSwitch) id 1350290749957221_3547; Mon, 15 Oct 2012 08:45:49 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.253]) by mail30-am1.bigfish.com (Postfix) with ESMTP id E46234A004A; Mon, 15 Oct 2012 08:45:49 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Oct 2012 08:45:49 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0207.009; Mon, 15 Oct 2012 08:45:49 +0000 From: C Chauvenet To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAIAAdJeAgABi3ICAAIeagIABJjmA Date: Mon, 15 Oct 2012 08:45:48 +0000 Message-ID: <208DA393-C499-4538-8FA4-7D04255B3665@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_208DA393C49945388FA47D04255B3665wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Stan Ratliff \(sratliff\)" , "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 08:45:56 -0000 --_000_208DA393C49945388FA47D04255B3665wattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, Le 14 oct. 2012 =E0 17:12, Ulrich Herberg a =E9crit : Hi JP, On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" > wrote: Hi Ulrich, On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote: Hi C=E9dric, On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet > wrote: [...] The distinction between MANET and LLNs seems to be vanish here. This brings us back to the summer discussion between what is a MANET and wh= at is a LLN that did not really fostered on a consensus. WG chairs could help there, as it is their related scope. I am not suggesting to revive a discussion of the definition of a MANET vs = LLN. JP> Mei neither - this is why, if you suggest to indicate the applicability= of the protocol in the document which makes total sense, the WG should exc= lude LLNs from this ID explicitly. I disagree. How can we exclude it from the document when it is as a matter = of fact used in LLNs? I am just saying that if LOADng is to be accepted by= the WG, it has been clearly expressed in the last meeting that it is too f= ocused on LLNs, and should instead focus on the general MANET case. I agree= with that. Mentioning one, out of many use cases, in particular when peopl= e actually deploy it in that use cases seems just fair, and does not cause = any overlap between two working groups. I did not bring up this discussion. All I am saying is that MANET is charte= red to come up with a reactive protocol. And I believe it should be allowed= to mention where a protocol is used in deployments. My vision is that LLNs are more constrained than MANET for the following cr= iterion : Power consumption, Loss of the media, Computation capability, Thr= oughput. What do you think ? My vision is also that the level of constraints of LLNs should not be consi= dered in a MANET protocol. Do you agree ? Since you ask here...In my personal opinion, LLNs are a 100% subset of a M= ANET. Both are usually multi-hop, often wireless, with constrained routers,= in many cases incoming packets leave a router on the same interface that t= hey have been received on, and the topology is dynamic. JP> Well, in this case, pushing your reasoning a bit further, this may very= well apply to OSPF, ISIS, =85 too. These protocos don't cope well with lossy channels and dynamic topology cha= nges. I clearly do not think that LLNs are 100% subset of MANET; there is a treme= ndous difference between several dozens of highly constrained fixed routers= interconnected by very lossy links providing a few KBits/s and several hundreds of routers= with high mobility interconnected by Wifi links. Nobody ever said that MANETs are interconnected by wifi only, or anything a= bout limited size of the network (quite the contrary, they are intended to = be very large). Also, MANETs such as Funkfeuer are non-mobile. MANETs, IMO, have a larger range of "constrained routers", from very constr= ained routers (e.g. LLN) to somewhat constrained routers (e.g. community ne= tworks) to non-constrained routers (e.g. certain military deployments). LLN= is focused on extremely constrained devices. However, I don't say that we should revisit the way how the Routing Area di= stributed the tasks in the WGs, nor do I suggest to change the charters. JP> IF that were the case, we would not have formed two WG but one. I don't want to go in there. I'm trying to figure out if LOADng is efficient over a mains-powered comput= er using Wifi, a 8K/48K RAM/ROM device, or both (cover such a wide range w= ould be magical !). I cannot answer this question, as I have not deployed LOADng on a 8K/48K RA= M/ROM device. Those who have deployments and are willing to disclose detail= s, may have more details. Just one comment: I have implemented numerous ad-= hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simple= st to implement and has the least lines of code (by far) compared to all th= ese other protocols that I have implemented. If you can run any of these be= forementioned protocols on such a device, you can certainly run LOADng on i= t. JP> I wish life was so simple =85 The argument around simplicity is a recur= ring one. And unfortunately, simple protocols do not always WORK =85 I coul= d actually show you, taking real-life networks (no simulation), how a (simple) reactive rou= ting protocol would break in a LLN. As a matter of fact, there are large-scale deployments of LOADng by industr= y. If LOADng was not working, I doubt that there would be any money spent o= n that. That is an interesting information. Do you have some material on that ? Was LOADng deployed over LLNs in these = cases ? The description of these deployments could help to see what is targeting. Overall, I think the discussion need the new version of LOADng to move on. As IETF is coming fast, I guess that it will released in the coming days ? Once released, we could see how its relates to the MANET charter and scope,= and do not conflict with RFC6550, the routing protocol for LLNs designed b= y the IETF. C=E9dric. And your last argument is not helpful; I am convinced that for any Standard= s Track routing protool, I can show you scenarios where it breaks (whereas = in other scenarios it works fine). Best Ulrich I see in the interop report http://tools.ietf.org/html/draft-lavenu-lln-loa= dng-interoperability-report-02 in section 3 : [...] So my first guess is that LOADng is suitable for what I called "mains-power= ed computer using Wifi" ? I think Jiazi has already replied to that in a later mail. Interop !=3D per= formance test. LOADng (like any other MANET protocol) can run on any medium= . Testing it on wifi is a simple thing to do. Interop tests are solely to f= ind out if messages can be parsed correctly, and if the implementations beh= ave according to the specification. As Jiazi pointed out correctly, I don't understand why we have this discuss= ion before you have seen the latest LOADng revision. Best Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_208DA393C49945388FA47D04255B3665wattecocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <77120BA1EE0D9549970505E3FC9D8D35@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Ulrich, 

Le 14 oct. 2012 =E0 17:12, Ulrich Herberg a =E9crit :

Hi JP,

On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Hi Ulrich,

On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote:

Hi C=E9dric,

On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
[...]

The distinction between MANET and LLNs seems to be vanish here.
This brings us back to the summer discussion between what is a MANET a= nd what is a LLN that did not really fostered on a consensus.
WG chairs could help there, as it is their related scope.


I am not suggesting to revive a discussion of the definition of a MANE= T vs LLN.

JP> Mei neither - this is why, if you suggest to indicate the appli= cability of the protocol in the document which makes total sense, the WG sh= ould exclude LLNs from
this ID explicitly.


I disagree. How can we exclude it from the document when it is as a ma= tter of fact used in LLNs?  I am just saying that if LOADng is to be a= ccepted by the WG, it has been clearly expressed in the last meeting that i= t is too focused on LLNs, and should instead focus on the general MANET case. I agree with that. Mentioning one= , out of many use cases, in particular when people actually deploy it in th= at use cases seems just fair, and does not cause any overlap between two wo= rking groups.




I did not bring up this discussion. All I am saying is that MANET is c= hartered to come up with a reactive protocol. And I believe it should be al= lowed to mention where a protocol is used in deployments. 


 
My vision is that LLNs are more constrained than MANET for the followi= ng criterion : Power consumption, Loss of the media, Computation capability= , Throughput.
What do you think ?
My vision is also that the level of constraints of LLNs should not be = considered in a MANET protocol.
Do you agree ?


Since you ask here...In my personal opinion,  LLNs are a 100% sub= set of a MANET. Both are usually multi-hop, often wireless, with constraine= d routers, in many cases incoming packets leave a router on the same interf= ace that they have been received on, and the topology is dynamic.

JP> Well, in this case, pushing your reasoning a bit further, this = may very well apply to OSPF, ISIS, =85 too.


These protocos don't cope well with lossy channels and dynamic topolog= y changes.

I clearly do not think that LLNs are 100% subset of MANET; there is a = tremendous difference between several dozens of highly constrained fixed ro= uters interconnected
by very lossy links providing a few KBits/s and several hundreds of ro= uters with high mobility interconnected by Wifi links.

Nobody ever said that MANETs are interconnected by wifi only, or anyth= ing about limited size of the network (quite the contrary, they are intende= d to be very large). Also, MANETs such as Funkfeuer are non-mobile.



MANETs, IMO, have a larger range of "constrained routers", f= rom very constrained routers (e.g. LLN) to somewhat constrained routers (e.= g. community networks) to non-constrained routers (e.g. certain military de= ployments). LLN is focused on extremely constrained devices.
However, I don't say that we should revisit the way how the Routing Ar= ea distributed the tasks in the WGs, nor do I suggest to change the charter= s.


JP> IF that were the case, we would not have formed two WG but one.=


I don't want to go in there.




 

I'm trying to figure out if LOADng is efficient over a mains-powered c= omputer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wi= de range would be magical !).

I cannot answer this question, as I have not deployed LOADng on a 8K/4= 8K RAM/ROM device. Those who have deployments and are willing to disclose d= etails, may have more details. Just one comment: I have implemented numerou= s ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest to implement and has the le= ast lines of code (by far) compared to all these other protocols that I hav= e implemented. If you can run any of these beforementioned protocols on suc= h a device, you can certainly run LOADng on it.

JP> I wish life was so simple =85 The argument around simplicity is= a recurring one. And unfortunately, simple protocols do not always WORK = =85 I could actually show
you, taking real-life networks (no simulation), how a (simple) reactiv= e routing protocol would break in a LLN.


As a matter of fact, there are large-scale deployments of LOADng by in= dustry. If LOADng was not working, I doubt that there would be any money sp= ent on that.

That is an interesting information. 
Do you have some material on that ? Was LOADng deployed over LLNs in t= hese cases ?
The description of these deployments could help to see what is targeti= ng.

Overall, I think the discussion need the new version of LOADng to move= on.
As IETF is coming fast, I guess that it will released in the coming da= ys ?
Once released, we could see how its relates to the MANET charter and s= cope, and do not conflict with RFC6550, the routing protocol for = LLNs designed by the IETF. 

C=E9dric.

And your last argument is not helpful; I am convinced that for any Sta= ndards Track routing protool, I can show you scenarios where it breaks (whe= reas in other scenarios it works fine). 

Best
Ulrich





 


I think Jiazi has already replied to that in a later mail. Interop != =3D performance test. LOADng (like any other MANET protocol) can run on any= medium. Testing it on wifi is a simple thing to do. Interop tests are sole= ly to find out if messages can be parsed correctly, and if the implementations behave according to the specificatio= n. 

As Jiazi pointed out correctly, I don't understand why we have this di= scussion before you have seen the latest LOADng revision. 

Best
Ulrich
 
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


--_000_208DA393C49945388FA47D04255B3665wattecocom_-- From abdussalambaryun@gmail.com Mon Oct 15 01:55:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA39221F8629 for ; Mon, 15 Oct 2012 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GyxO6EWtmiL for ; Mon, 15 Oct 2012 01:55:39 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75AFE21F8613 for ; Mon, 15 Oct 2012 01:55:39 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6074375vcb.31 for ; Mon, 15 Oct 2012 01:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1MxenxYmXwZnhpULnnWnPpE25PmWNmMA4v0faAy6aCc=; b=UyRWrBX+nYtgXG/L3U2bflHO9AzbXxwCT33e3yJpNrK7ufwU49CVvehjCKvZekqAoa 44VdareoZdhBGEBEG2SotwHtlbHT46CNSE19k0ZhqGLXVejV01geAOnbp9MvNifA3A4M 7/WnadincL70GI+vS6FkOW3jcdpn+GCOcaR3hqeNYUoXWsym71K02N3jP/pct9uX7jR4 eo/HT3Wf6KymTFK/YANmO4/pUQ8RvNO3iOVcXf1sj701uL/6AxKEl8SXtVgSV6Gk5OCj 3WW8JBHniYlhA4bs5uMc5rPiRnUVDmaGR6+gTQAQCT/JlLFMScFeNbp1Q8IO/FZQYnni uBUA== MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr6393945vec.51.1350291338668; Mon, 15 Oct 2012 01:55:38 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 15 Oct 2012 01:55:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Oct 2012 10:55:38 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 08:55:40 -0000 Hi Ulrich, My comments in line below, On 10/15/12, Ulrich Herberg wrote: > Hi AB, > > On Sun, Oct 14, 2012 at 7:58 AM, Abdussalam Baryun >> [...] > >> >> AB> I see there was an overlap when there was a claim that MANET routing >> are better than RPL performance in ROLL meetings, >> > and resulted to an I-D draft [2] produced for RPL experience, with authors >> discussing their observation without their recommendations for RPL >> specification RFC6550. >> > > I think that this discussion does not fit in the MANET mailing list. MANET > has not specified RFC6550. > That draft describes the authors' observations of the specification of > RFC6550. It does not say that "MANET routing are better than RPL > performance". I know that MANET did not specify the Request For Comment 6550, but MANET WG is an IETF WG, so if there is some idea its participants have they should *comment* as Reply to RFC6550 to ROLL WG *directly* for the IETF progress. If you read the minutes of MANET WG meeting IETF84 [1] you will find there was a discussion, my input was only a reflection. Please note that refering to I-D [2] was in the minutes which I agree that we SHOULD delete from our MANET minutes because it is another *overalp* (I don't beleive that the I-D name was pronounced in the meeting but the minute writter prefered to advertise the name). I RECOMMEND the Chair of MANET to delete the name of RPL experience I-D from the minutes because it is/was note said just indicated such as draft not named. > >> >> IMO, MANET routings are not best solutions for LLNs. The RPL [RFC6550] is >> the best solution so far that IETF has produced for such specific MANETs >> that are LLNs. >> > > In order to determine the performance or suitability of one protocol in > certain scenarios, it would be more helpful to come up with actual results, > than just saying "IMO". I seen results from participants *in IETF* about that performance, and if the IETF created a ROLL WG then it is a big reason known why (because MANET routings cannot handle *All LLNs* or specific-LLN scenarios), please note that until now there in no result presented in IETF shows against my opinion, therefore my opinion still stands, which I beleive it is the opinion of IETF. We should not take results from outside the IETF and beleive them just because they were presented in the world. We can present thoes results and discuss it so we can go progress in IETF. If no one likes to discuss them then they are not relavent in IETF until presented in meetings, discussion lists, new drafts, etc.. Therefore, OLSRv2, AODVv2, and LOADng cannot handle All LLNs like RPL [RFC6550] can handle, this is what I understand from IETF output decisions, if I am wrong please advise. [1] Minutes of MANET-WG IETF84, manet-tools, July, 2012. [2] http://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-04 Best Regards AB From abdussalambaryun@gmail.com Mon Oct 15 03:19:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7005321F867F for ; Mon, 15 Oct 2012 03:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYc3+UxdiTsR for ; Mon, 15 Oct 2012 03:19:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B87021F8687 for ; Mon, 15 Oct 2012 03:19:38 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6162724vcb.31 for ; Mon, 15 Oct 2012 03:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H7ISdRmX7uEe7MJyohU4pAyME/HsqmXW/KjLqJM5PXY=; b=ydEmHdWxt3UU0x8/Fo7wNLRJzo1PwZ2y7rMbStre+CXWMvbifR08ejCIC5CRgHUh+3 ZGDX6860bWZJvfVNHBMQ4RPJL+h8ap1200euM0RZBpZtfObk34iTVxTRkMjG119u1w3H ylK8fFMY3/FFZSUSXlfp1qNv3ZzywD1tp18Jg5Jryli38qK3Hyn/IvadM1JQObzF5GQ+ 947JHsP+dPf5apCBpU2b6mG7araHmetWXsgb3qBXIvfD44nlxZR0jSYTPfQ9i8wxInLx 8nIALaqrNHvLVunUGNE2zLv1ej9CwPGc4bcGSr/2GDm+H6Pn3o03objof2VoGVSkGnCa j1dA== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr5342652vdi.55.1350296377737; Mon, 15 Oct 2012 03:19:37 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 15 Oct 2012 03:19:37 -0700 (PDT) In-Reply-To: <208DA393-C499-4538-8FA4-7D04255B3665@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3665@watteco.com> Date: Mon, 15 Oct 2012 12:19:37 +0200 Message-ID: From: Abdussalam Baryun To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 10:19:39 -0000 Hi Cedric, > Overall, I think the discussion need the new version of LOADng to move on= . > As IETF is coming fast, I guess that it will released in the coming days = ? > Once released, we could see how its relates to the MANET charter and scop= e, > and do not conflict with RFC6550, the routing protocol for LLNs designed = by > the IETF. LOADng if to be adopted by MANET, I recommend the change of the name and specification. It should not be *LLN On demand Ad hoc Distance vector next generation*, I suggest to be : Lossy MANET On demand Ad hoc Distance-vector next generation (LOADng). So far the specification has included RFC5444 and AODV techniques which is excellent, just needs more editting to include MANET scenarios. AB > > C=E9dric. > From c.chauvenet@watteco.com Mon Oct 15 03:38:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D282B21F85A2 for ; Mon, 15 Oct 2012 03:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO1CMNE+O27U for ; Mon, 15 Oct 2012 03:38:29 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 353CE21F8589 for ; Mon, 15 Oct 2012 03:38:29 -0700 (PDT) Received: from mail216-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Oct 2012 10:38:28 +0000 Received: from mail216-va3 (localhost [127.0.0.1]) by mail216-va3-R.bigfish.com (Postfix) with ESMTP id 3C0F384029C; Mon, 15 Oct 2012 10:38:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc89bh1432Izz1202h1d1ah1d2ahzzz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail216-va3 (localhost.localdomain [127.0.0.1]) by mail216-va3 (MessageSwitch) id 1350297506151892_25594; Mon, 15 Oct 2012 10:38:26 +0000 (UTC) Received: from VA3EHSMHS042.bigfish.com (unknown [10.7.14.242]) by mail216-va3.bigfish.com (Postfix) with ESMTP id 16C2F180049; Mon, 15 Oct 2012 10:38:26 +0000 (UTC) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by VA3EHSMHS042.bigfish.com (10.7.99.52) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Oct 2012 10:38:24 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.67.165]) with mapi id 14.16.0207.009; Mon, 15 Oct 2012 10:38:23 +0000 From: C Chauvenet To: Abdussalam Baryun Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAIAAdJeAgABi3ICAAIeagIABJjmAgAAaN4CAAAU/gA== Date: Mon, 15 Oct 2012 10:38:23 +0000 Message-ID: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3665@watteco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <031274D390962C469B3D27D19BEDC179@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 10:38:29 -0000 Hi AB,=20 Le 15 oct. 2012 =E0 12:19, Abdussalam Baryun a =E9crit : > Hi Cedric, >=20 >> Overall, I think the discussion need the new version of LOADng to move o= n. >> As IETF is coming fast, I guess that it will released in the coming days= ? >> Once released, we could see how its relates to the MANET charter and sco= pe, >> and do not conflict with RFC6550, the routing protocol for LLNs designed= by >> the IETF. >=20 > LOADng if to be adopted by MANET, I recommend the change of the name > and specification. It should not be *LLN On demand Ad hoc Distance > vector next generation*, I suggest to be : Lossy MANET On demand Ad > hoc Distance-vector next generation (LOADng). I think it is the responsibility of authors to choose the title of their do= cument, but LLN references should definitely move away, and not only in the= title, as it is a MANET protocol. > So far the specification has included RFC5444 and AODV techniques > which is excellent, just needs more editting to include MANET > scenarios. or exclude LLN-specific scenarios... C=E9dric. >=20 > AB >=20 >>=20 >> C=E9dric. >>=20 >=20 From boberry@cisco.com Mon Oct 15 04:32:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A32D21F869E for ; Mon, 15 Oct 2012 04:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmlQ22yXeLYQ for ; Mon, 15 Oct 2012 04:32:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD0421F863B for ; Mon, 15 Oct 2012 04:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3317; q=dns/txt; s=iport; t=1350300745; x=1351510345; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KZViWhuWT69miglVgZhOePFRDzahVZQn2FmmY0cQbtA=; b=lcpVsa2WaswfeY77tP926ctbj97WXfz8zm71IQcECh6JIUmWPC9kzNEl vIY/BBzl8n7Z/iAeAcBirg0jgvZYb1vridstiHQzBH9lPVKkupCJ+DSpc K3Bw1Q4DVbCIpatfTVFCBOy1GNBef9/TKyz9wrwOtiLbFQnjuo9yMmABc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACjze1CtJV2c/2dsb2JhbABFv3iBCIIgAQEBAwEBAQEPAVsLBQsLGCcHJx8RBhMbB4dcBgudV59Ei1kUhUlgA5VshWKIY4FrgwmBPgk X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131662736" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 15 Oct 2012 11:32:25 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-91.cisco.com [10.81.230.91]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9FBWOf3002505; Mon, 15 Oct 2012 11:32:24 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Bo Berry In-Reply-To: <507BA1AA.7080607@fkie.fraunhofer.de> Date: Mon, 15 Oct 2012 07:32:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 11:32:26 -0000 On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: > On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: >> I've asked twice now (this email makes attempt number 3) for someone = to suggest some text to clarify what a router or modem would do with an = UNKNOWN metric. So far, what I've seen is a potentially new *way* of = specifying UNKNOWN - one that makes more sense than picking some = arbitrary code point. But no actual text to suggest what either of the = endpoints would *do* with the data. Maybe I'm old, feeble, and not very = bright - but I'm looking for suggestions that start with "A router = receiving a metric value of UNKNOWN MUST=85" or "An implementation = receiving an UNKNOWN indication SHOULD=85" or something along those = lines. Barring that, the only text I've got to insert is what I = suggested before: >>>=20 >>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where = RLQ is supported, but not currently calculable. The authors have no idea = under what circumstances this would occur. Routers receiving a value of = RLQ_UNKNOWN are free to take any action deemed appropriate, including = (but not limited to) ignoring the value, producing log messages, or = bursting into flames. The RLQ_UNKNOWN (TBD) value was added at the = request of the working group, as consensus formed around the key ideas = that this MAY allow for innovation, even though none of the working = group members were able to note a set of circumstances under which this = innovation might take place. So, in an effort to stop the email storm, = the authors added the additional code point." >=20 > If we use Teco's suggested solution (using 'length =3D 0' to make an = unknown but supported TLV): >=20 > ---- > Radio implementations MAY use a metric TLV without value and length 0 = to signal a not measurable but supported TLV. >=20 > Most router implementations will process this metric TLV in the same = way as a missing metric TLV. > ---- >=20 > The "will" in the second sentence could also be a "SHOULD" or "MAY", I = am not sure about this. >=20 > "Metric TLV" would be a list of all DLEP TLVs that transport a metric = value like RLQ, delay, current/maximum link speed, ... >=20 For my clarity, the proposal above only applies to metrics. Not credits = or other TLVs. I understand the proposal to use 0-length but I'm still not = understanding the value. If I'm developing the radio code to send the metrics, why send a = 0-length TLV when the TLV can be omitted? This adds test vectors to be verified = for no or little value.=20 Taking the extreme of the proposal the radio can send a Neighbor Up = filled with=20 0-length TLVs which would have no value or purpose from a router's = perspective.=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Mon Oct 15 04:44:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A384B21F86A4 for ; Mon, 15 Oct 2012 04:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyOCkaNeVBVg for ; Mon, 15 Oct 2012 04:44:15 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAD021F8680 for ; Mon, 15 Oct 2012 04:44:15 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TNj5i-0003fb-SR; Mon, 15 Oct 2012 13:44:14 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TNj5i-0006q0-Pn; Mon, 15 Oct 2012 13:44:14 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Oct 2012 13:44:14 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 15 Oct 2012 13:44:14 +0200 Message-ID: <507BF707.1000303@fkie.fraunhofer.de> Date: Mon, 15 Oct 2012 13:44:07 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Bo Berry References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070802090100020609080007" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 15 Oct 2012 11:44:14.0577 (UTC) FILETIME=[66A44610:01CDAACA] X-Virus-Scanned: yes (ClamAV 0.97.5/15460/Mon Oct 15 06:36:59 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 9fba06858ea504e244212894029289c9 Cc: manet@ietf.org Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 11:44:16 -0000 --------------ms070802090100020609080007 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/15/2012 01:32 PM, Bo Berry wrote: > On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >> If we use Teco's suggested solution (using 'length =3D 0' to make an u= nknown but supported TLV): >> >> ---- >> Radio implementations MAY use a metric TLV without value and length 0 = to signal a not measurable but supported TLV. >> >> Most router implementations will process this metric TLV in the same w= ay as a missing metric TLV. >> ---- >> >> The "will" in the second sentence could also be a "SHOULD" or "MAY", I= am not sure about this. >> >> "Metric TLV" would be a list of all DLEP TLVs that transport a metric = value like RLQ, delay, current/maximum link speed, ... >> > > For my clarity, the proposal above only applies to metrics. Not credit= s or other TLVs. Yes, I think so. > I understand the proposal to use 0-length but I'm still not understandi= ng the value. > If I'm developing the radio code to send the metrics, why send a 0-leng= th > TLV when the TLV can be omitted? This adds test vectors to be verified= for no > or little value. > > Taking the extreme of the proposal the radio can send a Neighbor Up fil= led with > 0-length TLVs which would have no value or purpose from a router's pers= pective. As I wrote in my mail to Stan, I am primarily interested in getting the=20 fact that a router cannot calculate or support a TLV like RLQ. I=20 personally do not care about the difference of both, so I would be okay=20 with a "if RLQ is not calculable or supported, the radio MUST not=20 include the RLQ TLV into the message". This "RLQ=3D100 for non-measurable= =20 links" as in PPPoE is a disaster for Adhoc networks. But people argued that the difference between "not supported" and "not=20 calculable" is important... thats where the discussion about "additional = encoding for non-calculable" started. Maybe it would be a cleaner way to look into the proposal of Powell Ill=20 and Christoph Barz to give the radio a way to tell the router what=20 things it supports (in the discovery message?). This would allow us to=20 drop this "length 0/value=3D255" thing for RLQs, because the Radio could = just drop the TLV if it cannot calculate it. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070802090100020609080007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTUxMTQ0MTJaMCMGCSqGSIb3DQEJBDEWBBQkcp7jMr19wfEYCwX6zWFgfxV7NjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEARjYDwdgZHyJFSPETMHD4Ht8KuuO69IAV0ixLaKvqLdn9 KbX6l17Hp+PP1Nhfg5f9NmFm81tWu+rYor7okQmFI72P3QnUTFqAQDJLRs7gvbqjhfvaFMLe ap4RKGoW66sUbli0XZj92Be+zHwCzQo3fXr0nHerRWayN/ZcLBImL1wy4Xab0t6hHoo7rWh3 LCLenHOjATpGNcN1eIquQHRVXfbSh9v958nM6HAhrOkresHpt3Q1owX/8DeKzo65Qnew5oER NLvB1mk0DG+vyPwghRc31/1v5hMnulYFCoy4aNZAiBDyKeFiQc2pishPHzSSZxfz7yesI0rC V/G08kLnxQAAAAAAAA== --------------ms070802090100020609080007-- From ietf@thomasclausen.org Mon Oct 15 06:25:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1543421F8754 for ; Mon, 15 Oct 2012 06:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlGMNThCnZeD for ; Mon, 15 Oct 2012 06:25:19 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A6FD621F8752 for ; Mon, 15 Oct 2012 06:25:19 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5507AA589E for ; Mon, 15 Oct 2012 06:25:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E48F41BCCF18; Mon, 15 Oct 2012 06:25:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.4] (221x249x212x15.ap221.ftth.ucom.ne.jp [221.249.212.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A5B6B1BCCF14; Mon, 15 Oct 2012 06:25:17 -0700 (PDT) References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3 665@watteco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Mon, 15 Oct 2012 22:25:17 +0900 To: C Chauvenet Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:25:20 -0000 On 15 oct. 2012, at 19:38, C Chauvenet wrote: > Hi AB,=20 >=20 > Le 15 oct. 2012 =C3=A0 12:19, Abdussalam Baryun a =C3=A9crit : >=20 >> Hi Cedric, >>=20 >>> Overall, I think the discussion need the new version of LOADng to move o= n. >>> As IETF is coming fast, I guess that it will released in the coming days= ? >>> Once released, we could see how its relates to the MANET charter and sco= pe, >>> and do not conflict with RFC6550, the routing protocol for LLNs designed= by >>> the IETF. >>=20 >> LOADng if to be adopted by MANET, I recommend the change of the name >> and specification. It should not be *LLN On demand Ad hoc Distance >> vector next generation*, I suggest to be : Lossy MANET On demand Ad >> hoc Distance-vector next generation (LOADng). >=20 > I think it is the responsibility of authors to choose the title of their d= ocument, but LLN references should definitely move away, and not only in the= title, as it is a MANET protocol. >=20 >> So far the specification has included RFC5444 and AODV techniques >> which is excellent, just needs more editting to include MANET >> scenarios. >=20 > or exclude LLN-specific scenarios... >=20 That would be very intellectually dishonest, considering that LOADng is wide= ly deployed on what you call "LLN-specific scenarios" (although I adhere to w= hat Adrian said: that LLNs are a subset of MANETs) Thomas > C=C3=A9dric. >=20 >>=20 >> AB >>=20 >>>=20 >>> C=C3=A9dric. >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Mon Oct 15 06:31:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7512921F86C3 for ; Mon, 15 Oct 2012 06:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFAtMILq-bXp for ; Mon, 15 Oct 2012 06:31:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B2FFA21F865F for ; Mon, 15 Oct 2012 06:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1350307902; x=1351517502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mOBZ8c+vfgejpG80JRkyLwl+c2jDoi/Z0Pz81IAAeVc=; b=in4XB+5pnQhQTIKIIk1fvmyYndARE4NbawXRIee1FmjKuf4rAGCIsK2t SEBV0HGab0Vo7IRlIqOV3CsGh2y+BQv2pNU7l3Z8QHvlvN6E3Gtd/rx3O v66E4v6/cVoftDBN7k9MWsfUR79wPag59WhDpKPSqmtreSfZRldvDxbnD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPYOfFCtJV2d/2dsb2JhbABFv3iBCIIgAQEBAwEBAQEPAVsLBQsCAQgiJCcLJQIEDgUIGodcBgudZZ9PBItZhV1gA6QxgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131438508" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2012 13:31:42 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9FDVgKI030945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 13:31:42 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 08:31:40 -0500 From: "JP Vasseur (jvasseur)" To: C Chauvenet Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Mon, 15 Oct 2012 13:31:39 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE2A6B@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3665@watteco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--38.686100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <7154C3B58696A8469E8B2734E4625331@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:31:43 -0000 Hi, On Oct 15, 2012, at 12:38 PM, C Chauvenet wrote: > Hi AB,=20 >=20 > Le 15 oct. 2012 =E0 12:19, Abdussalam Baryun a =E9crit : >=20 >> Hi Cedric, >>=20 >>> Overall, I think the discussion need the new version of LOADng to move = on. >>> As IETF is coming fast, I guess that it will released in the coming day= s ? >>> Once released, we could see how its relates to the MANET charter and sc= ope, >>> and do not conflict with RFC6550, the routing protocol for LLNs designe= d by >>> the IETF. >>=20 >> LOADng if to be adopted by MANET, I recommend the change of the name >> and specification. It should not be *LLN On demand Ad hoc Distance >> vector next generation*, I suggest to be : Lossy MANET On demand Ad >> hoc Distance-vector next generation (LOADng). >=20 > I think it is the responsibility of authors to choose the title of their = document, but LLN references should definitely move away, and not only in t= he title, as it is a MANET protocol. >=20 >> So far the specification has included RFC5444 and AODV techniques >> which is excellent, just needs more editting to include MANET >> scenarios. >=20 > or exclude LLN-specific scenarios=85 and change the name, to avoid mis-interpretation =85 Thanks. JP. >=20 > C=E9dric. >=20 >>=20 >> AB >>=20 >>>=20 >>> C=E9dric. >>>=20 >>=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Mon Oct 15 07:00:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969581F041F for ; Mon, 15 Oct 2012 07:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaCZC4t+GcEX for ; Mon, 15 Oct 2012 07:00:32 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40D1F040A for ; Mon, 15 Oct 2012 07:00:32 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 9BB45A395C for ; Mon, 15 Oct 2012 07:00:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0850E1BCD5A3; Mon, 15 Oct 2012 07:00:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.4] (221x249x212x15.ap221.ftth.ucom.ne.jp [221.249.212.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C03081BCD5AE; Mon, 15 Oct 2012 07:00:30 -0700 (PDT) References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <43C2092B-D60C-4993-9D7A-9ED771B7D6E2@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Mon, 15 Oct 2012 23:00:29 +0900 To: "JP Vasseur (jvasseur)" Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:00:32 -0000 On 14 oct. 2012, at 16:07, "JP Vasseur (jvasseur)" wrot= e: >> I cannot answer this question, as I have not deployed LOADng on a 8K/48K R= AM/ROM device. Those who have deployments and are willing to disclose detail= s, may have more details. Just one comment: I have implemented numerous ad-h= oc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by far the simplest= to implement and has the least lines of code (by far) compared to all these= other protocols that I have implemented. If you can run any of these before= mentioned protocols on such a device, you can certainly run LOADng on it. >=20 > JP> I wish life was so simple =E2=80=A6 The argument around simplicity is a= recurring one. And unfortunately, simple protocols do not always WORK =E2=80= =A6 I could actually show > you, taking real-life networks (no simulation), how a (simple) reactive ro= uting protocol would break in a LLN. That would be an instance of the argument: "Show me protocol X, and I can construct a scenario wherein protoco= l X breaks". That doesn't mean, however, that protocol X cannot be (and has not been and w= ill not be) successfully deployed in other scenarios. Thus, I'd really suggest not going there (the IETF-version of Godwin's law?)= . Thomas= From Martin.Duke@boeing.com Mon Oct 15 07:10:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF011E8099 for ; Mon, 15 Oct 2012 07:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFAJ8wkoyYLp for ; Mon, 15 Oct 2012 07:10:43 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 285BC11E808A for ; Mon, 15 Oct 2012 07:10:43 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9FEAg45028560 for ; Mon, 15 Oct 2012 09:10:42 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9FEAfM0028536 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 15 Oct 2012 09:10:42 -0500 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 15 Oct 2012 07:10:41 -0700 From: "Duke, Martin" To: "Stan Ratliff (sratliff)" , Henning Rogge Date: Mon, 15 Oct 2012 07:10:40 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4CAAAUlAIAAE+oAgAAjnQCAAAVpAIAAASmAgADq2wCAAELQAIAAFCoAgAAUKgCAAAbRAIAABH6AgAE84wCAAOzCgIAAlvbA Message-ID: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:10:45 -0000 The reason I haven't responded to this request is because I haven't been ab= le to find anywhere in the draft that instructs the router on how to handle= ANY of these metrics- RLQ, Latency, whatever. In fact, I thought the way t= he router used information about the radio was out of scope for this draft. Martin -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff (sratliff) Sent: Sunday, October 14, 2012 5:09 PM To: Henning Rogge Cc: manet@ietf.org; Bo Berry (boberry) Subject: Re: [manet] Some comments on manet-dlep-03 I've asked twice now (this email makes attempt number 3) for someone to sug= gest some text to clarify what a router or modem would do with an UNKNOWN m= etric. So far, what I've seen is a potentially new *way* of specifying UNKN= OWN - one that makes more sense than picking some arbitrary code point. But= no actual text to suggest what either of the endpoints would *do* with the= data. Maybe I'm old, feeble, and not very bright - but I'm looking for sug= gestions that start with "A router receiving a metric value of UNKNOWN MUST= ..." or "An implementation receiving an UNKNOWN indication SHOULD..." or so= mething along those lines. Barring that, the only text I've got to insert i= s what I suggested before:=20 >=20 > "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ i= s supported, but not currently calculable. The authors have no idea under w= hat circumstances this would occur. Routers receiving a value of RLQ_UNKNOW= N are free to take any action deemed appropriate, including (but not limite= d to) ignoring the value, producing log messages, or bursting into flames. = The RLQ_UNKNOWN (TBD) value was added at the request of the working group, = as consensus formed around the key ideas that this MAY allow for innovation= , even though none of the working group members were able to note a set of = circumstances under which this innovation might take place. So, in an effor= t to stop the email storm, the authors added the additional code point." >=20 Stan On Oct 14, 2012, at 6:01 AM, Henning Rogge wrote: > I think the idea is not bad. >=20 > IF we decide to use a special codepoint for "unknown TLV value", using=20 > "length =3D 0" would give us a generic way for doing it for all kind of=20 > additional metric TLVs... instead of doing this "what to use for=20 > UNKNOWN" brainstorming again. >=20 > It also makes it easier to include the UNKNOWN codepoint into metrics=20 > which have no bits/values left. >=20 > Henning Rogge >=20 > On Sat, Oct 13, 2012 at 5:06 PM, Bo Berry wrote: >> Teco >> Thanks, this helps. So let's see what others think. >> Have a great wkend. >>=20 >> -Bo >>=20 >>=20 >> On Oct 13, 2012, at 10:50 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: >>>=20 >>>> Teco, >>>> I do not understand it and it's not been described in a manner that=20 >>>> I can. But if we can not understand it, we will not be successful=20 >>>> describing it such that it can be useful. >>>>=20 >>>> If you can provide meaningful, descriptive text, that would help. >>>> At this time, "prepare for data items that can fall back to unknown" >>>> does not help me. What do you propose as optional data items and=20 >>>> how do you propose, by what mechanism, they fall back? Do they=20 >>>> fall back in the radio or router, or both? >>>=20 >>> The optional Data Item TLVs for Neighbor Up are in the draft: >>> - IPv4 Address >>> - IPv6 Address >>> - Maximum Data Rate >>> - Current Data Rate >>> - Latency >>> - Expected Forwarding Time >>> - Resources >>> - Relative Link Factor >>> - Credit Window Status >>> Neighbor Up messages would be send by router, although the draft=20 >>> mentions the router can send it also. >>> Relative Link Factor should be Relative Link Quality (posted before,=20 >>> I think). In Neighbor Update, Expected Forwarding Time is missing. >>>=20 >>> My comment is on the protocol. Optional data item TLVs can be=20 >>> present, or not. There was a proposal for TLV with an UNKNOWN codepoint= , for RLQ. >>> I don't see much difference in UNKNOWN and not sending the TLV.=20 >>> Then, this UNKNOWN applies to all optional Data Item TLVs. So if we=20 >>> just add a mechanism that enables sending UNKNOWN for all optional=20 >>> Data Item TLVs, we are done. Addresses have the drop already. The=20 >>> other TLVs can have the length=3D0. That's all. I provided the text alr= eady. >>>=20 >>> I can't be more clear. Sorry. >>>=20 >>> Teco >>>=20 >>>>=20 >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: >>>>=20 >>>>> DLEP is (mainly) getting the neighbor information base from radio=20 >>>>> to router, as accurate as possible. It is up to the router to use=20 >>>>> this for route calculation. >>>>>=20 >>>>> This discussion is not about using RFC 5444. >>>>>=20 >>>>> It is about transfer of "hey there, I don't have this info anymore". >>>>> Bo and Stan say, this is not needed. Others say, there is a need for = it. >>>>> I agree with the others, because I cannot see a reason a radio is=20 >>>>> only allowed *once* during neighbor_up state to miss data items.=20 >>>>> We better prepare for data items that can fall back to unknown. I=20 >>>>> say: let's allow this for all optional data items. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>> Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende geschr= even: >>>>>=20 >>>>>> I agree we should design for the present MANET technologies and=20 >>>>>> future, for the protocol completion. Do you mean router-state as=20 >>>>>> the DLEP-server state? IF yes THEN I agree with you. IF not THEN,=20 >>>>>> I Don't understand why we need to consider router states. >>>>>>=20 >>>>>> DLEP considers the session between server and client states,=20 >>>>>> other states are not inscope. For simplicity, DLEP should be=20 >>>>>> abstract from MANET-Router's (OLSRv2 or AODVv2) states, decisions=20 >>>>>> or processes, an optional future interaction may be useful but=20 >>>>>> complicated (will need RFC5444). >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>> On 10/13/12, Teco Boot wrote: >>>>>>>=20 >>>>>> My point is that the DLEP protocol should be "complete", in that=20 >>>>>> the radio is able to get the router in a certain state, in=20 >>>>>> another state and get back in the earlier state. RLQ is just an exam= ple. >>>>>>=20 >>>>>> If you think this makes no sense with the radios you have seen up=20 >>>>>> to now, you could be right. Tomorrow, you could have a different opi= nion. >>>>>> I saw on this mailing list some of us see already the requirement=20 >>>>>> the protocol shall be "complete". >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > -- > Steven Hawkings about cosmic inflation: "An increase of billions of=20 > billions of percent in a tiny fraction of a second. Of course, that=20 > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Mon Oct 15 07:12:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6541311E80D2 for ; Mon, 15 Oct 2012 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw7eXLSKBD+O for ; Mon, 15 Oct 2012 07:12:54 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9AAA11E80D1 for ; Mon, 15 Oct 2012 07:12:54 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2585110dan.31 for ; Mon, 15 Oct 2012 07:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jx2Dt2uyQBzmFNQYZOz3End9Pk9xnSQtjDteL+oQ9JY=; b=LJhTLJKXKBAiBAAwoCSJK+3mkbKXpAwOQcZx6rBOJqjGFyYB2xVsjn7/t+OsntE5O3 DafnAiSIIZ6miqrQWKJnsQBee3j09v6RXWibX/4vdfr6OvJ0LWd5gxr3JQGqW70VBBnC N1XjGphtF8dvxuAGivYdlXvkZRFPvlcEvbT7jdFLTDKfXUt5W/hBthsq+8dFktKFWEHB EnbLC8jL3igf/nt6qWDoxKfgD1wy7Bx5//S5339l6L0WJ2GwU37zAKrrdp/xqx7skzij 29SP/B2MGIhpYJ6UTErUwsbv0/p+pifJA+OiiV3qVL6tJqDc8t3m/oUYb1/R6S/HkM46 gDpQ== Received: by 10.68.221.166 with SMTP id qf6mr37503537pbc.54.1350310374110; Mon, 15 Oct 2012 07:12:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Mon, 15 Oct 2012 07:12:33 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Mon, 15 Oct 2012 16:12:33 +0200 Message-ID: To: "Duke, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:12:55 -0000 On Mon, Oct 15, 2012 at 4:10 PM, Duke, Martin wrot= e: > The reason I haven't responded to this request is because I haven't been = able to find anywhere in the draft that instructs the router on how to hand= le ANY of these metrics- RLQ, Latency, whatever. In fact, I thought the way= the router used information about the radio was out of scope for this draf= t. I still think we need rules how the RADIO side produce the information. Otherwise the router will not be sure what the information means. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From jvasseur@cisco.com Mon Oct 15 07:24:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7B811E80D2 for ; Mon, 15 Oct 2012 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LECD3RuGKb-s for ; Mon, 15 Oct 2012 07:24:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E347221F8681 for ; Mon, 15 Oct 2012 07:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2152; q=dns/txt; s=iport; t=1350311081; x=1351520681; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eM5hJnBwUtRD09YrDTFBSTguPES6/Z4MatIeHMt+Mck=; b=DOEnV52cKc1ESVaHLZM6ri070/IaS1ftbDA38y9VwUVIbB+8V6PwQqD7 DdokgD0wjqWHkJSBudTe8Ve2Xku3SsWxK6RYMl11RtdZbkx8No2q/s/My lXzHC45rqMzGx+egg1CEpXAmN4z7fk91vEBOVRG/L5sayNB0TU9d8YMbb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH4bfFCtJV2Z/2dsb2JhbABFv3WBCIIgAQEBAwEBAQEPAVsLBQsCAQgYCiQnCyUCBA4FCBqHXAYLngKfUgSLWYVdYAOII5wOgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131679508" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2012 14:24:40 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9FEOe59001026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 14:24:40 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 09:24:39 -0500 From: "JP Vasseur (jvasseur)" To: Thomas Heide Clausen Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Mon, 15 Oct 2012 14:24:39 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3 665@watteco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> In-Reply-To: <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--40.069300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <187A81C7A3F35B48BF1757FE28805AAC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:24:48 -0000 On Oct 15, 2012, at 3:25 PM, Thomas Heide Clausen wrote: >=20 > On 15 oct. 2012, at 19:38, C Chauvenet wrote: >=20 >> Hi AB,=20 >>=20 >> Le 15 oct. 2012 =E0 12:19, Abdussalam Baryun a =E9crit : >>=20 >>> Hi Cedric, >>>=20 >>>> Overall, I think the discussion need the new version of LOADng to move= on. >>>> As IETF is coming fast, I guess that it will released in the coming da= ys ? >>>> Once released, we could see how its relates to the MANET charter and s= cope, >>>> and do not conflict with RFC6550, the routing protocol for LLNs design= ed by >>>> the IETF. >>>=20 >>> LOADng if to be adopted by MANET, I recommend the change of the name >>> and specification. It should not be *LLN On demand Ad hoc Distance >>> vector next generation*, I suggest to be : Lossy MANET On demand Ad >>> hoc Distance-vector next generation (LOADng). >>=20 >> I think it is the responsibility of authors to choose the title of their= document, but LLN references should definitely move away, and not only in = the title, as it is a MANET protocol. >>=20 >>> So far the specification has included RFC5444 and AODV techniques >>> which is excellent, just needs more editting to include MANET >>> scenarios. >>=20 >> or exclude LLN-specific scenarios... >>=20 >=20 > That would be very intellectually dishonest, JP> Let's not make any personal statement. > considering that LOADng is widely deployed on what you call "LLN-specific= scenarios" (although I adhere to what Adrian said: that LLNs are a subset = of MANETs) JP> Then document the scenarios, and run them by the ROLL WG, since LLNs ro= uting is being discussed in the ROLL WG, as decided by the IESG. Thanks. Best Regards. JP. >=20 > Thomas >=20 >> C=E9dric. >>=20 >>>=20 >>> AB >>>=20 >>>>=20 >>>> C=E9dric. >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Mon Oct 15 07:30:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3070511E80E1 for ; Mon, 15 Oct 2012 07:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou7s5fAskqEL for ; Mon, 15 Oct 2012 07:30:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4811E80D9 for ; Mon, 15 Oct 2012 07:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5562; q=dns/txt; s=iport; t=1350311404; x=1351521004; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d79cF/ig1kboGuWhlads69bvU1sLfuXqa6d41a/K1CI=; b=AjZdh/+9seLhPdDtPNkAuC3nDJKlb8fj/Vd6AFNxw78pxq6vQ+Qk/QsK bL05oDQZQaXdDikW7n5V7WafVowkH++0vxgDYgu9/jqDGhWJSxG7a2yvC 7Tl/s5PBSujJB58Ty1HZL3YtBnzrCZv+tbidgwugxa6kJMymRtB3y+EeD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANgcfFCtJV2b/2dsb2JhbABFv3WBCIIhAQEEAQEBDwFbCxACAQgiHQcnCxQRAgQOBQgah2ILnXSfWQSRNmADpDGBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208,217";a="131679898" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 15 Oct 2012 14:30:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9FEU3ZB002802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 14:30:04 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 09:30:03 -0500 From: "JP Vasseur (jvasseur)" To: Thomas Heide Clausen Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe85e6wzkA Date: Mon, 15 Oct 2012 14:30:03 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE2EE0@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3 665@watteco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--33.764800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FE2EE0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:30:05 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FE2EE0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable By the way =85 [snip] That would be very intellectually dishonest, JP> Let's not make any personal statement. considering that LOADng is widely deployed on what you call "LLN-specific s= cenarios" (although I adhere to what Adrian said: that LLNs are a subset of= MANETs) JP2> We also know a number of deployed proprietary protocols =85 which does= not mean that they should become IETF standards ... JP> Then document the scenarios, and run them by the ROLL WG, since LLNs ro= uting is being discussed in the ROLL WG, as decided by the IESG. Thanks. Best Regards. JP. Thomas C=E9dric. AB C=E9dric. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FE2EE0xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable By the way =85

[snip]





That would be very intellectually dishonest,

JP> Let's not make any personal statement.

considering that LOADng is widely deployed on wha= t you call "LLN-specific scenarios" (although I adhere to what Ad= rian said: that LLNs are a subset of MANETs)


JP2> We also know a number of deployed proprietary protocols =85 wh= ich does not mean that they should become IETF standards ...

JP> Then document the scenarios, and run them by the ROLL WG, since= LLNs routing is being discussed in the ROLL WG, as decided by the IESG.
Thanks.

Best Regards.

JP.


Thomas

C=E9dric.


AB


C=E9dric.


_______________________________________________
manet mailing list
manet@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/manet

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

--_000_03B78081B371D44390ED6E7BADBB4A7721FE2EE0xmbrcdx02ciscoc_-- From ietf@thomasclausen.org Mon Oct 15 07:31:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A50C11E80E1 for ; Mon, 15 Oct 2012 07:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPKHaVRQu5wX for ; Mon, 15 Oct 2012 07:31:39 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7525721F86DD for ; Mon, 15 Oct 2012 07:31:39 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5224BA399E for ; Mon, 15 Oct 2012 07:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id ED2491BCE098; Mon, 15 Oct 2012 07:31:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.3] (221x249x212x15.ap221.ftth.ucom.ne.jp [221.249.212.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 5965B1BCE08B; Mon, 15 Oct 2012 07:31:38 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Heide Clausen In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> Date: Mon, 15 Oct 2012 16:31:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3 665@watteco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> To: "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1498) Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:31:40 -0000 On Oct 15, 2012, at 16:24 , "JP Vasseur (jvasseur)" = wrote: >=20 > On Oct 15, 2012, at 3:25 PM, Thomas Heide Clausen wrote: >=20 >>=20 >> On 15 oct. 2012, at 19:38, C Chauvenet = wrote: >>=20 >>> Hi AB,=20 >>>=20 >>> Le 15 oct. 2012 =E0 12:19, Abdussalam Baryun a =E9crit : >>>=20 >>>> Hi Cedric, >>>>=20 >>>>> Overall, I think the discussion need the new version of LOADng to = move on. >>>>> As IETF is coming fast, I guess that it will released in the = coming days ? >>>>> Once released, we could see how its relates to the MANET charter = and scope, >>>>> and do not conflict with RFC6550, the routing protocol for LLNs = designed by >>>>> the IETF. >>>>=20 >>>> LOADng if to be adopted by MANET, I recommend the change of the = name >>>> and specification. It should not be *LLN On demand Ad hoc Distance >>>> vector next generation*, I suggest to be : Lossy MANET On demand Ad >>>> hoc Distance-vector next generation (LOADng). >>>=20 >>> I think it is the responsibility of authors to choose the title of = their document, but LLN references should definitely move away, and not = only in the title, as it is a MANET protocol. >>>=20 >>>> So far the specification has included RFC5444 and AODV techniques >>>> which is excellent, just needs more editting to include MANET >>>> scenarios. >>>=20 >>> or exclude LLN-specific scenarios... >>>=20 >>=20 >> That would be very intellectually dishonest, >=20 > JP> Let's not make any personal statement. My comment was nothing more than a statement as to what the should be = written in a document as to a protocol applicability. I believe that it = would be intellectually dishonest of the authors (or WG) of a document = to deliberately exclude or distort known facts of the applicability of a = protocol. I'd assume that any IETFer would agree with this by default. Thomas >> considering that LOADng is widely deployed on what you call = "LLN-specific scenarios" (although I adhere to what Adrian said: that = LLNs are a subset of MANETs) >=20 > JP> Then document the scenarios, and run them by the ROLL WG, since = LLNs routing is being discussed in the ROLL WG, as decided by the IESG. >=20 > Thanks. >=20 > Best Regards. >=20 > JP. >=20 >>=20 >> Thomas >>=20 >>> C=E9dric. >>>=20 >>>>=20 >>>> AB >>>>=20 >>>>>=20 >>>>> C=E9dric. >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From jvasseur@cisco.com Mon Oct 15 07:40:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3D31F0429 for ; Mon, 15 Oct 2012 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCPDUd53ZWkI for ; Mon, 15 Oct 2012 07:40:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 818F01F0425 for ; Mon, 15 Oct 2012 07:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3192; q=dns/txt; s=iport; t=1350312003; x=1351521603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jiY9G1upZ87Mo303JKEYA7mrkb3voWkgosFDZF6dPuA=; b=dQOGj1y40nx8zljX6FtWCRLGepsVBf9zoj2Pcv9lCze9BDcp0Ia9POOv 0hLISEORFjN4Ug6xVHqSBU/15f8NjfbC0pnvuQ+keELU218Zabmt+Y3DT 3QrOGTU5zD+ligNhW/YcxlmVVlEvr+XJL4Sro0iQjs5oR/wZoctdXwgD+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADYffFCtJV2a/2dsb2JhbABFv3WBCIIgAQEBAwEBAQEPAVsLEAIBCBgKJCcLJQIEDgUIGodcBgudbZ9dBItZhV1gA4gjnA6Ba4Jtghc X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131665341" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2012 14:40:03 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9FEe3vF022816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 14:40:03 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 09:40:02 -0500 From: "JP Vasseur (jvasseur)" To: Thomas Heide Clausen Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Mon, 15 Oct 2012 14:40:02 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3 665@watteco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--42.011400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:40:04 -0000 On Oct 15, 2012, at 4:31 PM, Thomas Heide Clausen wrote: >=20 > On Oct 15, 2012, at 16:24 , "JP Vasseur (jvasseur)" = wrote: >=20 >>=20 >> On Oct 15, 2012, at 3:25 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>> On 15 oct. 2012, at 19:38, C Chauvenet wrote: >>>=20 >>>> Hi AB,=20 >>>>=20 >>>> Le 15 oct. 2012 =E0 12:19, Abdussalam Baryun a =E9crit : >>>>=20 >>>>> Hi Cedric, >>>>>=20 >>>>>> Overall, I think the discussion need the new version of LOADng to mo= ve on. >>>>>> As IETF is coming fast, I guess that it will released in the coming = days ? >>>>>> Once released, we could see how its relates to the MANET charter and= scope, >>>>>> and do not conflict with RFC6550, the routing protocol for LLNs desi= gned by >>>>>> the IETF. >>>>>=20 >>>>> LOADng if to be adopted by MANET, I recommend the change of the name >>>>> and specification. It should not be *LLN On demand Ad hoc Distance >>>>> vector next generation*, I suggest to be : Lossy MANET On demand Ad >>>>> hoc Distance-vector next generation (LOADng). >>>>=20 >>>> I think it is the responsibility of authors to choose the title of the= ir document, but LLN references should definitely move away, and not only i= n the title, as it is a MANET protocol. >>>>=20 >>>>> So far the specification has included RFC5444 and AODV techniques >>>>> which is excellent, just needs more editting to include MANET >>>>> scenarios. >>>>=20 >>>> or exclude LLN-specific scenarios... >>>>=20 >>>=20 >>> That would be very intellectually dishonest, >>=20 >> JP> Let's not make any personal statement. >=20 > My comment was nothing more than a statement as to what the should be wri= tten in a document as to a protocol applicability. I believe that it would = be intellectually dishonest of the authors (or WG) of a document to deliber= ately exclude or distort known facts of the applicability of a protocol. I'= d assume that any IETFer would agree with this by default. And my point was that if a new protocol is aimed at being standardized at t= he IETF for an applicability in a domain X, it may be wise to then run it b= y the WG in charge of working on the said domain. I'd also assume that any = IETFer would agree with this too. Best Regards. JP. >=20 >=20 > Thomas >=20 >=20 >>> considering that LOADng is widely deployed on what you call "LLN-specif= ic scenarios" (although I adhere to what Adrian said: that LLNs are a subse= t of MANETs) >>=20 >> JP> Then document the scenarios, and run them by the ROLL WG, since LLNs= routing is being discussed in the ROLL WG, as decided by the IESG. >>=20 >> Thanks. >>=20 >> Best Regards. >>=20 >> JP. >>=20 >>>=20 >>> Thomas >>>=20 >>>> C=E9dric. >>>>=20 >>>>>=20 >>>>> AB >>>>>=20 >>>>>>=20 >>>>>> C=E9dric. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From ietf@thomasclausen.org Mon Oct 15 07:44:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDBB1F0C54 for ; Mon, 15 Oct 2012 07:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY-5IpuUjuSH for ; Mon, 15 Oct 2012 07:44:30 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C277E1F0429 for ; Mon, 15 Oct 2012 07:44:30 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id AE05EA3882 for ; Mon, 15 Oct 2012 07:44:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 733781BD1BD7; Mon, 15 Oct 2012 07:44:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.3] (221x249x212x15.ap221.ftth.ucom.ne.jp [221.249.212.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C80FB1BD1BA5; Mon, 15 Oct 2012 07:44:25 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Heide Clausen In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> Date: Mon, 15 Oct 2012 16:44:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3 665@watteco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> To: "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1498) Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:44:32 -0000 On Oct 15, 2012, at 16:40 , "JP Vasseur (jvasseur)" = wrote: >=20 > On Oct 15, 2012, at 4:31 PM, Thomas Heide Clausen wrote: >=20 >>=20 >> On Oct 15, 2012, at 16:24 , "JP Vasseur (jvasseur)" = wrote: >>=20 >>>=20 >>> On Oct 15, 2012, at 3:25 PM, Thomas Heide Clausen wrote: >>>=20 >>>>=20 >>>> On 15 oct. 2012, at 19:38, C Chauvenet = wrote: >>>>=20 >>>>> Hi AB,=20 >>>>>=20 >>>>> Le 15 oct. 2012 =E0 12:19, Abdussalam Baryun a =E9crit : >>>>>=20 >>>>>> Hi Cedric, >>>>>>=20 >>>>>>> Overall, I think the discussion need the new version of LOADng = to move on. >>>>>>> As IETF is coming fast, I guess that it will released in the = coming days ? >>>>>>> Once released, we could see how its relates to the MANET charter = and scope, >>>>>>> and do not conflict with RFC6550, the routing protocol for LLNs = designed by >>>>>>> the IETF. >>>>>>=20 >>>>>> LOADng if to be adopted by MANET, I recommend the change of the = name >>>>>> and specification. It should not be *LLN On demand Ad hoc = Distance >>>>>> vector next generation*, I suggest to be : Lossy MANET On demand = Ad >>>>>> hoc Distance-vector next generation (LOADng). >>>>>=20 >>>>> I think it is the responsibility of authors to choose the title of = their document, but LLN references should definitely move away, and not = only in the title, as it is a MANET protocol. >>>>>=20 >>>>>> So far the specification has included RFC5444 and AODV techniques >>>>>> which is excellent, just needs more editting to include MANET >>>>>> scenarios. >>>>>=20 >>>>> or exclude LLN-specific scenarios... >>>>>=20 >>>>=20 >>>> That would be very intellectually dishonest, >>>=20 >>> JP> Let's not make any personal statement. >>=20 >> My comment was nothing more than a statement as to what the should be = written in a document as to a protocol applicability. I believe that it = would be intellectually dishonest of the authors (or WG) of a document = to deliberately exclude or distort known facts of the applicability of a = protocol. I'd assume that any IETFer would agree with this by default. >=20 > And my point was that if a new protocol is aimed at being standardized = at the IETF for an applicability in a domain X, it may be wise to then = run it by the WG in charge of working on the said domain. I'd also = assume that any IETFer would agree with this too. Yep. LOADng is intended for the MANET domain, and is discussed here. It = also, but not exclusively, is applicable to the special case of a MANET = that some call an LLN. So, I'd suggest that we're in agreement? Thomas > Best Regards. >=20 > JP. >=20 >>=20 >>=20 >> Thomas >>=20 >>=20 >>>> considering that LOADng is widely deployed on what you call = "LLN-specific scenarios" (although I adhere to what Adrian said: that = LLNs are a subset of MANETs) >>>=20 >>> JP> Then document the scenarios, and run them by the ROLL WG, since = LLNs routing is being discussed in the ROLL WG, as decided by the IESG. >>>=20 >>> Thanks. >>>=20 >>> Best Regards. >>>=20 >>> JP. >>>=20 >>>>=20 >>>> Thomas >>>>=20 >>>>> C=E9dric. >>>>>=20 >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>>>=20 >>>>>>> C=E9dric. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From ulrich@herberg.name Mon Oct 15 08:22:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2A621F87A3 for ; Mon, 15 Oct 2012 08:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axOQfetZ-RF2 for ; Mon, 15 Oct 2012 08:22:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB06121F87A2 for ; Mon, 15 Oct 2012 08:22:45 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6565036vcb.31 for ; Mon, 15 Oct 2012 08:22:45 -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=N9I9r0o3XqvAc0YlOTxIkbbT6KjYgWyM3uUfKbvRc1c=; b=oOEVIf2b/H+guUB03b9oydTWlaALbUYe2FI+ZLakC6hQKfEEN4wT2Xxunc9nAwmVYM C9G5xLAywL8BvQacusj+eJyKcHHSrCwR/gO3dGqCavnREgnZ+QFprtuWAyMz28tTN0dU AAMe48hDEAdk4ZBy6P6cu97RB1pi22UxEUPnQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=N9I9r0o3XqvAc0YlOTxIkbbT6KjYgWyM3uUfKbvRc1c=; b=U31E/fwvkDDwXI6gy/8r6lCrG3kShEdcDyPEM6P9hn8SuYKGI+NmIjbKTNX/56qqBy +s97jb1sXu7/tbaROvoBZKdoI0Q0qc+63sbzXOQQzw3DOI3oklXR9I/y+huPRIRwiURX zcILga38UCuzGI5ixcsTtmP8Ya6XFyjOt2fkefim2WxNhHsH3LA+ImAmj+mgdPWY44Wq N4+veIt5mt2WBPe47K8J5plvHZS6Vx/NvJLW7cDB1t5qJdmrO4zqJdk/TcVT2F1ALKwx 4TpfJKk2NmdpD4uItSCfJbC187Sb+vZGba7W7sBexQ4aJzsA9gjwWk8mr6Mn3YOb0kA/ 9vlA== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr5714348vdv.20.1350314565039; Mon, 15 Oct 2012 08:22:45 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Mon, 15 Oct 2012 08:22:44 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> Date: Mon, 15 Oct 2012 08:22:44 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=bcaec50162bdfbf4c304cc1a9b87 X-Gm-Message-State: ALoCoQlPigweIuQLGwqs1DBevRKRsCZXgOQhXNErKpZaael+370ygBaOCPu9Vm/yeG/TcMfTEOnS Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:22:47 -0000 --bcaec50162bdfbf4c304cc1a9b87 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) wrote: > [...] > > > JP> Here we do not disagree at all. I am not saying that reactive > protocols are not appropriate in a number of scenario. All I am saying is > that *if* you intent to specify > a reactive routing protocol for LLNs, knowing the years of intense work > and efforts of the ROLL WG, then it should be discussed with a wider > audience. > I agree. But that's not we are intending to do. We intent to produce a reactive protocol for MANETs, which is requested by the MANET charter. LOADng is a protocol that covers all the use cases of MANETs, one of which being LLNs. And yes, the introduction and title of the draft needs to be changed > On the other > hand, if your explicitly exclude LLNs from your protocol in your protocol, > it is no longer required to involve the ROLL WG. The objective is simply to > avoid WG charter > overlap but more importantly try to benefit from the benefit of experts in > the area of LLNs to build a good protocol for the Internet. > I am personally against removing to mention a use case where as a matter of fact the protocol is used in (as *one* use-case out of many). Citing Adrian from the last MANET meeting: Adrian Farrell: If you were to pick up a reactive protocol for MANET, you would be in charter. If you pick up a protocol and your main use case is for LLNs, you have diverged from charter. Main use case is delicate thing to talk about. It is clear that some if not all LLNs are MANET. Not all MANETs are LLNs. So you need to be producing a single reactive protocol for MANETs, not for *some* MANETs. You need to be clear that the protocol you work on is applicable across all MANETs. If that picks up some LLNs across the way, no big deal, but it should not be main use case. Look at all use cases for MANETs and make sure you address all of those. This is exactly what we intend to do. > It was also agreed at the last MANET meeting that if LOADng was to be > considered for MANET, it needs to de-emphasize LLNs (which I have not heard > anybody disagree with so far). So I don't understand what we are even > discussing here. > > > JP> No, this your recollection of the discussion. "less-focussed" or > "de-emphasize" was I think your interpretation. Mine was "not referring to > LLNs" at all. > I sincerely suggest to wait until you read the new revision, as this discussion is hypothetical without that. > Otherwise, it should be reviewed by both WGs (to be discussed between > chairs and AD). > Best Ulrich --bcaec50162bdfbf4c304cc1a9b87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,


On Sun, Oct 14, 2012 at 11:28= PM, JP Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
[...]

JP> Here we do not disagree at all. I am not saying that reac= tive protocols are not appropriate in a number of scenario. All I am saying= is that *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of intense wor= k and efforts of the ROLL WG, then it should be discussed with a wider audi= ence.


I agree. But that's not we are intending to do. We intent to produ= ce a reactive protocol for MANETs, which is requested by the MANET charter.= LOADng is a protocol that covers all the use cases of MANETs, one of which= being LLNs.
And yes, the introduction and title of the draft needs to be changed


=A0
On the other
hand, if your explicitly exclude LLNs from your protocol in your proto= col, it is no longer required to involve the ROLL WG. The objective is simp= ly to avoid WG charter
overlap but more importantly try to benefit from the benefit of expert= s in the area of LLNs to build a good protocol for the Internet.

I am personally against remov= ing to mention a use case where as a matter of fact the protocol is used in= (as *one* use-case out of many).

Citing Adrian from the last MANET meeting:
Adrian Farrell: If y= ou were to pick up a reactive protocol for MANET, you would be in charter. = If you pick up a protocol and your main use case is for LLNs, you have dive= rged from charter. Main use case is delicate thing to talk about. It is cle= ar that some if not all LLNs are MANET. Not all MANETs are LLNs. So you nee= d to be producing a single reactive protocol for MANETs, not for *some* MAN= ETs. You need to be clear that the protocol you work on is applicable acros= s all MANETs. If that picks up some LLNs across the way, no big deal, but i= t should not be main use case. Look at all use cases for MANETs and make su= re you address all of those.

This is exactly what we intend to do.
<= br>


It was also agreed at the last MANET meeting that if LOADng was to be = considered for MANET, it needs to de-emphasize LLNs (which I have not heard= anybody disagree with so far). So I don't understand what we are even = discussing here.=A0

JP> No, this your recollection of the discussion. "less-= focussed" or "de-emphasize" was I think your interpretation.= Mine was "not referring to LLNs" at all.=A0


I sincerely suggest t= o wait until you read the new revision, as this discussion is hypothetical = without that.=A0

=A0
Otherwise, it should be reviewed by both WGs (to be discussed between = chairs and AD).

Bes= t
Ulrich=A0
--bcaec50162bdfbf4c304cc1a9b87-- From ulrich@herberg.name Mon Oct 15 08:33:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C1621F84D6 for ; Mon, 15 Oct 2012 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YHktX2Ha968 for ; Mon, 15 Oct 2012 08:33:50 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B33E21F843E for ; Mon, 15 Oct 2012 08:33:50 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6580682vcb.31 for ; Mon, 15 Oct 2012 08:33:49 -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=DvoZdT8C5GqDzThVBpaXoPNmtGaSsFKZx55hAlEkjrM=; b=m6aIZzCQc2U/mJmKhfUDJxVVox5tnyaMAtYtl1k/1BVyfuEcCHkk3nClZ0T6Nqa/Ht o24z+v37fvDASxRkzydG6Uyfw+mn8ugcgRD7PjkUPAKcZ0cIu0jCYPYyhWSGnZcxfKfl HKLsoCrGNwd2PCg5B+pwkxRD/x6KoHm8072Mw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DvoZdT8C5GqDzThVBpaXoPNmtGaSsFKZx55hAlEkjrM=; b=dDPxyxPXRD3W+yhayeuISvkxTSgCYR3g/8XZ/3PhVefQRI0tU/e4pLFYTPlnwsgN4X YPKf1Bm9kVLSuyLzlbwhIKhKQ6dFTP1UqmpxyIs+g4abVtcGjEILo44HKzNdR3SpFjDe 6TZBRZLWM07qe7vcZrOOWZCNxvoyMU1bjTNvEXhDncbc0R/nf4sOaZu3HbXGuinXfJoH pGc74P16Cpu7vD2hfPaTkCHihFZzirHDd5frT0NA+RWMrQjTR0BS3YcpaeLrDmbnudK9 xvMgH3m1oytVlkB2e9l/JodcAttJHqfjcraQP46sMfMyJJGVHL0ug+zdL+FVjg/LCS9J AQbQ== MIME-Version: 1.0 Received: by 10.58.23.100 with SMTP id l4mr7047055vef.46.1350315229453; Mon, 15 Oct 2012 08:33:49 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Mon, 15 Oct 2012 08:33:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Oct 2012 08:33:49 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b339d9d961f4404cc1ac3a8 X-Gm-Message-State: ALoCoQkinQxlB0Zd7Gisowm0tzCM75iStoQu+7Vd+PhjZtw1Uoot/wD30ZuzRsz4Oa24rPTOQyPR Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:33:51 -0000 --047d7b339d9d961f4404cc1ac3a8 Content-Type: text/plain; charset=ISO-8859-1 Hi AB, On Mon, Oct 15, 2012 at 1:55 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > [...] > > If you read the minutes of MANET WG meeting IETF84 [1] you will find > there was a discussion, my input was only a reflection. Please note > that refering to I-D [2] was in the minutes which I agree that we > SHOULD delete from our MANET minutes because it is another *overalp* > (I don't beleive that the I-D name was pronounced in the meeting but > the minute writter prefered to advertise the name). > > I RECOMMEND the Chair of MANET to delete the name of RPL experience > I-D from the minutes because it is/was note said just indicated such > as draft not named. > I strongly disagree. I have listened to the audio again. Thomas Clausen clearly named the moniker of the draft. The minutes are supposed to reflect what has been said in the meeting. [...] Best Ulrich --047d7b339d9d961f4404cc1ac3a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi AB,

On Mon, Oct 15, 2012 at 1:55 AM, A= bdussalam Baryun <abdussalambaryun@gmail.com> wrote= :
[...]

=A0If you read the minutes of MANET WG meeting IETF84 [1] you will find
there was a discussion, my input was only a reflection. Please note
that refering to I-D [2] was in the minutes which I agree that we
SHOULD delete from our MANET minutes because it is another *overalp*
(I don't beleive that the I-D name was pronounced in the meeting but the minute writter prefered to advertise the name).

I RECOMMEND the Chair of MANET to delete the name of RPL experience
I-D from the minutes because it is/was note said just indicated such
as draft not named.


I st= rongly disagree. I have listened to the audio again. Thomas Clausen clearly= named the moniker of the draft. The minutes are supposed to reflect what h= as been said in the meeting.


[...]

Best
Ulrich
--047d7b339d9d961f4404cc1ac3a8-- From jvasseur@cisco.com Mon Oct 15 08:54:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2BD1F0C4A for ; Mon, 15 Oct 2012 08:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw2pyowQs4Jb for ; Mon, 15 Oct 2012 08:54:22 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 29FDE1F0C44 for ; Mon, 15 Oct 2012 08:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4253; q=dns/txt; s=iport; t=1350316462; x=1351526062; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QSljB4eSHn0KhHlChVqN4sUhsajtu2dAJBBgyl1vw2k=; b=SgFRuGMoRy7s1i7ZoOZcTqawMLIDciCe17ovnzQYbyj7nsHAGvIoH7mw pg56ziCG9XKWqDb8xPp+xlaD1UTeNCFYL78nhOrgJKHbxnXiSgKm9QgYt EFEjxIRCRyAQ3On7oK+Aypi+QAm7sF6u0fjinoDM0nQZxQkGzjEDOYpl2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANYwfFCtJXG+/2dsb2JhbABFv3aBCIIgAQEBAwEBAQEPAVsLEAIBCBgKJCcLJQIEDgUIGodcBgueAJ9vBItZhV1gA6QxgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="131728970" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2012 15:54:21 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9FFsLIm003188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 15:54:21 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 10:54:21 -0500 From: "JP Vasseur (jvasseur)" To: Thomas Heide Clausen Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Mon, 15 Oct 2012 15:54:20 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE35C9@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <208DA393-C499-4538-8FA4-7D04255B3 665@watteco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--47.023600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <4622BCAED6DDBB40AA784C4C7FECC3DA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:54:23 -0000 On Oct 15, 2012, at 4:44 PM, Thomas Heide Clausen wrote: >=20 > On Oct 15, 2012, at 16:40 , "JP Vasseur (jvasseur)" = wrote: >=20 >>=20 >> On Oct 15, 2012, at 4:31 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>> On Oct 15, 2012, at 16:24 , "JP Vasseur (jvasseur)" wrote: >>>=20 >>>>=20 >>>> On Oct 15, 2012, at 3:25 PM, Thomas Heide Clausen wrote: >>>>=20 >>>>>=20 >>>>> On 15 oct. 2012, at 19:38, C Chauvenet wrot= e: >>>>>=20 >>>>>> Hi AB,=20 >>>>>>=20 >>>>>> Le 15 oct. 2012 =E0 12:19, Abdussalam Baryun a =E9crit : >>>>>>=20 >>>>>>> Hi Cedric, >>>>>>>=20 >>>>>>>> Overall, I think the discussion need the new version of LOADng to = move on. >>>>>>>> As IETF is coming fast, I guess that it will released in the comin= g days ? >>>>>>>> Once released, we could see how its relates to the MANET charter a= nd scope, >>>>>>>> and do not conflict with RFC6550, the routing protocol for LLNs de= signed by >>>>>>>> the IETF. >>>>>>>=20 >>>>>>> LOADng if to be adopted by MANET, I recommend the change of the na= me >>>>>>> and specification. It should not be *LLN On demand Ad hoc Distance >>>>>>> vector next generation*, I suggest to be : Lossy MANET On demand Ad >>>>>>> hoc Distance-vector next generation (LOADng). >>>>>>=20 >>>>>> I think it is the responsibility of authors to choose the title of t= heir document, but LLN references should definitely move away, and not only= in the title, as it is a MANET protocol. >>>>>>=20 >>>>>>> So far the specification has included RFC5444 and AODV techniques >>>>>>> which is excellent, just needs more editting to include MANET >>>>>>> scenarios. >>>>>>=20 >>>>>> or exclude LLN-specific scenarios... >>>>>>=20 >>>>>=20 >>>>> That would be very intellectually dishonest, >>>>=20 >>>> JP> Let's not make any personal statement. >>>=20 >>> My comment was nothing more than a statement as to what the should be w= ritten in a document as to a protocol applicability. I believe that it woul= d be intellectually dishonest of the authors (or WG) of a document to delib= erately exclude or distort known facts of the applicability of a protocol. = I'd assume that any IETFer would agree with this by default. >>=20 >> And my point was that if a new protocol is aimed at being standardized a= t the IETF for an applicability in a domain X, it may be wise to then run i= t by the WG in charge of working on the said domain. I'd also assume that a= ny IETFer would agree with this too. >=20 > Yep. LOADng is intended for the MANET domain, and is discussed here. It a= lso, but not exclusively, is applicable to the special case of a MANET that= some call an LLN. >=20 > So, I'd suggest that we're in agreement? JP> I do not think so =85 All I am saying is that *if* you design a protoco= l for LLNs or a superset including LLNs, then at the very least it should b= e discussed in the WG formed at the IETF for Routing in LLNs: ROLL. Remember that the I= ETF has formed a WG for that purpose. If you exclude LLNs from the routing protocol applicability, I guess that i= t addresses a MANET charter work item indeed. Thanks. JP. >=20 > Thomas >=20 >=20 >> Best Regards. >>=20 >> JP. >>=20 >>>=20 >>>=20 >>> Thomas >>>=20 >>>=20 >>>>> considering that LOADng is widely deployed on what you call "LLN-spec= ific scenarios" (although I adhere to what Adrian said: that LLNs are a sub= set of MANETs) >>>>=20 >>>> JP> Then document the scenarios, and run them by the ROLL WG, since LL= Ns routing is being discussed in the ROLL WG, as decided by the IESG. >>>>=20 >>>> Thanks. >>>>=20 >>>> Best Regards. >>>>=20 >>>> JP. >>>>=20 >>>>>=20 >>>>> Thomas >>>>>=20 >>>>>> C=E9dric. >>>>>>=20 >>>>>>>=20 >>>>>>> AB >>>>>>>=20 >>>>>>>>=20 >>>>>>>> C=E9dric. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>=20 >=20 From jvasseur@cisco.com Mon Oct 15 08:57:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA69D11E80D7 for ; Mon, 15 Oct 2012 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3wmHI-SAjke for ; Mon, 15 Oct 2012 08:57:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AC2DA1F0C5F for ; Mon, 15 Oct 2012 08:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9395; q=dns/txt; s=iport; t=1350316641; x=1351526241; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IofPwNYeXGDADnuNF1PIrE4p5plP2oAbOcG9TyvvvRs=; b=PQe2VA7+qEhH1fNV2KdRFulr5BpLnMxWqH8J/qv+EJ4UEvSQJlbynf53 wcazY8oAyNtiPpsbXpWPXeo9Bud9n79T0ntZkmzTo6DpWejc34PS+4o9i /WTrbAzrlkXBYjSTGr69P1R4NjEu7osUqkIe523yPGuRmjn8fB85M5qk2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFAxfFCtJXG//2dsb2JhbABFv3aBCIIhAQEEEgFYCAYQAgEIIh0HMhQRAgQOBQgah2KeDZ9zi1mFXWADpDGBa4JtgWM0 X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208,217";a="131759332" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 15 Oct 2012 15:57:21 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9FFvL5e014115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 15:57:21 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 10:57:20 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Mon, 15 Oct 2012 15:57:20 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--49.324500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FE361Axmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:57:22 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FE361Axmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 15, 2012, at 5:22 PM, Ulrich Herberg wrote: Hi JP, On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) > wrote: [...] JP> Here we do not disagree at all. I am not saying that reactive protocols= are not appropriate in a number of scenario. All I am saying is that *if* = you intent to specify a reactive routing protocol for LLNs, knowing the years of intense work and= efforts of the ROLL WG, then it should be discussed with a wider audience. I agree. But that's not we are intending to do. We intent to produce a reac= tive protocol for MANETs, which is requested by the MANET charter. LOADng i= s a protocol that covers all the use cases of MANETs, one of which being LL= Ns. JP> See previous email =85. then it should be run by the WG in charge of ro= uting protocol in LLN, that excluded the use of reactive routing after years of work. And yes, the introduction and title of the draft needs to be changed JP> No issue with this. On the other hand, if your explicitly exclude LLNs from your protocol in your protocol, = it is no longer required to involve the ROLL WG. The objective is simply to= avoid WG charter overlap but more importantly try to benefit from the benefit of experts in = the area of LLNs to build a good protocol for the Internet. I am personally against removing to mention a use case where as a matter of= fact the protocol is used in (as *one* use-case out of many). Citing Adrian from the last MANET meeting: Adrian Farrell: If you were to pick up a reactive protocol for MANET, you w= ould be in charter. If you pick up a protocol and your main use case is for= LLNs, you have diverged from charter. Main use case is delicate thing to t= alk about. It is clear that some if not all LLNs are MANET. Not all MANETs = are LLNs. So you need to be producing a single reactive protocol for MANETs= , not for *some* MANETs. You need to be clear that the protocol you work on= is applicable across all MANETs. If that picks up some LLNs across the way= , no big deal, but it should not be main use case. Look at all use cases fo= r MANETs and make sure you address all of those. This is exactly what we intend to do. JP> I cannot speak for our AD. As a WG co-chair, the minimum would be to ma= ke sure that the ROLL WG reviews the work in great details. It was also agreed at the last MANET meeting that if LOADng was to be consi= dered for MANET, it needs to de-emphasize LLNs (which I have not heard anyb= ody disagree with so far). So I don't understand what we are even discussin= g here. JP> No, this your recollection of the discussion. "less-focussed" or "de-em= phasize" was I think your interpretation. Mine was "not referring to LLNs" = at all. I sincerely suggest to wait until you read the new revision, as this discus= sion is hypothetical without that. JP> Sure, when can we expect to see it ? Thanks. JP. Otherwise, it should be reviewed by both WGs (to be discussed between chair= s and AD). Best Ulrich --_000_03B78081B371D44390ED6E7BADBB4A7721FE361Axmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <10B2B6C64DEA434D9B4F45D1DCDA5A34@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 15, 2012, at 5:22 PM, Ulrich Herberg wrote:

Hi JP,


On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jv= asseur) <jvasseur@cisco.= com> wrote:
[...]

JP> Here we do not disagree at all. I am not saying that reactive p= rotocols are not appropriate in a number of scenario. All I am saying is th= at *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of intense wor= k and efforts of the ROLL WG, then it should be discussed with a wider audi= ence.


I agree. But that's not we are intending to do. We intent to produce a= reactive protocol for MANETs, which is requested by the MANET charter. LOA= Dng is a protocol that covers all the use cases of MANETs, one of which bei= ng LLNs.

JP> See previous email =85. then it should be run by the WG in char= ge of routing protocol in LLN, that excluded the use of reactive routing&nb= sp;
after years of work.

And yes, the introduction and title of the draft needs to be changed

JP> No issue with this.



 
On the other
hand, if your explicitly exclude LLNs from your protocol in your proto= col, it is no longer required to involve the ROLL WG. The objective is simp= ly to avoid WG charter
overlap but more importantly try to benefit from the benefit of expert= s in the area of LLNs to build a good protocol for the Internet.

I am personally against removing to mention a use case where as a matt= er of fact the protocol is used in (as *one* use-case out of many).

Citing Adrian from the last MANET meeting:
Adrian Farrell: If=
 you were to pick up a reactive protocol for MANET, you would be in charter=
. If you pick up a protocol and your main use case is for LLNs, you have di=
verged from charter. Main use case is delicate thing to talk about. It is c=
lear that some if not all LLNs are MANET. Not all MANETs are LLNs. So you n=
eed to be producing a single reactive protocol for MANETs, not for *some* M=
ANETs. You need to be clear that the protocol you work on is applicable acr=
oss all MANETs. If that picks up some LLNs across the way, no big deal, but=
 it should not be main use case. Look at all use cases for MANETs and make =
sure you address all of those.

This is exactly what we intend to do.

JP> I cannot speak for our AD. As a WG co-chair, the minimum would = be to make sure that the ROLL WG reviews the work in great details.




It was also agreed at the last MANET meeting that if LOADng was to be = considered for MANET, it needs to de-emphasize LLNs (which I have not heard= anybody disagree with so far). So I don't understand what we are even disc= ussing here. 

JP> No, this your recollection of the discussion. "less-focuss= ed" or "de-emphasize" was I think your interpretation. Mine = was "not referring to LLNs" at all. 


I sincerely suggest to wait until you read the new revision, as this d= iscussion is hypothetical without that. 

JP> Sure, when can we expect to see it ?

Thanks.

JP.


 
Otherwise, it should be reviewed by both WGs (to be discussed between = chairs and AD).

Best
Ulrich 

--_000_03B78081B371D44390ED6E7BADBB4A7721FE361Axmbrcdx02ciscoc_-- From c.chauvenet@watteco.com Mon Oct 15 09:00:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0851F0C7E for ; Mon, 15 Oct 2012 09:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrlZv73K4hsr for ; Mon, 15 Oct 2012 09:00:52 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 707051F0C6E for ; Mon, 15 Oct 2012 09:00:52 -0700 (PDT) Received: from mail159-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Oct 2012 16:00:50 +0000 Received: from mail159-va3 (localhost [127.0.0.1]) by mail159-va3-R.bigfish.com (Postfix) with ESMTP id C2C081C0159; Mon, 15 Oct 2012 16:00:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.53; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz98dI9371Ic89bhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail159-va3 (localhost.localdomain [127.0.0.1]) by mail159-va3 (MessageSwitch) id 1350316848214751_32524; Mon, 15 Oct 2012 16:00:48 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.247]) by mail159-va3.bigfish.com (Postfix) with ESMTP id 24B714200AE; Mon, 15 Oct 2012 16:00:48 +0000 (UTC) Received: from AMSPRD0510HT004.eurprd05.prod.outlook.com (157.56.248.53) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Oct 2012 16:00:45 +0000 Received: from AMSPRD0510MB385.eurprd05.prod.outlook.com ([169.254.12.26]) by AMSPRD0510HT004.eurprd05.prod.outlook.com ([10.255.42.39]) with mapi id 14.16.0207.009; Mon, 15 Oct 2012 16:00:38 +0000 From: C Chauvenet To: Ulrich Herberg , Thomas Heide Clausen Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAIAAdJeAgABi3ICAAIeagIAAER6AgACSLwCAAFx+AIAAlVYAgAAKlAA= Date: Mon, 15 Oct 2012 16:00:37 +0000 Message-ID: <50A05995-EE7B-44DA-B157-B83D62FE2E6C@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_50A05995EE7B44DAB157B83D62FE2E6Cwattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Stan Ratliff \(sratliff\)" , "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 16:00:53 -0000 --_000_50A05995EE7B44DAB157B83D62FE2E6Cwattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ulrich and Thomas Le 15 oct. 2012 =E0 17:22, Ulrich Herberg a =E9crit : Hi JP, On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) > wrote: [...] JP> Here we do not disagree at all. I am not saying that reactive protocols= are not appropriate in a number of scenario. All I am saying is that *if* = you intent to specify a reactive routing protocol for LLNs, knowing the years of intense work and= efforts of the ROLL WG, then it should be discussed with a wider audience. I agree. But that's not we are intending to do. We intent to produce a reac= tive protocol for MANETs, which is requested by the MANET charter. LOADng i= s a protocol that covers all the use cases of MANETs, one of which being LL= Ns. And yes, the introduction and title of the draft needs to be changed On the other hand, if your explicitly exclude LLNs from your protocol in your protocol, = it is no longer required to involve the ROLL WG. The objective is simply to= avoid WG charter overlap but more importantly try to benefit from the benefit of experts in = the area of LLNs to build a good protocol for the Internet. I am personally against removing to mention a use case where as a matter of= fact the protocol is used in (as *one* use-case out of many). Citing Adrian from the last MANET meeting: Adrian Farrell: If you were to pick up a reactive protocol for MANET, you w= ould be in charter. If you pick up a protocol and your main use case is for= LLNs, you have diverged from charter. Main use case is delicate thing to t= alk about. It is clear that some if not all LLNs are MANET. Not all MANETs = are LLNs. So you need to be producing a single reactive protocol for MANETs= , not for *some* MANETs. You need to be clear that the protocol you work on= is applicable across all MANETs. If that picks up some LLNs across the way= , no big deal, but it should not be main use case. Look at all use cases fo= r MANETs and make sure you address all of those. You'll not the "If that picks up some LLNs across the way, no big deal, but= it should not be main use case". That is why I asked in a previous mail the nature of LOADng deployments you= were talking about. I cannot find any material on this. If they are LLN, then it seems in disagreement with what Adrian suggest. This is exactly what we intend to do. It was also agreed at the last MANET meeting that if LOADng was to be consi= dered for MANET, it needs to de-emphasize LLNs (which I have not heard anyb= ody disagree with so far). So I don't understand what we are even discussin= g here. JP> No, this your recollection of the discussion. "less-focussed" or "de-em= phasize" was I think your interpretation. Mine was "not referring to LLNs" = at all. I sincerely suggest to wait until you read the new revision, as this discus= sion is hypothetical without that. Agree that the new version should be a good point of discussion. Best, C=E9dric. Otherwise, it should be reviewed by both WGs (to be discussed between chair= s and AD). Best Ulrich --_000_50A05995EE7B44DAB157B83D62FE2E6Cwattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3895214D83DCFB4DAA10877D6714E4F3@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi ulrich and Thomas

Le 15 oct. 2012 =E0 17:22, Ulrich Herberg a =E9crit :

Hi JP,


On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jv= asseur) <jvasseur@cisco.= com> wrote:
[...]

JP> Here we do not disagree at all. I am not saying that reactive p= rotocols are not appropriate in a number of scenario. All I am saying is th= at *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of intense wor= k and efforts of the ROLL WG, then it should be discussed with a wider audi= ence.


I agree. But that's not we are intending to do. We intent to produce a= reactive protocol for MANETs, which is requested by the MANET charter. LOA= Dng is a protocol that covers all the use cases of MANETs, one of which bei= ng LLNs.
And yes, the introduction and title of the draft needs to be changed


 
On the other
hand, if your explicitly exclude LLNs from your protocol in your proto= col, it is no longer required to involve the ROLL WG. The objective is simp= ly to avoid WG charter
overlap but more importantly try to benefit from the benefit of expert= s in the area of LLNs to build a good protocol for the Internet.

I am personally against removing to mention a use case where as a matt= er of fact the protocol is used in (as *one* use-case out of many).

Citing Adrian from the last MANET meeting:
Adrian Farrell: If=
 you were to pick up a reactive protocol for MANET, you would be in charter=
. If you pick up a protocol and your main use case is for LLNs, you have di=
verged from charter. Main use case is delicate thing to talk about. It is c=
lear that some if not all LLNs are MANET. Not all MANETs are LLNs. So you n=
eed to be producing a single reactive protocol for MANETs, not for *some* M=
ANETs. You need to be clear that the protocol you work on is applicable acr=
oss all MANETs. If that picks up some LLNs across the way, no big deal, but=
 it should not be main use case. Look at all use cases for MANETs and make =
sure you address all of those.

You'll not the "If that picks up some LLNs across= the way, no big deal, but it should not be main use case".

That is why I asked in a previous mail the nature of LOADng deployment= s you were talking about.
I cannot find any material on this.
If they are LLN, then it seems in disagreement with what Adrian sugges= t.


This is exactly what we intend to do.



It was also agreed at the last MANET meeting that if LOADng was to be = considered for MANET, it needs to de-emphasize LLNs (which I have not heard= anybody disagree with so far). So I don't understand what we are even disc= ussing here. 

JP> No, this your recollection of the discussion. "less-focuss= ed" or "de-emphasize" was I think your interpretation. Mine = was "not referring to LLNs" at all. 


I sincerely suggest to wait until you read the new revision, as this d= iscussion is hypothetical without that. 

Agree that the new version should be a good point of discussion.

Best,

C=E9dric.


 
Otherwise, it should be reviewed by both WGs (to be discussed between = chairs and AD).

Best
Ulrich 

--_000_50A05995EE7B44DAB157B83D62FE2E6Cwattecocom_-- From abdussalambaryun@gmail.com Mon Oct 15 10:53:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221A621F869E for ; Mon, 15 Oct 2012 10:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+LOxsbs95bh for ; Mon, 15 Oct 2012 10:53:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A031C21F870F for ; Mon, 15 Oct 2012 10:53:36 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6210552vbb.31 for ; Mon, 15 Oct 2012 10:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PLT9kOVcqlmiOACaxQ+UCIl4bn2YtiUu/+wwxqafw8w=; b=jVYY/7qivN/V/vPLv/x1kZTil4IfgBJ0TbooPN4p1tQUe3fUGavCHXABjUAecAmiyv DRrCTaqU7HJMvNKvP/4ORKBXEa9jC1t6pUhWiUf0CwvD3T6A4zE9AS52/AYwln8m93qU ACzC5mBzFCjl+povanzJZYerqpNBZZFHxLgRZU5vcgim1RugX/Gjzez198tt7e3BEq+h +DPcNaPqvSPM3R/UorrQdehNfeERLd5rrFpAfs1xHsn8fQbcDSX0Br2AVnErNOjG/elh MbQWvUZ4oAA95xlKvz70l/jqsgZmV0ZnBw6NswnHJ035toYaTG+hVPkeWnUXkGQ31aq5 WD6Q== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr5932720vdi.55.1350323615643; Mon, 15 Oct 2012 10:53:35 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 15 Oct 2012 10:53:33 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> Date: Mon, 15 Oct 2012 18:53:33 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf3079bc7071364e04cc1cb735 Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 17:53:39 -0000 --20cf3079bc7071364e04cc1cb735 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ulrich, MANET WG is working on AODVv2 (DYMO born 2005), we already discussed this on the list. There is MANET WG consensus on the AODVv2 for many years, so it should go forward to submission without noise from another reactive-draft that was born in 2011. Do you mean there was an agreement that we leave AODVv2 and replace to LOADng, if so please advise, (this maybe agreed out of the meetings and the list which is not authorised yet). AB On Mon, Oct 15, 2012 at 4:22 PM, Ulrich Herberg wrote= : > Hi JP, > > > On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) < > jvasseur@cisco.com> wrote: > >> [...] >> >> >> JP> Here we do not disagree at all. I am not saying that reactive >> protocols are not appropriate in a number of scenario. All I am saying i= s >> that *if* you intent to specify >> a reactive routing protocol for LLNs, knowing the years of intense work >> and efforts of the ROLL WG, then it should be discussed with a wider >> audience. >> > > > I agree. But that's not we are intending to do. We intent to produce a > reactive protocol for MANETs, which is requested by the MANET charter. > LOADng is a protocol that covers all the use cases of MANETs, one of whic= h > being LLNs. > And yes, the introduction and title of the draft needs to be changed > > > > >> On the other >> hand, if your explicitly exclude LLNs from your protocol in your >> protocol, it is no longer required to involve the ROLL WG. The objective= is >> simply to avoid WG charter >> overlap but more importantly try to benefit from the benefit of experts >> in the area of LLNs to build a good protocol for the Internet. >> > > I am personally against removing to mention a use case where as a matter > of fact the protocol is used in (as *one* use-case out of many). > > Citing Adrian from the last MANET meeting: > > Adrian Farrell: If you were to pick up a reactive protocol for MANET, you= would be in charter. If you pick up a protocol and your main use case is f= or LLNs, you have diverged from charter. Main use case is delicate thing to= talk about. It is clear that some if not all LLNs are MANET. Not all MANET= s are LLNs. So you need to be producing a single reactive protocol for MANE= Ts, not for *some* MANETs. You need to be clear that the protocol you work = on is applicable across all MANETs. If that picks up some LLNs across the w= ay, no big deal, but it should not be main use case. Look at all use cases = for MANETs and make sure you address all of those. > > > This is exactly what we intend to do. > > > >> It was also agreed at the last MANET meeting that if LOADng was to be >> considered for MANET, it needs to de-emphasize LLNs (which I have not he= ard >> anybody disagree with so far). So I don't understand what we are even >> discussing here. >> >> >> JP> No, this your recollection of the discussion. "less-focussed" or >> "de-emphasize" was I think your interpretation. Mine was "not referring = to >> LLNs" at all. >> > > > I sincerely suggest to wait until you read the new revision, as this > discussion is hypothetical without that. > > > >> Otherwise, it should be reviewed by both WGs (to be discussed between >> chairs and AD). >> > > Best > Ulrich > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf3079bc7071364e04cc1cb735 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,
=A0
MANET WG is working on=A0AODVv2 (DY= MO born 2005), we already discussed this on the list. There is=A0MANET WG c= onsensus on the AODVv2 for many years, so it should go forward to submissio= n without noise from another reactive-draft that was born=A0in 2011. Do you= mean there was an agreement that we leave AODVv2 and replace to LOADng, if= so please advise, (this maybe agreed out of the meetings and the list whic= h is not authorised yet).
=A0
AB

On Mon, Oct 1= 5, 2012 at 4:22 PM, Ulrich Herberg <ulrich@herberg.name> w= rote:
Hi JP,


On Sun, Oct = 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) <jvasseur@cisco.com>= wrote:
[...]


JP> Here we do not disagree at all. I am not saying that reac= tive protocols are not appropriate in a number of scenario. All I am saying= is that *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of intense wor= k and efforts of the ROLL WG, then it should be discussed with a wider audi= ence.


I agree. But that's not we are intending to do. We intent to produ= ce a reactive protocol for MANETs, which is requested by the MANET charter.= LOADng is a protocol that covers all the use cases of MANETs, one of which= being LLNs.
And yes, the introduction and title of the draft needs to be changed


=A0
On the other
hand, if your explicitly exclude LLNs from your protocol in your proto= col, it is no longer required to involve the ROLL WG. The objective is simp= ly to avoid WG charter
overlap but more importantly try to benefit from the benefit of expert= s in the area of LLNs to build a good protocol for the Internet.

I am personally against= removing to mention a use case where as a matter of fact the protocol is u= sed in (as *one* use-case out of many).

Citing Adrian from the last MANET meeting:
Adrian Farrell: If y= ou were to pick up a reactive protocol for MANET, you would be in charter. = If you pick up a protocol and your main use case is for LLNs, you have dive= rged from charter. Main use case is delicate thing to talk about. It is cle= ar that some if not all LLNs are MANET. Not all MANETs are LLNs. So you nee= d to be producing a single reactive protocol for MANETs, not for *some* MAN= ETs. You need to be clear that the protocol you work on is applicable acros= s all MANETs. If that picks up some LLNs across the way, no big deal, but i= t should not be main use case. Look at all use cases for MANETs and make su= re you address all of those.

This is exactly what we intend to do.



It was also agreed at the last MANET meeting that if LOADng was to be = considered for MANET, it needs to de-emphasize LLNs (which I have not heard= anybody disagree with so far). So I don't understand what we are even = discussing here.=A0

JP> No, this your recollection of the discussion. "less-= focussed" or "de-emphasize" was I think your interpretation.= Mine was "not referring to LLNs" at all.=A0


I sincerely sug= gest to wait until you read the new revision, as this discussion is hypothe= tical without that.=A0

=A0
=
Otherwise, it should be reviewed by both WGs (to be discussed between = chairs and AD).

Best
Ulrich=A0<= /div>

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf3079bc7071364e04cc1cb735-- From abdussalambaryun@gmail.com Mon Oct 15 10:58:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2E221F8860 for ; Mon, 15 Oct 2012 10:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huEIHP2XA1hd for ; Mon, 15 Oct 2012 10:58:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2A721F8862 for ; Mon, 15 Oct 2012 10:58:14 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6216055vbb.31 for ; Mon, 15 Oct 2012 10:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ljwkhG3xZYTqVrrNFAXj3Ni1eUneL+mbkN+04TeBCyk=; b=aXcXob5zDtgIFryvGhhay+044zRGgks1myyD5OLaCcFPIOSa7FwF4yMwBpt0+Kw61j WbwQEDa1avoJGBj+vihY7sw88OcW0tBRRrB/rENR9Ub8JH1CLAAZjuBlD6L4MFnY54M4 rpqVng47gkt7fMEi9UDYCpLxksCHflLx+1Gx494BU5LgP8mDUfllMZWsk0l2YA6bIp8U Mwy/r2xJvra1n2alaXpi8SYf5lu+6xSCfQ9WSkiL6y6ez7lW6s2CHjMV5u/3LbiFlWHp +nH+NxhFn7R7J9lFHaDfe5jHi5gx3NkkbZSWAJrXMMKnR/LvLF2fIVlE4NLc5sNEvE/D FjtQ== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr5825664vdb.125.1350323893788; Mon, 15 Oct 2012 10:58:13 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 15 Oct 2012 10:58:12 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> Date: Mon, 15 Oct 2012 18:58:12 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf307f3bcc055f9504cc1cc838 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 17:58:15 -0000 --20cf307f3bcc055f9504cc1cc838 Content-Type: text/plain; charset=ISO-8859-1 > > > Yep. LOADng is intended for the MANET domain, and is discussed here. It > also, but not exclusively, is applicable to the special case of a MANET > that some call an LLN. > I call thoes: Lossy MANET = LMANET AB > > --20cf307f3bcc055f9504cc1cc838 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Yep. LOADng is intended for the MANET domain, and is discussed = here. It also, but not exclusively, is applicable to the special case of a = MANET that some call an LLN.
=A0
I call thoe= s: Lossy MANET =3D LMANET
=A0
AB=A0

--20cf307f3bcc055f9504cc1cc838-- From ulrich@herberg.name Mon Oct 15 11:01:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D58C21F8864 for ; Mon, 15 Oct 2012 11:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGIGa6IZnItX for ; Mon, 15 Oct 2012 11:01:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B03F21F8863 for ; Mon, 15 Oct 2012 11:01:19 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6220194vbb.31 for ; Mon, 15 Oct 2012 11:01:19 -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=1upIRkJsP9RmME66FjaaU59HVlPJj8w/QylrAgQ023g=; b=psFYtPTJWTEGhYxbOaoN+teHsIMdozWRD29evgeMgx7bioLKFSY6ckbR2ZcTs/GKsV 25ajnoEQkQY7AsmaqYM4r2701OYabDQbbjNN5iqYg2KynDYZ9soGRvK/A/BTw+G0dPBe VL5vjFiEaXC0C5bNgFxXDOeIwi8vl68n82vkQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1upIRkJsP9RmME66FjaaU59HVlPJj8w/QylrAgQ023g=; b=Qb1Pa/8O1m/1X46hjmvSvLp24acO/jtiEUowst5JEDw4l5oiuefgl4OhP8b9NfWMoI VF58k2GNDDAkaP5hq08xYSkOciQHrh6MWjBN7fL/Oi52znQ05bSOHl9m2URhkWiFhrHg Lf3fijFKaIqew35AfkQyZ23i3qkWbqJrbmww6lAe5uGkhSTtIokaQAz+AFXKENDCHysh kudmPXbua58YbUtGJSh11gjsUfSOjj7QfaI5ZQZqoHxvP2sOU4CysnEaiRDWadYWpKBB Lb6uVPK1JnDmyg0OHLKkC2VCd3Mp0DbJtzr4HutV3ArmJT6r1WeqQUJmkMRNJyCtblvD Z9kw== MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr5906050vdb.95.1350324079265; Mon, 15 Oct 2012 11:01:19 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Mon, 15 Oct 2012 11:01:19 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> Date: Mon, 15 Oct 2012 11:01:19 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf3071c69c1387a704cc1cd3f0 X-Gm-Message-State: ALoCoQk7IOXaCOA1ja2BxaxFNfLc8JU8MgrFJaTts1uVHuhm2xn0SUDgCgSU/s4NebiO9cMZ268u Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:01:21 -0000 --20cf3071c69c1387a704cc1cd3f0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi AB, On Mon, Oct 15, 2012 at 10:53 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ulrich, > > MANET WG is working on AODVv2 (DYMO born 2005), we already discussed this > on the list. There is MANET WG consensus on the AODVv2 for many years, so > it should go forward to submission without noise from another > reactive-draft that was born in 2011. Do you mean there was an agreement > that we leave AODVv2 and replace to LOADng, if so please advise, (this > maybe agreed out of the meetings and the list which is not authorised yet= ). > As you can read in the last MANET minutes, there were discussions to adopt LOADng as WG document. Per charter, there is only one reactive routing protocol in MANET. There has not been a WG decision on that yet, in part because we need a new LOADng revision first, before it can even be considered. Best regards Ulrich > > AB > > On Mon, Oct 15, 2012 at 4:22 PM, Ulrich Herberg wrot= e: > >> Hi JP, >> >> >> On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) < >> jvasseur@cisco.com> wrote: >> >>> [...] >>> >>> >>> JP> Here we do not disagree at all. I am not saying that reactive >>> protocols are not appropriate in a number of scenario. All I am saying = is >>> that *if* you intent to specify >>> a reactive routing protocol for LLNs, knowing the years of intense work >>> and efforts of the ROLL WG, then it should be discussed with a wider >>> audience. >>> >> >> >> I agree. But that's not we are intending to do. We intent to produce a >> reactive protocol for MANETs, which is requested by the MANET charter. >> LOADng is a protocol that covers all the use cases of MANETs, one of whi= ch >> being LLNs. >> And yes, the introduction and title of the draft needs to be changed >> >> >> >> >>> On the other >>> hand, if your explicitly exclude LLNs from your protocol in your >>> protocol, it is no longer required to involve the ROLL WG. The objectiv= e is >>> simply to avoid WG charter >>> overlap but more importantly try to benefit from the benefit of experts >>> in the area of LLNs to build a good protocol for the Internet. >>> >> >> I am personally against removing to mention a use case where as a matter >> of fact the protocol is used in (as *one* use-case out of many). >> >> Citing Adrian from the last MANET meeting: >> >> Adrian Farrell: If you were to pick up a reactive protocol for MANET, yo= u would be in charter. If you pick up a protocol and your main use case is = for LLNs, you have diverged from charter. Main use case is delicate thing t= o talk about. It is clear that some if not all LLNs are MANET. Not all MANE= Ts are LLNs. So you need to be producing a single reactive protocol for MAN= ETs, not for *some* MANETs. You need to be clear that the protocol you work= on is applicable across all MANETs. If that picks up some LLNs across the = way, no big deal, but it should not be main use case. Look at all use cases= for MANETs and make sure you address all of those. >> >> >> This is exactly what we intend to do. >> >> >> >>> It was also agreed at the last MANET meeting that if LOADng was to be >>> considered for MANET, it needs to de-emphasize LLNs (which I have not h= eard >>> anybody disagree with so far). So I don't understand what we are even >>> discussing here. >>> >>> >>> JP> No, this your recollection of the discussion. "less-focussed" or >>> "de-emphasize" was I think your interpretation. Mine was "not referring= to >>> LLNs" at all. >>> >> >> >> I sincerely suggest to wait until you read the new revision, as this >> discussion is hypothetical without that. >> >> >> >>> Otherwise, it should be reviewed by both WGs (to be discussed between >>> chairs and AD). >>> >> >> Best >> Ulrich >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > --20cf3071c69c1387a704cc1cd3f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi AB,

On Mon, Oct 15, 2012 at 10:53 AM, = Abdussalam Baryun <abdussalambaryun@gmail.com> wrot= e:
Hi Ulrich,
=A0
MANE= T WG is working on=A0AODVv2 (DYMO born 2005), we already discussed this on = the list. There is=A0MANET WG consensus on the AODVv2 for many years, so it= should go forward to submission without noise from another reactive-draft = that was born=A0in 2011. Do you mean there was an agreement that we leave A= ODVv2 and replace to LOADng, if so please advise, (this maybe agreed out of= the meetings and the list which is not authorised yet).


As you can read in the last= MANET minutes, there were discussions to adopt LOADng as WG document. Per = charter, there is only one reactive routing protocol in MANET. There has no= t been a WG decision on that yet, in part because we need a new LOADng revi= sion first, before it can even be considered.

Best regards
Ulrich

= =A0
=A0
AB

On Mon, Oct 15, 2012 at 4:22 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi JP,


On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) &= lt;jvasseur@cisco.c= om> wrote:
[...]


JP> Here we do not disagree at all. I am not saying that reac= tive protocols are not appropriate in a number of scenario. All I am saying= is that *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of intense wor= k and efforts of the ROLL WG, then it should be discussed with a wider audi= ence.


I agree. But that's not we are intending to do. We intent to produ= ce a reactive protocol for MANETs, which is requested by the MANET charter.= LOADng is a protocol that covers all the use cases of MANETs, one of which= being LLNs.
And yes, the introduction and title of the draft needs to be changed


=A0
On the other
hand, if your explicitly exclude LLNs from your protocol in your proto= col, it is no longer required to involve the ROLL WG. The objective is simp= ly to avoid WG charter
overlap but more importantly try to benefit from the benefit of expert= s in the area of LLNs to build a good protocol for the Internet.

I am personally against= removing to mention a use case where as a matter of fact the protocol is u= sed in (as *one* use-case out of many).

Citing Adrian from the last MANET meeting:
Adrian Farrell: If y= ou were to pick up a reactive protocol for MANET, you would be in charter. = If you pick up a protocol and your main use case is for LLNs, you have dive= rged from charter. Main use case is delicate thing to talk about. It is cle= ar that some if not all LLNs are MANET. Not all MANETs are LLNs. So you nee= d to be producing a single reactive protocol for MANETs, not for *some* MAN= ETs. You need to be clear that the protocol you work on is applicable acros= s all MANETs. If that picks up some LLNs across the way, no big deal, but i= t should not be main use case. Look at all use cases for MANETs and make su= re you address all of those.

This is exactly what we intend to do.
<= div>


It was also agreed at the last MANET meeting that if LOADng was to be = considered for MANET, it needs to de-emphasize LLNs (which I have not heard= anybody disagree with so far). So I don't understand what we are even = discussing here.=A0

JP> No, this your recollection of the discussion. "less-= focussed" or "de-emphasize" was I think your interpretation.= Mine was "not referring to LLNs" at all.=A0


I sincerely sug= gest to wait until you read the new revision, as this discussion is hypothe= tical without that.=A0

=A0
Otherwise, it should be reviewed by both WGs (to be discussed between = chairs and AD).

Best
Ulrich=A0

_________________________________________= ______
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--20cf3071c69c1387a704cc1cd3f0-- From abdussalambaryun@gmail.com Mon Oct 15 11:01:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7F21F8875 for ; Mon, 15 Oct 2012 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KLC7Azf0BjY for ; Mon, 15 Oct 2012 11:01:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C38621F8873 for ; Mon, 15 Oct 2012 11:01:35 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6220194vbb.31 for ; Mon, 15 Oct 2012 11:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0UM5xn81oifr8qEz5mrk7iSbRZ0gd10nvfZsFsppj4=; b=b7UXnjYXKv50Cw9ptVXEatq6VPuRZHKCPh8l0ohmYumwR5lT7Du7fBa60YOgztLiGz /GEiK2tYVCM3/3SHiLb/72gOByarkDL/lkRp75UkseCRab6URkQGR2mKBant+nbh7z83 1IretE+Kl1abqbJYjmHuELQSzbmfN/UX5Vfhbi9bgmrzvYQcMW0107IiCHTn8u/IU0Hp M5xlJTMIa/KvPQXqQ5IqIW6tq2Fz6Dk9QZNrRFfkY4ENIraQbFI8GxBOMRWsAx0tang1 DNRnfVM7ofgcX7yPbZSj/Yhce+eEZ1Zn7mE7hEClMSr1Hj9Bn08luhx57Q76mZ+Xp3D8 OYiQ== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr5830349vdb.125.1350324094779; Mon, 15 Oct 2012 11:01:34 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 15 Oct 2012 11:01:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Oct 2012 19:01:34 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf307f3bcc00413c04cc1cd435 Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:01:36 -0000 --20cf307f3bcc00413c04cc1cd435 Content-Type: text/plain; charset=ISO-8859-1 I will check it again as well, but as you said it is out of scope to MANET WG to discuss LLN or RPL, then the draft refered to was out of scope and we as MANET WG should take it out of the minutes and delet any noise. Please note that the minutes should be called consensus before approved. AB On Mon, Oct 15, 2012 at 4:33 PM, Ulrich Herberg wrote: > Hi AB, > > On Mon, Oct 15, 2012 at 1:55 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> [...] >> > >> If you read the minutes of MANET WG meeting IETF84 [1] you will find >> there was a discussion, my input was only a reflection. Please note >> that refering to I-D [2] was in the minutes which I agree that we >> SHOULD delete from our MANET minutes because it is another *overalp* >> (I don't beleive that the I-D name was pronounced in the meeting but >> the minute writter prefered to advertise the name). >> >> I RECOMMEND the Chair of MANET to delete the name of RPL experience >> I-D from the minutes because it is/was note said just indicated such >> as draft not named. >> > > > I strongly disagree. I have listened to the audio again. Thomas Clausen > clearly named the moniker of the draft. The minutes are supposed to reflect > what has been said in the meeting. > > > [...] > > Best > Ulrich > --20cf307f3bcc00413c04cc1cd435 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I will check it again as well,=A0but as you said it is out of scope to= MANET WG to discuss LLN or RPL, then the draft refered to was out of scope= and we as MANET WG should take it out of the minutes and delet any noise.<= /div>
=A0
Please note that the minutes should be called consensus= =A0before approved.
=A0
AB

On Mon, Oct 15, 2012 at 4:33 PM, Ulrich Herberg <ulrich@her= berg.name> wrote:
Hi AB,

On Mon, Oct 15, 2= 012 at 1:55 AM, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
[...]

=A0If you read the minutes of MANET WG meeting IETF84 [1] you will find
there was a discussion, my input was only a reflection. Please note
that refering to I-D [2] was in the minutes which I agree that we
SHOULD delete from our MANET minutes because it is another *overalp*
(I don't beleive that the I-D name was pronounced in the meeting but the minute writter prefered to advertise the name).

I RECOMMEND the Chair of MANET to delete the name of RPL experience
I-D from the minutes because it is/was note said just indicated such
as draft not named.


I strongly disagree. I have listened to the audio again. Thomas Clausen c= learly named the moniker of the draft. The minutes are supposed to reflect = what has been said in the meeting.


[...]

Best
Ulrich

--20cf307f3bcc00413c04cc1cd435-- From abdussalambaryun@gmail.com Mon Oct 15 11:03:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C692021F8873 for ; Mon, 15 Oct 2012 11:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu4H6UKSyxxq for ; Mon, 15 Oct 2012 11:03:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0321F8871 for ; Mon, 15 Oct 2012 11:03:24 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6778220vcb.31 for ; Mon, 15 Oct 2012 11:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2I32ZVSoXf2y5UruLLIN+XTaFzX/WxjHtrmd0QoauX4=; b=Wt1xxdWVDkcvg1ibEFrvgEqQsUR+1HRXm2/qypZybpXGdXCGR+ibOFHEmY6k/MbBv0 aDNJoQY9vlf+bI55wBB7vkcj26VTb8sn3JYFURby4Wnh12I4ziE77VVwMbFGkCnarNpJ /7J2O9TvgwZQIvJ1rwF+PHDEJR5GRW0xj5tKv3bafguUSnWdRny/UmTseLgQbH5MYv6S BhFa29exMP6BwPCDCzpKKG3tlAjU4DiVDE+78p1QX2n6BRaPu9O/E2RadW065uqvl+Ql xchMJ+jDzb07gCWLjgXWbhQp8xfhuZ0iYULyD5uMD0udOKw3vDJ+2ThQLxRXwb0uMDCG IjBw== MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr7230959vec.51.1350324204442; Mon, 15 Oct 2012 11:03:24 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 15 Oct 2012 11:03:21 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> Date: Mon, 15 Oct 2012 19:03:21 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b2e535289968b04cc1cda75 Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:03:25 -0000 --047d7b2e535289968b04cc1cda75 Content-Type: text/plain; charset=ISO-8859-1 there was discussion but no consensus, and there was objections, AB On Mon, Oct 15, 2012 at 7:01 PM, Ulrich Herberg wrote: > Hi AB, > > On Mon, Oct 15, 2012 at 10:53 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Ulrich, >> >> MANET WG is working on AODVv2 (DYMO born 2005), we already discussed this >> on the list. There is MANET WG consensus on the AODVv2 for many years, so >> it should go forward to submission without noise from another >> reactive-draft that was born in 2011. Do you mean there was an agreement >> that we leave AODVv2 and replace to LOADng, if so please advise, (this >> maybe agreed out of the meetings and the list which is not authorised yet). >> > > > As you can read in the last MANET minutes, there were discussions to adopt > LOADng as WG document. Per charter, there is only one reactive routing > protocol in MANET. There has not been a WG decision on that yet, in part > because we need a new LOADng revision first, before it can even be > considered. > > Best regards > Ulrich > > > --047d7b2e535289968b04cc1cda75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
there was discussion but no consensus, and there was objections,
=
=A0
AB

On Mon, Oct 1= 5, 2012 at 7:01 PM, Ulrich Herberg <ulrich@herberg.name> w= rote:
Hi AB,

On Mon, Oct 15, 2012 at 10:53 AM, Abdussalam Baryun <= abdussalamb= aryun@gmail.com> wrote:
Hi Ulrich,
=A0
MANET WG is workin= g on=A0AODVv2 (DYMO born 2005), we already discussed this on the list. Ther= e is=A0MANET WG consensus on the AODVv2 for many years, so it should go for= ward to submission without noise from another reactive-draft that was born= =A0in 2011. Do you mean there was an agreement that we leave AODVv2 and rep= lace to LOADng, if so please advise, (this maybe agreed out of the meetings= and the list which is not authorised yet).


As you can read in th= e last MANET minutes, there were discussions to adopt LOADng as WG document= . Per charter, there is only one reactive routing protocol in MANET. There = has not been a WG decision on that yet, in part because we need a new LOADn= g revision first, before it can even be considered.

Best regards
Ulrich

=A0
--047d7b2e535289968b04cc1cda75-- From hrogge@googlemail.com Mon Oct 15 11:06:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09321F889E for ; Mon, 15 Oct 2012 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDF8ZjLPUe+O for ; Mon, 15 Oct 2012 11:06:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2F621F889B for ; Mon, 15 Oct 2012 11:06:45 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so5115160pbb.31 for ; Mon, 15 Oct 2012 11:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WFwzlH6Vw/BwH8TKarGPk6EtaUNrdEAzO6pvh1bcboI=; b=yjzuvfoW/2ApMO5Qch6rNwA3g3gcRqVyPfUp005Zfp0XDs37gys7YEx27YaybunRhc Ink3uTTBS1ZVHC5ar92dBfdCVbq19CxvwYG5sqeT9rxF2Cr322Hnea4yhYTqDvv0e4YI tK6lEMHNi++8VUFYiosdK14gIneZ8GU3tdgy+6Vvx0PcDr544AUT5MlVvOxiOqqI4yzL pE9ddFr1bSbJY5vQw1Z6Hn5v/cMIjdi7UOMixEEuTiZ5UN4NVdi/Vwh+x97jLo3OPLB2 3M09vpJEebEeEy8n0P2H3P9REe/dOls0VIN0GwjvsBldmAEvzg5YKeUPT+Ex9Ne/sebK ZvTw== Received: by 10.68.138.198 with SMTP id qs6mr39663920pbb.151.1350324405230; Mon, 15 Oct 2012 11:06:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Mon, 15 Oct 2012 11:06:24 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Mon, 15 Oct 2012 20:06:24 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:06:46 -0000 On Mon, Oct 15, 2012 at 7:58 PM, Abdussalam Baryun wrote: >> >> Yep. LOADng is intended for the MANET domain, and is discussed here. It >> also, but not exclusively, is applicable to the special case of a MANET that >> some call an LLN. > > I call thoes: Lossy MANET = LMANET Has there ever been a MANET without lossy links, except for the ones in simulation (NS2, wifi, tworay-ground)? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Mon Oct 15 11:08:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D7B21F884B for ; Mon, 15 Oct 2012 11:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHyBkG0kgoIW for ; Mon, 15 Oct 2012 11:08:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3366D21F87D7 for ; Mon, 15 Oct 2012 11:08:47 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6229419vbb.31 for ; Mon, 15 Oct 2012 11:08:46 -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=S/T/bSafOQ48nkbE1aE3zfIslCCJuwe5cRHfA9yZyNw=; b=pulNYP2thlxivFUFKDDXhI4bnlNhtRYVRToMIvwhQ/bxNq6MrdreJIhF5PmDFMN68A ykygVbSUiRwuzKUR/bn5ZU4yogC+ivPaj611Opk5WJBeGGPx1X4Pz+4k1PGqvKavR2Vp YrM0qsFJnCDmj+R9cC50g4FiCjBGUmXTTSbho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=S/T/bSafOQ48nkbE1aE3zfIslCCJuwe5cRHfA9yZyNw=; b=atM6A3aE+FcpUjuLtZVxy4bwsiE+Cd3RMVTA3ER0gcpeMtpULcygqv8yLd2xtogdBR Qujzw+4j0DKp2H9m9CZkCk+uI1ctMGkXnm1bF9UHQmqPyYoAbIpBlEwxmxu17vPBGybR JiIVLGbq70Yy5OglywANhTm3/ODwCX9AlY2ZPquk+oUX/f3kPDllUIMA+ZUHacxc2PNu RMqbngMzyrGzBsAltx4EMn36s/lOMHw61sRB7WAEjuo0MmnOKS+1ZsRv7736mUt+OeTs uTgevERAk+twdIMqFqp+eBd+7Vja4rPJhtN2VwCMnVrcUf5BVtywNDSaT4VF7sGiks62 KmvA== MIME-Version: 1.0 Received: by 10.58.23.100 with SMTP id l4mr7333435vef.46.1350324526638; Mon, 15 Oct 2012 11:08:46 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Mon, 15 Oct 2012 11:08:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Oct 2012 11:08:46 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b339d9dbde50e04cc1ced82 X-Gm-Message-State: ALoCoQntdbaqsD6NZaKckbefAPHKZOCBQK/Vrof+N0DO7L2UI7F3VH4xkPZ/ANW+CFH5kmQzuPIM Cc: " List" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:08:48 -0000 --047d7b339d9dbde50e04cc1ced82 Content-Type: text/plain; charset=ISO-8859-1 Hi AB, On Mon, Oct 15, 2012 at 11:01 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > I will check it again as well, but as you said it is out of scope to MANET > WG to discuss LLN or RPL, then the draft refered to was out of scope and we > as MANET WG should take it out of the minutes and delet any noise. > Absolutely not. The minutes reflect what has been said. You may not agree with what has been discussed in the meeting; it is the chairs' responsibility to lead the WG meeting and to decide whether discussions are relevant. And I think they do a great job. It is the minute-takers job to reflect as accurately as possible what has been said in the meeting. > > Please note that the minutes should be called consensus before approved. > This is a question to the chairs, so I won't answer here. Just that: Do you have any concrete item that you believe has not been represented correctly? Best Ulrich > > AB > > On Mon, Oct 15, 2012 at 4:33 PM, Ulrich Herberg wrote: > >> Hi AB, >> >> On Mon, Oct 15, 2012 at 1:55 AM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> wrote: >> >>> [...] >>> >> >>> If you read the minutes of MANET WG meeting IETF84 [1] you will find >>> there was a discussion, my input was only a reflection. Please note >>> that refering to I-D [2] was in the minutes which I agree that we >>> SHOULD delete from our MANET minutes because it is another *overalp* >>> (I don't beleive that the I-D name was pronounced in the meeting but >>> the minute writter prefered to advertise the name). >>> >>> I RECOMMEND the Chair of MANET to delete the name of RPL experience >>> I-D from the minutes because it is/was note said just indicated such >>> as draft not named. >>> >> >> >> I strongly disagree. I have listened to the audio again. Thomas Clausen >> clearly named the moniker of the draft. The minutes are supposed to reflect >> what has been said in the meeting. >> >> >> [...] >> >> Best >> Ulrich >> > > --047d7b339d9dbde50e04cc1ced82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi AB,

On Mon, Oct 15, 2012 at 11:01 AM, = Abdussalam Baryun <abdussalambaryun@gmail.com> wrot= e:
I will check it again as well,=A0but as= you said it is out of scope to MANET WG to discuss LLN or RPL, then the dr= aft refered to was out of scope and we as MANET WG should take it out of th= e minutes and delet any noise.

Absolutely not. The minutes reflect what h= as been said. You may not agree with what has been discussed in the meeting= ; it is the chairs' responsibility to lead the WG meeting and to decide= whether discussions are relevant. And I think they do a great job. It is t= he minute-takers job to reflect as accurately as possible what has been sai= d in the meeting.

=A0
=A0
Please note that the minutes should be called consensus= =A0before approved.

This is a questio= n to the chairs, so I won't answer here. Just that: Do you have any con= crete item that you believe has not been represented correctly?

Best
Ulrich
=A0
=A0
AB

On Mon, Oct 15, 2012 at 4:33 PM, Ulrich= Herberg <ulrich@herberg.name> wrote:
Hi AB,

On Mon, Oct 15, 2= 012 at 1:55 AM, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
[...]

=A0If you read the minutes of MANET WG meeting IETF84 [1] you will find
there was a discussion, my input was only a reflection. Please note
that refering to I-D [2] was in the minutes which I agree that we
SHOULD delete from our MANET minutes because it is another *overalp*
(I don't beleive that the I-D name was pronounced in the meeting but the minute writter prefered to advertise the name).

I RECOMMEND the Chair of MANET to delete the name of RPL experience
I-D from the minutes because it is/was note said just indicated such
as draft not named.


I strongly disagree. I have listened to the audio again. Thomas Clausen c= learly named the moniker of the draft. The minutes are supposed to reflect = what has been said in the meeting.


[...]

Best
Ulrich


--047d7b339d9dbde50e04cc1ced82-- From jvasseur@cisco.com Mon Oct 15 12:35:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8721F897D for ; Mon, 15 Oct 2012 12:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WX2zF9EP7gg for ; Mon, 15 Oct 2012 12:35:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8821F8990 for ; Mon, 15 Oct 2012 12:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1147; q=dns/txt; s=iport; t=1350329758; x=1351539358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bJVa36F5MJ7FdLRSyMvPDEiWtBekIudV2QGRR1e5Xkg=; b=C93AcNy8mKLuW/G7GUy36KJ+7dUL3AhgU1EN4VgnbfY1un6U+0dwMu40 24irWZ0yphKuSlyzvkbbzCqHlgKoYzc0GT/lIn7E+PkQ9XW7YFq4MVsd9 NH6bKXdAHGCx7ghz+Ei4yEXcEmji4SFk1Y4Q9IIpV7+LodI3O3rXEydu1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANdkfFCtJV2c/2dsb2JhbABFwASBCIIgAQEBAwEBAQEPASc0CwULAgEIDgoKFBAhBgslAgQOBQgah1ADCQYLnQ2WOg2JUASKc2aFXWADlBeMeIMigWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,590,1344211200"; d="scan'208";a="131596780" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2012 19:35:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9FJZnGR029285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 19:35:49 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 14:35:49 -0500 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Mon, 15 Oct 2012 19:35:49 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--40.030500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <784A92E8CFA5644FA01672D247D161B9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 19:36:00 -0000 Hi Henning, On Oct 15, 2012, at 8:06 PM, Henning Rogge wrote: > On Mon, Oct 15, 2012 at 7:58 PM, Abdussalam Baryun > wrote: >>>=20 >>> Yep. LOADng is intended for the MANET domain, and is discussed here. It >>> also, but not exclusively, is applicable to the special case of a MANET= that >>> some call an LLN. >>=20 >> I call thoes: Lossy MANET =3D LMANET >=20 > Has there ever been a MANET without lossy links, except for the ones > in simulation (NS2, wifi, tworay-ground)? >=20 LLN is a combination of well-known constrained though: lossy links, low ban= dwidth and constrained nodes. This is that unique combination that makes it difficult and that justified = forming a new WG at the IETF (ROLL). Does that make sense ? Thanks. JP. > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From thomas.r.henderson@boeing.com Mon Oct 15 17:22:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668F521F883F for ; Mon, 15 Oct 2012 17:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPM7MocSv91v for ; Mon, 15 Oct 2012 17:22:40 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 73C9A21F882F for ; Mon, 15 Oct 2012 17:22:31 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9G0MUoT017125 for ; Mon, 15 Oct 2012 19:22:30 -0500 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9G0MTUs017122 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 15 Oct 2012 19:22:30 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 15 Oct 2012 17:22:29 -0700 From: "Henderson, Thomas R" To: "'manet@ietf.org'" Date: Mon, 15 Oct 2012 17:22:28 -0700 Thread-Topic: suggestions for further DLEP development Thread-Index: Ac2rNEyBrbe0ZW05QDyLCpjgBljWbA== Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.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 X-TM-AS-MML: No Subject: [manet] suggestions for further DLEP development X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 00:22:41 -0000 Hi, I had a chance today to finally read the -03 dlep draft, and catch up o= n the list traffic since it was published. I'd like to suggest a few thing= s to try to make better progress. First, it is very hard to review the list traffic to figure out what has re= ached either WG consensus or a decision point by the authors. There are po= ssibly hundreds of messages with the same subject line "Some comments on ma= net-dlep-03", containing many separate technical threads. Could people ple= ase make an effort in the future to originate a new subject line when the t= opic forks, and to try to keep topics organized and separated by thread tha= t is clear in the subject line? It was previously suggested to use the tracker to document these issues and= their wrapup/conclusion, an idea that I offer +1 to, but if the WG chooses= to not use the tracker, perhaps some kind of informal convention could be = adopted such as posting to the list with a clear subject such as "Decision = on RFC 5444 issue for DLEP". I'd also be in favor of recording this in a c= hange log in the draft, for that matter, but I would be happy with just usi= ng an issue tracker or summary messages on the list if the authors do not w= ant to use the draft this way. Regarding the draft itself, it seems to me that there are still many fundam= ental disagreements or concerns about underspecification of the basic proto= col for message exchanges and management of state between the entities. I'= d suggest first that the group try to document/decide basic aspects of the = protocol without concern for the finer details of some of the radio-specifi= c parameters. Such as: - is DLEP transport independent or not? If so, what are the anticipated t= ransports? - is there a need for a stateful session? - is there a need for a per-session identifier? DLEP-layer node identifier= s? a message sequence number? - what are the requirements for reliable message delivery, unreliable messa= ge delivery, etc.? - how do acknowledgments work? Are acknowledgments on a per-TLV or per-mes= sage basis? - who can initiate or terminate a session? - RFC 5444 or not? - what is the version number; what is the distinction between major and min= or numbers? - can messages mix optional TLVs with mandatory, reliable TLVs? Is TLV ord= ering to be enforced? etc. I'd suggest that the working group focus first on writing down and agreeing= upon some requirements and detailed protocol just to cover the session sta= te aspects, such that it would be really hard to come up with implementatio= ns that did not interoperate at that level. Then move on to the radio-spec= ific TLVs and issues there. This kind of protocol has been done before and (I've suggested this in the = past) it may be more efficient to try to reuse/adapt an existing protocol (= LCP and X.25 come to mind). This protocol may seem simple but when one sta= rts to deal with issues such as race conditions, state misalignment (one si= de reboots and the other side doesn't detect it), notifications of errors t= o the peer, parameter negotiations, multiple devices on link, etc. one gets= into issues that lead to interoperability and robustness problems. - Tom=20 From charliep@computer.org Mon Oct 15 18:06:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554E41F0C61 for ; Mon, 15 Oct 2012 18:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUjQ3bH+0M55 for ; Mon, 15 Oct 2012 18:06:58 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0D1F041F for ; Mon, 15 Oct 2012 18:06:57 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TNvcX-00028r-B8; Mon, 15 Oct 2012 21:06:57 -0400 Message-ID: <507CB329.8010508@computer.org> Date: Mon, 15 Oct 2012 18:06:49 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "'manet@ietf.org'" References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ec40d84420d86f6be112256bbe557aea350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "Henderson, Thomas R" Subject: Re: [manet] suggestions for further DLEP development X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 01:06:59 -0000 Hello folks, Just one comment... On 10/15/2012 5:22 PM, Henderson, Thomas R wrote: > It was previously suggested to use the tracker to document these issues and their wrapup/conclusion, an idea that I offer +1 to, but if the WG chooses to not use the tracker, perhaps some kind of informal convention could be adopted such as posting to the list with a clear subject such as "Decision on RFC 5444 issue for DLEP". I'd also be in favor of recording this in a change log in the draft, for that matter, but I would be happy with just using an issue tracker or summary messages on the list if the authors do not want to use the draft this way. For any draft with contentious issues, I think that the issue tracker ought to be considered a "must", and the change log is even more of a "must". It really helps to avoid going around in circles. I also agree that it is very helpful to use more descriptive "Subject:" lines, but it is not so easy to remember to do that. -- Regards, Charlie P. From ppcs2214@gmail.com Mon Oct 15 21:49:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BCD21F86F7 for ; Mon, 15 Oct 2012 21:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td2h1IVKfi+4 for ; Mon, 15 Oct 2012 21:49:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22FFE21F86E4 for ; Mon, 15 Oct 2012 21:49:40 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so5337464qcg.31 for ; Mon, 15 Oct 2012 21:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4/WUFy/2wvI9oHu6iul5Y/z/LBAhwkPP49BBW+5207U=; b=GngvabkYax8HKE/uLo7IEqMcOKLmtv63oMKHIcFMP873LT+JwRvi32DcqRz8gWEzFL nPsKuMLB9Hk+rRMdPvVIaJazbeWQfso/Zeic54AP1cuwwPhLxD0SzwAB2S7XgrQ4MBoQ a6D7J/zGuXBIR2hPjg5IB3nx8y33cm1zqs1wtV1I87Br4xSFLM01WpU0fuGRNpuXQjni bKrvoG8Z/FkL/2ziqY1SzzJhi36TJLCPILIq8lMWQmqtScZ2JTv34eEfWoYP4S+rn6NG th4gdwCBdmV/kpaC3VifN9cgo8FYweCxpqYA1KvTSHpFei4NOdJRjz0gAmj0QfRdifpE 9tEA== MIME-Version: 1.0 Received: by 10.224.109.199 with SMTP id k7mr9607298qap.66.1350362979423; Mon, 15 Oct 2012 21:49:39 -0700 (PDT) Received: by 10.49.85.38 with HTTP; Mon, 15 Oct 2012 21:49:39 -0700 (PDT) Date: Tue, 16 Oct 2012 10:19:39 +0530 Message-ID: From: Pr To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf3074b3ccb4d51604cc25e171 Subject: [manet] INTERFERENCE POWER X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 04:49:43 -0000 --20cf3074b3ccb4d51604cc25e171 Content-Type: text/plain; charset=ISO-8859-1 > > is there any formula to calculate noise > power based on transmitter power or receiver > power or based on distance between them? > I saw a formula in mathworks.in website > while generally searcing in google which is: > interference power=transmission power-signal power-noise power. > Is this a basic formula or derived from any other formula? > --20cf3074b3ccb4d51604cc25e171 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0 is there any formula to calculate noise
power= based on transmitter power or receiver
power or based on distance between them?
I saw a formula in = mathworks.in website
while ge= nerally searcing in google which is:
interference power=3Dtransmi= ssion power-signal power-noise power.
Is this a basic formula or derived from any other formula?
=
--20cf3074b3ccb4d51604cc25e171-- From henning.rogge@fkie.fraunhofer.de Mon Oct 15 22:17:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11F21F87F4 for ; Mon, 15 Oct 2012 22:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwB3TZdduQzR for ; Mon, 15 Oct 2012 22:17:35 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1721F87E8 for ; Mon, 15 Oct 2012 22:17:34 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TNzX3-0004hi-DN for manet@ietf.org; Tue, 16 Oct 2012 07:17:33 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TNzX3-0003pk-Ak for manet@ietf.org; Tue, 16 Oct 2012 07:17:33 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Oct 2012 07:17:33 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 16 Oct 2012 07:17:32 +0200 Message-ID: <507CEDE5.9080800@fkie.fraunhofer.de> Date: Tue, 16 Oct 2012 07:17:25 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090107070307000807080409" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 16 Oct 2012 05:17:33.0124 (UTC) FILETIME=[8BE94040:01CDAB5D] X-Virus-Scanned: yes (ClamAV 0.97.5/15464/Mon Oct 15 19:41:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b023bd6aafd0ed920562fab22193c372 Subject: Re: [manet] INTERFERENCE POWER X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 05:17:36 -0000 --------------ms090107070307000807080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/16/2012 06:49 AM, Pr wrote: > is there any formula to calculate noise > power based on transmitter power or receiver > power or based on distance between them? > I saw a formula in mathworks.in website > while generally searcing in google which is: > interference power=3Dtransmission power-signal power-noise power. > Is this a basic formula or derived from any other formula? I think this highly depends on your model of the radio propagation. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090107070307000807080409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTYwNTE3MzBaMCMGCSqGSIb3DQEJBDEWBBRuRyCjBNNyxewHIqyy+kvdxSEFQTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAI5O9aB0FcSMmSJI8ZjNPerUxIINob9LOa/zOBvh0/9fK DJZEmbdNTnDfNc/rEEGOtQzTueaTMu7OGR1VPRdUjBSVccU5VXMMty1ipUsEkX68n9nxb2XG ngdbyWKzfOIgkIkJ+jYAbIOQkEJxES0YPkpowm8ar4J8nN7etDZWFEyyb4gAGrWN/iFYa55q JZx1cdWkR86k2VKckL69T870iJ+yNWVEnWy1ZDcHfYDkQp2PznTOHQAnZnpfzbF/pNUeBRCK atequBPqfgUNi332h4H2BkBMDa4+vIoPs9vwqTA2mRKOLyxcRhMsX1NzO+VNgP8scwtk18+d e2VZ1fn+kAAAAAAAAA== --------------ms090107070307000807080409-- From henning.rogge@fkie.fraunhofer.de Mon Oct 15 22:28:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A017121F8813 for ; Mon, 15 Oct 2012 22:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5tbonALcowF for ; Mon, 15 Oct 2012 22:28:27 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A23BA21F8811 for ; Mon, 15 Oct 2012 22:28:26 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TNzhY-00085e-H8 for manet@ietf.org; Tue, 16 Oct 2012 07:28:24 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TNzhY-000480-EV for manet@ietf.org; Tue, 16 Oct 2012 07:28:24 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Oct 2012 07:28:24 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 16 Oct 2012 07:28:23 +0200 Message-ID: <507CF076.80809@fkie.fraunhofer.de> Date: Tue, 16 Oct 2012 07:28:22 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060905030106000905040505" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 16 Oct 2012 05:28:24.0237 (UTC) FILETIME=[100135D0:01CDAB5F] X-Virus-Scanned: yes (ClamAV 0.97.5/15464/Mon Oct 15 19:41:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 05:28:28 -0000 --------------ms060905030106000905040505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/15/2012 09:35 PM, JP Vasseur (jvasseur) wrote: > LLN is a combination of well-known constrained though: lossy links, low= bandwidth and constrained nodes. > This is that unique combination No, it is not unique. Its also the default description of MANET/MESH. > that makes it difficult and that justified forming a new WG at the=20 IETF (ROLL). > Does that make sense ? ROLL looks (mostly) into Zigbee based stationary networks. This are=20 reasonable fast networks and one of the basic assumptions of of ROLL=20 seems to be that the link quality doesn't change that much over time (an = assumption that makes sense because of the lack of mobility). This is a part of the "problem space" MANET looks into... similar to the = fact that some MANET protocols are just normal routing protocols that=20 have been optimized for less stable links. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060905030106000905040505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTYwNTI4MjJaMCMGCSqGSIb3DQEJBDEWBBRmNTLmx0YsSn/fqnrQ5PLHRFUuCTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAwmLCsLvqrfWanVIvsx+3bWGdVVm/cqeOy9CHeqxki+u5 JGdAQRMguDrpxvGMm7Ts32PKzXgfvdXtL9MWUboOaZ3VR52pKM9BX8em5swX9DW2RyoEGl4u S8DzMqaccKzxPznU1GQFJO4IF82dOZ9YcUbxHvSD29HFndES/7sRV8HReOJ41jJcEZzaonkW 0iLgbXxx0LE7oNTRiXHoWMYLYK8xsyxx6huoND+StNkz+SUQHOuN7h5ARR+kcDJYgTVboqmo 41K/MUgSWcZ+STA0C0eV4+59vKTPYWLdq/zUq0etVsjmEQZ4KnD1AcgYtWoVEld7gR/9OOWr 69SfyETPQwAAAAAAAA== --------------ms060905030106000905040505-- From srinivaskanakala@gmail.com Mon Oct 15 23:03:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101BF21F873D for ; Mon, 15 Oct 2012 23:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FezC1nec4uQn for ; Mon, 15 Oct 2012 23:03:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 010BA21F871C for ; Mon, 15 Oct 2012 23:03:17 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so4486085lbo.31 for ; Mon, 15 Oct 2012 23:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=fw9oPV5XOTMCOBRj3u3t/D6q4JwaqYCd0ROcPysOPlw=; b=x8YMIfq/+mYN2nk0puRbTq3I6pQWfptkUStjH1B/PmYXfhA3jR4G2DecmabkOHUdv8 YrDt25sEyRjWVEhbl4pW9x3AEmd6h8RCFJVOx9yKF0VOH/GyQuE24/ieMjHovUe3MLlz NFWos/ldM7opaJQfS644Bts3FSKfDALWPp/A/XRKmG1djhHAWAIshG8LJCa7zqB3hfic QlDIOgRAeOuD/Gfnet0+L7KJQKnEOQeWYpV7nfdeyBV85+ENOFUCZGrnkz7yii29wA+6 cHdWbcmXIxyyfyVRbFus2p7d46XGMqtoxL2ubra/eSCs5FrrDZLEw0CcP6v8KeuXQrNL wa5Q== MIME-Version: 1.0 Received: by 10.112.45.231 with SMTP id q7mr5067459lbm.133.1350367396576; Mon, 15 Oct 2012 23:03:16 -0700 (PDT) Received: by 10.112.8.168 with HTTP; Mon, 15 Oct 2012 23:03:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Oct 2012 11:33:16 +0530 Message-ID: From: Srinivas Kanakala To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] manet Digest, Vol 101, Issue 87 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:03:20 -0000 visit www.csestudent.com On Tue, Oct 16, 2012 at 10:47 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/manet > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send manet mailing list submissions to > manet@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/manet > or, via email, send a message with subject or body 'help' to > manet-request@ietf.org > > You can reach the person managing the list at > manet-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of manet digest..." > > > Today's Topics: > > 1. Re: MANET meeting at IETF85 (JP Vasseur (jvasseur)) > 2. suggestions for further DLEP development (Henderson, Thomas R) > 3. Re: suggestions for further DLEP development (Charles E. Perkins) > 4. INTERFERENCE POWER (Pr) > 5. Re: INTERFERENCE POWER (Henning Rogge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 15 Oct 2012 19:35:49 +0000 > From: "JP Vasseur (jvasseur)" > To: Henning Rogge > Cc: " List" > Subject: Re: [manet] MANET meeting at IETF85 > Message-ID: > <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi Henning, > > On Oct 15, 2012, at 8:06 PM, Henning Rogge wrote: > >> On Mon, Oct 15, 2012 at 7:58 PM, Abdussalam Baryun >> wrote: >>>> >>>> Yep. LOADng is intended for the MANET domain, and is discussed here. I= t >>>> also, but not exclusively, is applicable to the special case of a MANE= T that >>>> some call an LLN. >>> >>> I call thoes: Lossy MANET =3D LMANET >> >> Has there ever been a MANET without lossy links, except for the ones >> in simulation (NS2, wifi, tworay-ground)? >> > > LLN is a combination of well-known constrained though: lossy links, low b= andwidth and constrained nodes. > This is that unique combination that makes it difficult and that justifie= d forming a new WG at the IETF (ROLL). > Does that make sense ? > > Thanks. > > JP. > >> Henning Rogge >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > ------------------------------ > > Message: 2 > Date: Mon, 15 Oct 2012 17:22:28 -0700 > From: "Henderson, Thomas R" > To: "'manet@ietf.org'" > Subject: [manet] suggestions for further DLEP development > Message-ID: > <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boe= ing.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi, I had a chance today to finally read the -03 dlep draft, and catch up= on the list traffic since it was published. I'd like to suggest a few thi= ngs to try to make better progress. > > First, it is very hard to review the list traffic to figure out what has = reached either WG consensus or a decision point by the authors. There are = possibly hundreds of messages with the same subject line "Some comments on = manet-dlep-03", containing many separate technical threads. Could people p= lease make an effort in the future to originate a new subject line when the= topic forks, and to try to keep topics organized and separated by thread t= hat is clear in the subject line? > > It was previously suggested to use the tracker to document these issues a= nd their wrapup/conclusion, an idea that I offer +1 to, but if the WG choos= es to not use the tracker, perhaps some kind of informal convention could b= e adopted such as posting to the list with a clear subject such as "Decisio= n on RFC 5444 issue for DLEP". I'd also be in favor of recording this in a= change log in the draft, for that matter, but I would be happy with just u= sing an issue tracker or summary messages on the list if the authors do not= want to use the draft this way. > > Regarding the draft itself, it seems to me that there are still many fund= amental disagreements or concerns about underspecification of the basic pro= tocol for message exchanges and management of state between the entities. = I'd suggest first that the group try to document/decide basic aspects of th= e protocol without concern for the finer details of some of the radio-speci= fic parameters. Such as: > > - is DLEP transport independent or not? If so, what are the anticipated= transports? > - is there a need for a stateful session? > - is there a need for a per-session identifier? DLEP-layer node identifi= ers? a message sequence number? > - what are the requirements for reliable message delivery, unreliable mes= sage delivery, etc.? > - how do acknowledgments work? Are acknowledgments on a per-TLV or per-m= essage basis? > - who can initiate or terminate a session? > - RFC 5444 or not? > - what is the version number; what is the distinction between major and m= inor numbers? > - can messages mix optional TLVs with mandatory, reliable TLVs? Is TLV o= rdering to be enforced? > etc. > > I'd suggest that the working group focus first on writing down and agreei= ng upon some requirements and detailed protocol just to cover the session s= tate aspects, such that it would be really hard to come up with implementat= ions that did not interoperate at that level. Then move on to the radio-sp= ecific TLVs and issues there. > > This kind of protocol has been done before and (I've suggested this in th= e past) it may be more efficient to try to reuse/adapt an existing protocol= (LCP and X.25 come to mind). This protocol may seem simple but when one s= tarts to deal with issues such as race conditions, state misalignment (one = side reboots and the other side doesn't detect it), notifications of errors= to the peer, parameter negotiations, multiple devices on link, etc. one ge= ts into issues that lead to interoperability and robustness problems. > > - Tom > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 15 Oct 2012 18:06:49 -0700 > From: "Charles E. Perkins" > To: "'manet@ietf.org'" > Cc: "Henderson, Thomas R" > Subject: Re: [manet] suggestions for further DLEP development > Message-ID: <507CB329.8010508@computer.org> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > > Hello folks, > > Just one comment... > > On 10/15/2012 5:22 PM, Henderson, Thomas R wrote: >> It was previously suggested to use the tracker to document these issues = and their wrapup/conclusion, an idea that I offer +1 to, but if the WG choo= ses to not use the tracker, perhaps some kind of informal convention could = be adopted such as posting to the list with a clear subject such as "Decisi= on on RFC 5444 issue for DLEP". I'd also be in favor of recording this in = a change log in the draft, for that matter, but I would be happy with just = using an issue tracker or summary messages on the list if the authors do no= t want to use the draft this way. > > For any draft with contentious issues, I think that the issue tracker > ought to > be considered a "must", and the change log is even more of a "must". > > It really helps to avoid going around in circles. > > I also agree that it is very helpful to use more descriptive "Subject:" > lines, > but it is not so easy to remember to do that. > > -- > Regards, > Charlie P. > > > > ------------------------------ > > Message: 4 > Date: Tue, 16 Oct 2012 10:19:39 +0530 > From: Pr > To: manet@ietf.org > Subject: [manet] INTERFERENCE POWER > Message-ID: > > Content-Type: text/plain; charset=3D"iso-8859-1" > >> >> is there any formula to calculate noise >> power based on transmitter power or receiver >> power or based on distance between them? >> I saw a formula in mathworks.in website >> while generally searcing in google which is: >> interference power=3Dtransmission power-signal power-noise power. >> Is this a basic formula or derived from any other formula? >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 5 > Date: Tue, 16 Oct 2012 07:17:25 +0200 > From: Henning Rogge > To: > Subject: Re: [manet] INTERFERENCE POWER > Message-ID: <507CEDE5.9080800@fkie.fraunhofer.de> > Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed" > > On 10/16/2012 06:49 AM, Pr wrote: >> is there any formula to calculate noise >> power based on transmitter power or receiver >> power or based on distance between them? >> I saw a formula in mathworks.in website >> while generally searcing in google which is: >> interference power=3Dtransmission power-signal power-noise power. >> Is this a basic formula or derived from any other formula? > > I think this highly depends on your model of the radio propagation. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra?e 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 6169 bytes > Desc: S/MIME Cryptographic Signature > URL: > > ------------------------------ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > End of manet Digest, Vol 101, Issue 87 > ************************************** --=20 Thanking You. best wishes and regards, yours sincerely, Srinivas.Kanakala Assistant Professor Department of Computer Science Vaagdevi College of Engineering www.vagdevieng.com Warangal,AndhraPradesh,INDIA-506002 contact no:91-9966343560 All the power is with in u,u can do any thing and every thing From jvasseur@cisco.com Tue Oct 16 00:37:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F22621F8806 for ; Tue, 16 Oct 2012 00:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKv4mqKjYgs1 for ; Tue, 16 Oct 2012 00:37:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB021F879B for ; Tue, 16 Oct 2012 00:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2358; q=dns/txt; s=iport; t=1350373032; x=1351582632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4099EL78R+yHeZh3aI3p19qdQo3xfFeRWB4+x3OubFQ=; b=Y5xOE4fL+aTDuBgt4vkxHFBr34CWdIZoeNRF8bjdLA1iDEsuc4QGFU61 nZtVeyaRB153VfSdaOp4F6iYHD7hIBJF0osFV0SH9X5Q0DJz6tM/oQa9g jbIuXVSjJHsHqNxKkSiVV6ee4Hp0oAfAcO7fw8oeSYvgN4e6cTZx65ugA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPsNfVCtJXHA/2dsb2JhbABFwBKBCIIgAQEBAwEBAQEPAVsLBQsCAQgYCh0HJwsUEQIEDgUIGodcBgubK49akGCLR4VdYAOXAI0wgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="131987031" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 16 Oct 2012 07:37:11 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9G7bBh5013374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 07:37:11 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 02:37:11 -0500 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Tue, 16 Oct 2012 07:37:10 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE77E3@xmb-rcd-x02.cisco.com> References: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> <507CF076.80809@fkie.fraunhofer.de> In-Reply-To: <507CF076.80809@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--53.381700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <0E0683DEFB9AF043B67098EFD4706723@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 07:37:13 -0000 Hi, On Oct 16, 2012, at 7:28 AM, Henning Rogge wrote: > On 10/15/2012 09:35 PM, JP Vasseur (jvasseur) wrote: >> LLN is a combination of well-known constrained though: lossy links, low = bandwidth and constrained nodes. >> This is that unique combination >=20 > No, it is not unique. >=20 > Its also the default description of MANET/MESH. JP> OK let's not argue further, this will not help. >=20 > > that makes it difficult and that justified forming a new WG at the IETF= (ROLL). >> Does that make sense ? >=20 > ROLL looks (mostly) into Zigbee based stationary networks. JP> This is completely incorrect. Being a co-chair of ROLL for the past 4+ = years, you may not have followed our work, but although Zigbee/IP is using RPL in one of its modes of operation, ROLL is not mostly into Zigb= ee at all. As a matter of fact, most of the RPL-based networks are outdoor large meshes using in smart cities and start metering to mention a = few examples, using 15.4g but also PLC P1901.2, with high variation of ETX. > This are reasonable fast networks and one of the basic assumptions of of = ROLL seems to be that the link quality doesn't change that much over time (= an assumption that makes sense because of the lack of mobility). >=20 JP> Again incorrect. ETX is *not* stable because of the lack of mobility. P= lease loos at http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deploym= ent-01 Figure 3. I could show you deployed networks with an ETX varying from 1 to = 2.5 within a 24-hour period ! > This is a part of the "problem space" MANET looks into... similar to the = fact that some MANET protocols are just normal routing protocols that have = been optimized for less stable links. JP> Hopefully I did clarify =85 you had a wrong perception of ROLL and LLNs= . JP. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From c.chauvenet@watteco.com Tue Oct 16 01:14:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7382F21F87A9 for ; Tue, 16 Oct 2012 01:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkbSJ+l0mY08 for ; Tue, 16 Oct 2012 01:14:33 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id A846D21F87A7 for ; Tue, 16 Oct 2012 01:14:32 -0700 (PDT) Received: from mail27-db3-R.bigfish.com (10.3.81.241) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 08:14:29 +0000 Received: from mail27-db3 (localhost [127.0.0.1]) by mail27-db3-R.bigfish.com (Postfix) with ESMTP id 5950C4A0136; Tue, 16 Oct 2012 08:14:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic89bh1432Izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h946hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail27-db3 (localhost.localdomain [127.0.0.1]) by mail27-db3 (MessageSwitch) id 1350375266855501_17558; Tue, 16 Oct 2012 08:14:26 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.254]) by mail27-db3.bigfish.com (Postfix) with ESMTP id CDFE580050; Tue, 16 Oct 2012 08:14:26 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 08:14:26 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0207.009; Tue, 16 Oct 2012 08:14:26 +0000 From: C Chauvenet To: "JP Vasseur (jvasseur)" Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAIAAdJeAgABi3ICAAIeagIABJjmAgAAaN4CAAAU/gIAALqGAgAAQl4CAAAHxAIAAAlsAgAABOACAADYmAIAAAkoAgAAY/ICAAKWOAIAAI/0AgAAKZwA= Date: Tue, 16 Oct 2012 08:14:25 +0000 Message-ID: References: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> <507CF076.80809@fkie.fraunhofer.de> <03B78081B371D44390ED6E7BADBB4A7721FE77E3@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE77E3@xmb-rcd-x02.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6391F84B24FF464F9465D6E57F9D97D0@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:14:37 -0000 Hi Henning,=20 Le 16 oct. 2012 =E0 09:37, JP Vasseur (jvasseur) a =E9crit : > Hi, >=20 > On Oct 16, 2012, at 7:28 AM, Henning Rogge wrote: >=20 >> On 10/15/2012 09:35 PM, JP Vasseur (jvasseur) wrote: >>> LLN is a combination of well-known constrained though: lossy links, low= bandwidth and constrained nodes. >>> This is that unique combination >>=20 >> No, it is not unique. >>=20 >> Its also the default description of MANET/MESH. >=20 > JP> OK let's not argue further, this will not help. >=20 >>=20 >>> that makes it difficult and that justified forming a new WG at the IETF= (ROLL). >>> Does that make sense ? >>=20 >> ROLL looks (mostly) into Zigbee based stationary networks. >=20 > JP> This is completely incorrect. Being a co-chair of ROLL for the past 4= + years, you may not have followed our work, but although Zigbee/IP > is using RPL in one of its modes of operation, ROLL is not mostly into Zi= gbee at all. As a matter of fact, most of the RPL-based networks are > outdoor large meshes using in smart cities and start metering to mention = a few examples, using 15.4g but also PLC P1901.2, with high variation > of ETX. Just stress on this fundamental point for people that do not follow ROLL : = LLNs is not restricted to zigbee at all ! >=20 >> This are reasonable fast networks and one of the basic assumptions of of= ROLL seems to be that the link quality doesn't change that much over time = (an assumption that makes sense because of the lack of mobility). Again, for your information, and as mentioned earlier on this list, No_Mobi= lity !=3D Stable links. I'm working on 15.4 and PLC solutions, and PLC is a perfect example : PLC (= indeed) don't move but present a high dynamic behavior because of the elect= rical activity on the grid. I don't know what is "fast" for you, but PLC can go down to a few kbps in r= obust mode when conditions are harsh. Also, for RF solution, low throughput induce longer range that can be suita= ble for LLNs deployments. A concrete example to show this: Engineers from TI have reached an 7 km ran= ge using their CC1120 transceiver using a throughput of ... 1,2 kbps ! I think such high constraints cannot be handle by a routing protocol that d= o not consider LLNs in its former scope. C=E9dric. >>=20 >=20 > JP> Again incorrect. ETX is *not* stable because of the lack of mobility.= Please loos at http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deplo= yment-01 > Figure 3. I could show you deployed networks with an ETX varying from 1 t= o 2.5 within a 24-hour period ! >=20 >> This is a part of the "problem space" MANET looks into... similar to the= fact that some MANET protocols are just normal routing protocols that have= been optimized for less stable links. >=20 > JP> Hopefully I did clarify =85 you had a wrong perception of ROLL and LL= Ns. >=20 > JP. >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From abdussalambaryun@gmail.com Tue Oct 16 02:27:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC4421F8868 for ; Tue, 16 Oct 2012 02:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDVPs4NnkB2v for ; Tue, 16 Oct 2012 02:27:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97921F8865 for ; Tue, 16 Oct 2012 02:27:42 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so7534786vcb.31 for ; Tue, 16 Oct 2012 02:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vd44wHgf5hL/RVzM5gg/Y+YIgNFO81xtm1+7y1tZeFU=; b=O3Z8hHpF/IKlCoHNygOSasOvnOAOutoUkU6UPcEw3Qz9FkMIxAHT8HRVMmh5Ldl+G6 9bMdWhvQyNb7YIAwqpWdi40hk/HzA/zN0chovLhtEHYipwZiBPyW65XAYWlRx1SMV/NU CEQN72xDTyHWiwIZQpKk9imtOl78a2L2JGcf3Pe/l9+JAgdmfS8iefVwTGU/kZXOGlKK KtwimgG+hDeuI3+8/Wd4xMttskw0YkkkTxI7x/m5jUI1cuPsoXW0wahRBCN0oKmqzPen stOUoZ8lzKPeQJ/EbPfKg1xA2igMruRWSp9QCBrr+8IMyXHV9DvqagaCAAXcGXfZjIfH bhuA== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr8309918vca.14.1350379661523; Tue, 16 Oct 2012 02:27:41 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 02:27:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Oct 2012 11:27:41 +0200 Message-ID: From: Abdussalam Baryun To: Pr Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] INTERFERENCE POWER X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:27:43 -0000 On 10/16/12, Pr wrote: >> >> is there any formula to calculate noise >> power based on transmitter power or receiver >> power or based on distance between them? >> I saw a formula in mathworks.in website >> while generally searcing in google which is: >> interference power=transmission power-signal power-noise power. >> Is this a basic formula or derived from any other formula? It is a wrong formula, please notice that interference is the receiver problem not the transmitter problem. The ITU have presented the answer formulas, but IETF does not, because they are maybe out of scope. AB >> > From abdussalambaryun@gmail.com Tue Oct 16 02:44:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFFE21F880B for ; Tue, 16 Oct 2012 02:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICnmazk0aGvC for ; Tue, 16 Oct 2012 02:44:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB36C21F87FB for ; Tue, 16 Oct 2012 02:44:42 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so7552574vcb.31 for ; Tue, 16 Oct 2012 02:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2VZK1/R1OZ+cn5BjTqhLucwacxE/Ee5j59u2yBAQnWM=; b=sH47bQUGF6O5uEacUDpLCkE/J8zyKRyiFB6mBaZgeIQda4MCLVTYMZge5QpaM2fMPK nU2TYDBU6q9SeZmlVqbd3R6mV+mLMV1apqsQWT6wQVFIcF+BoJ4q9auVNfUygCCKagFD MfDJQwWxDiDYxMlNTno+ATzyOYenuvPlAur83xMXmdeZodqfnF3yAFk42B7fHlXsE9hT Cl8js3qZ2C0PuKglbG3XMNhQcZ/aT2OR27G6w2a0U0O9weK36Jh3CaJJV0xMxdhKRmjm 4njXpznZszdogFy4iINvfzKR/iauyjiCjHCeU4rPsFpzu3mOsE+YoQ7iUFztp1ZltPnx m/GA== MIME-Version: 1.0 Received: by 10.220.154.68 with SMTP id n4mr8343538vcw.22.1350380682270; Tue, 16 Oct 2012 02:44:42 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 02:44:42 -0700 (PDT) Date: Tue, 16 Oct 2012 11:44:42 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: [manet] Lossy MANET (LMANET) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:44:43 -0000 Hi Henning, comments in line On 10/15/12, Henning Rogge wrote: >> I call thoes: Lossy MANET = LMANET > > Has there ever been a MANET without lossy links, except for the ones > in simulation (NS2, wifi, tworay-ground)? It depends how you define *link* some define it as the wireless interface, so Yes some times there is a possibility of *Lossy Link*, but if you define *link* as the wireless medium then your right all wireless-links are lossy. There are difference between Lossy MANET, and Lossy MANET-Links. Also it depends how the *Routers* define such *links*. MANET-Links may be logical links or physical links, both can be lossy or not. IMO, AODVv2 and OLSRv2 have logical links not physical. AB > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From abdussalambaryun@gmail.com Tue Oct 16 02:55:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5413021F8848 for ; Tue, 16 Oct 2012 02:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAgtUYvVmeOq for ; Tue, 16 Oct 2012 02:55:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8E921F8846 for ; Tue, 16 Oct 2012 02:55:52 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6989222vbb.31 for ; Tue, 16 Oct 2012 02:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=21p7pu4ztbi6chO7l9XHnYB2PF7lHJFJ8slFxbQCGW8=; b=oGNQfTHDgJS8dQdeZvN8Esp4z12qKRcjq6mDYlaeWAZh1sMgM8FchgIioxDdJw9GWq H/g/R59MX2p5Wov0edZgwBeIo3yb1xvvigxLa3D+3GG4HCL56Fhjg85BVIp5Lo3IHw0v Go+CYR896NvF/UJWnyU644GVRj8oz0YeniYkWyGYPFZAvFfdWNvCGAN4ygzWc409P4CJ ckgjQqpfXFcORI1em1lltvr5wCSTXyp7hvMhgmG0S5ZRI1+TR03rV9bDOixCfGaBGySA jj84dxZ/JcO9f10kPPATzfIZPX9Jb9YXWteuNYZCHdOPnZF3qWsiaNptE4C+A59C5xqS yRWg== MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr8390887vec.51.1350381352083; Tue, 16 Oct 2012 02:55:52 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 02:55:50 -0700 (PDT) In-Reply-To: <507CF076.80809@fkie.fraunhofer.de> References: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> <507CF076.80809@fkie.fraunhofer.de> Date: Tue, 16 Oct 2012 11:55:50 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:55:58 -0000 I understand you ment that ROLL looks also in similar applications of Zigbee as Home Networks. However, Zigbee is standard for another organisation, but IETF does not standard that, IMHO, we don't discuss *Zigbee standards* in IETF WGs, but we may discuss how to interoperate MANETs or LLNs with Zigbee-Internet technologies. AB +++ On 10/16/12, Henning Rogge wrote: > Its also the default description of MANET/MESH. > > > that makes it difficult and that justified forming a new WG at the > IETF (ROLL). >> Does that make sense ? > > ROLL looks (mostly) into Zigbee based stationary networks. This are > reasonable fast networks and one of the basic assumptions of of ROLL > seems to be that the link quality doesn't change that much over time (an > assumption that makes sense because of the lack of mobility). > > This is a part of the "problem space" MANET looks into... similar to the > fact that some MANET protocols are just normal routing protocols that > have been optimized for less stable links. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From abdussalambaryun@gmail.com Tue Oct 16 03:09:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3221F87CB for ; Tue, 16 Oct 2012 03:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P0ig3nQw+6o for ; Tue, 16 Oct 2012 03:09:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECF021F87BA for ; Tue, 16 Oct 2012 03:09:33 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7003315vbb.31 for ; Tue, 16 Oct 2012 03:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1hixQnhruDPgllbgAtAKcik1Y46z/GFuMOUaSO6za/U=; b=V3iA/Hz4CmgnT+MPEM9nbZbUPm/SRo02BjP6Syo/sB+QRNIowcOM7JxC2OtnAoYQEz dI6Suj2MP+IVbjdB0gBgdVa6pmBtj7NdrCxBLRGF98EJeqEbTHSoGa2SRjoRBkiHnNcD ZP9d9GuurBPMKX19ORdSvf8ZQA6kOmxxxLbqCD2c5gb4yhnxNKWBI3dHCjzskzaVVfyy 3cdGhI8S1mtDdzi7mjhM6hNG18lzSAF83bYcK8U45I18JYNbYcjcdofmVUai9XmcrZhW /UE6G/8G8fhNdOlV15AsU8RnoiQQVxumWO+uzWHqq9XzxAbY3vBxwVtkBFnjbWcV8bDt gwPw== MIME-Version: 1.0 Received: by 10.58.189.72 with SMTP id gg8mr662734vec.20.1350382172508; Tue, 16 Oct 2012 03:09:32 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 03:09:32 -0700 (PDT) In-Reply-To: <507CB329.8010508@computer.org> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507CB329.8010508@computer.org> Date: Tue, 16 Oct 2012 12:09:32 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: "Henderson, Thomas R" Subject: Re: [manet] suggestions for further DLEP development X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:09:33 -0000 I agree totally that we need to make clear decisions with the subjects/questions you mentioned. I already was trying many time to remind the DLEP authors about this, and there was some comments not responded when the new -03 version came out. Please note that I already was doing that if you may refer to my history in the MANET WG, and will recommend all to do the same. IMHO, the problem is that the MANET WG mostly depends on making its decisions in the Face-to-Face meeting, more than making them in the Discussion list, which I disagree. Further more, in the last meeting the WG did not give some reflection about the Discussion List which I RECOMMEND that we do in the future, for the progress and reminder purposes. AB On 10/16/12, Charles E. Perkins wrote: > > Hello folks, > > Just one comment... > > On 10/15/2012 5:22 PM, Henderson, Thomas R wrote: >> It was previously suggested to use the tracker to document these issues >> and their wrapup/conclusion, an idea that I offer +1 to, but if the WG >> chooses to not use the tracker, perhaps some kind of informal convention >> could be adopted such as posting to the list with a clear subject such as >> "Decision on RFC 5444 issue for DLEP". I'd also be in favor of recording >> this in a change log in the draft, for that matter, but I would be happy >> with just using an issue tracker or summary messages on the list if the >> authors do not want to use the draft this way. > > For any draft with contentious issues, I think that the issue tracker > ought to > be considered a "must", and the change log is even more of a "must". > > It really helps to avoid going around in circles. > > I also agree that it is very helpful to use more descriptive "Subject:" > lines, > but it is not so easy to remember to do that. > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From jvasseur@cisco.com Tue Oct 16 03:16:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D52221F87F4 for ; Tue, 16 Oct 2012 03:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZIKVEJK6ZhU for ; Tue, 16 Oct 2012 03:16:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B2E7C21F87EE for ; Tue, 16 Oct 2012 03:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1755; q=dns/txt; s=iport; t=1350382605; x=1351592205; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MByxmeJhzE+5r6aC6d4bir6L7NHZfAIEwHK1mtNIP14=; b=OmX77IAcHLbs9ctFuLdUv91laELFt72p3Et1E9CxkweGCj8Ydg1+JGrn ZnpDpwFaD5Fi3GfnT671XthIOvhq3/1Roe+sImZ+tDh8Fu5rd8TYzMGEn 8lRK+D+BjosrbhrI1kxGM5rQCsi/7fTWZUiTHXePPlKcr/p7h6ACzLeaA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE0zfVCtJV2d/2dsb2JhbABFwAuBCIIgAQEBAwEBAQEPAVsLBQsCAQgYCh0HJwsUEQIEDgUIGodcBgubPo9akFyLR4VdYAOII5wNgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="132025064" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 16 Oct 2012 10:16:45 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9GAGj97015457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 10:16:45 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 05:16:44 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Tue, 16 Oct 2012 10:16:44 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE8510@xmb-rcd-x02.cisco.com> References: <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> <507CF076.80809@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--37.380600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <45DA347406DE30449CA3AE43D2625B7E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:16:49 -0000 On Oct 16, 2012, at 11:55 AM, Abdussalam Baryun wrote: > I understand you ment that ROLL looks also in similar applications of > Zigbee as Home Networks. However, Zigbee is standard for another > organisation, but IETF does not standard that, IMHO, we don't discuss > *Zigbee standards* in IETF WGs, but we may discuss how to interoperate > MANETs or LLNs with Zigbee-Internet technologies. Not even so, Zigbee chose several IETF protocols. >=20 > AB > +++ > On 10/16/12, Henning Rogge wrote: >> Its also the default description of MANET/MESH. >>=20 >>> that makes it difficult and that justified forming a new WG at the >> IETF (ROLL). >>> Does that make sense ? >>=20 >> ROLL looks (mostly) into Zigbee based stationary networks. This are >> reasonable fast networks and one of the basic assumptions of of ROLL >> seems to be that the link quality doesn't change that much over time (an >> assumption that makes sense because of the lack of mobility). >>=20 >> This is a part of the "problem space" MANET looks into... similar to the >> fact that some MANET protocols are just normal routing protocols that >> have been optimized for less stable links. >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Tue Oct 16 03:29:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8621F88B7 for ; Tue, 16 Oct 2012 03:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tjkF+Gi15CN for ; Tue, 16 Oct 2012 03:29:50 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61C0021F88B1 for ; Tue, 16 Oct 2012 03:29:50 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7023693vbb.31 for ; Tue, 16 Oct 2012 03:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=INktoDx7y8J2TyCuMjmGYrtiv8XKRcd9YzfmcLF4Qpo=; b=vMCJdo9ge7053pD7CZPYovkQtG43VQtaTuomtNO10Rou1N9Afh1S6cg7cJlGcCLvKA XK0Dk6+xP8N/0VLybAMelxFUEeDHYf71VmTm4ABHRBs5jVx44/tauhiD51XIEigGnpDO Kcd8dbZ+iayiYTBbPHLNq6Ez6i2NApRZu2ethYtEuFGI5z9K+cLq+uVW05Y222it1Vk3 6o+F1fgn/YbsxGrqkDv3PDMJiVP7Z6OY9/u0I3PpRZXEuy3NPNu9IZ0usgtYOgwfMvGx w4IOq+ms19t5fecBZTc6wxiktnvNNSE6YNZGHmoa14Qy2zjfwbre5hqQdMlcEoBh3w5m AM5Q== MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr8435732vec.51.1350383389881; Tue, 16 Oct 2012 03:29:49 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 03:29:49 -0700 (PDT) Date: Tue, 16 Oct 2012 12:29:49 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: [manet] IETF WG Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:29:51 -0000 Hi Ulrich, I agree that the Chair is doing a greate job and I never doubted that, but I was saying that in any meetings in the world they do minutes, and the procedure is to prepare it and then agree or disagree on it because the minute is representing the relavent discussions, not every thing that was said. However, I will leave this issue to the Chair to decide because I was not in the last meeting. I am not sure if the IETF procedure does not give authority to WG participants to agree or disagree on minutes, which if it does I will feel it is a little strange from world best practice. AB On 10/15/12, Ulrich Herberg wrote: > Hi AB, > > On Mon, Oct 15, 2012 at 11:01 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> I will check it again as well, but as you said it is out of scope to >> MANET >> WG to discuss LLN or RPL, then the draft refered to was out of scope and >> we >> as MANET WG should take it out of the minutes and delet any noise. >> > > Absolutely not. The minutes reflect what has been said. You may not agree > with what has been discussed in the meeting; it is the chairs' > responsibility to lead the WG meeting and to decide whether discussions are > relevant. And I think they do a great job. It is the minute-takers job to > reflect as accurately as possible what has been said in the meeting. > > > >> >> Please note that the minutes should be called consensus before approved. >> > > This is a question to the chairs, so I won't answer here. Just that: Do you > have any concrete item that you believe has not been represented correctly? > > Best > Ulrich > > >> >> AB >> >> On Mon, Oct 15, 2012 at 4:33 PM, Ulrich Herberg >> wrote: >> >>> Hi AB, >>> >>> On Mon, Oct 15, 2012 at 1:55 AM, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> [...] >>>> >>> >>>> If you read the minutes of MANET WG meeting IETF84 [1] you will find >>>> there was a discussion, my input was only a reflection. Please note >>>> that refering to I-D [2] was in the minutes which I agree that we >>>> SHOULD delete from our MANET minutes because it is another *overalp* >>>> (I don't beleive that the I-D name was pronounced in the meeting but >>>> the minute writter prefered to advertise the name). >>>> >>>> I RECOMMEND the Chair of MANET to delete the name of RPL experience >>>> I-D from the minutes because it is/was note said just indicated such >>>> as draft not named. >>>> >>> >>> >>> I strongly disagree. I have listened to the audio again. Thomas Clausen >>> clearly named the moniker of the draft. The minutes are supposed to >>> reflect >>> what has been said in the meeting. >>> >>> >>> [...] >>> >>> Best >>> Ulrich >>> >> >> > From abdussalambaryun@gmail.com Tue Oct 16 03:51:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5D21F8897 for ; Tue, 16 Oct 2012 03:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8GLqAVL1d51 for ; Tue, 16 Oct 2012 03:51:52 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86AEA21F87B5 for ; Tue, 16 Oct 2012 03:51:52 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7045438vbb.31 for ; Tue, 16 Oct 2012 03:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=H3cn5978fpKYFlY78DXt9uwiRdFM4iSrIlrsUbTpKS4=; b=fKNiONPl2VCHB8LHPn+t7FAT+3QVbl0cZrSfYb4HfE/7zrvIv1I/98korEwH5EoNwC xNd9gq0oArm1NitUlwhiZ8V1Ai1I0Sh7RuEnkyvqrrv8jJO03cFYvVCq7JavDUv8CZ7T zrOxlAt5mcOh0NZLxiUFa0sTiQPUEw/0vB27W1sFIB3PIHoCzxd1rw0q2+fQYI/G0txY e5pwydlIvzr99TqKb6AflQepIpcRXsOr+EW7footXEUBWE0CfmntF30iwBfR/51RpQF9 jpZVwVCkkxE8df48lklVLsf8rO0hGKA0cOBlsLifI2Zk60fxguex/I/8C6EAplWt+3TK YWfA== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr6832403vdj.99.1350384711668; Tue, 16 Oct 2012 03:51:51 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 03:51:51 -0700 (PDT) Date: Tue, 16 Oct 2012 12:51:51 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: [manet] DLEP: How RADIO side produce the information for the MANET router? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:51:53 -0000 Hi Henning, I agree with Martin, Router process is out of scope in DLEP. However, understand your concerns which are important. > Otherwise the router will not be sure what the > information means. I think that will be the routers problem, which the user or router-developer should solve. We can see it with DLEP eyes: Will the RADIO be sure about the router information needed? Do we make DLEP for specific routers (AODVv2 or OLSRv2). I agree with not specific to such router. AB On 10/15/12, Henning Rogge wrote: > On Mon, Oct 15, 2012 at 4:10 PM, Duke, Martin > wrote: >> The reason I haven't responded to this request is because I haven't been >> able to find anywhere in the draft that instructs the router on how to >> handle ANY of these metrics- RLQ, Latency, whatever. In fact, I thought >> the way the router used information about the radio was out of scope for >> this draft. > > I still think we need rules how the RADIO side produce the > information. Otherwise the router will not be sure what the > information means. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From henning.rogge@fkie.fraunhofer.de Tue Oct 16 03:57:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534AF21F8819 for ; Tue, 16 Oct 2012 03:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEMUWEn4Ckdi for ; Tue, 16 Oct 2012 03:57:00 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 42C8D21F88B2 for ; Tue, 16 Oct 2012 03:57:00 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TO4pX-0001td-Jy for manet@ietf.org; Tue, 16 Oct 2012 12:56:59 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TO4pX-0004xR-HO for manet@ietf.org; Tue, 16 Oct 2012 12:56:59 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Oct 2012 12:56:59 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 16 Oct 2012 12:56:59 +0200 Message-ID: <507D3D75.4050606@fkie.fraunhofer.de> Date: Tue, 16 Oct 2012 12:56:53 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050809040405060602090800" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 16 Oct 2012 10:56:59.0360 (UTC) FILETIME=[F7223E00:01CDAB8C] X-Virus-Scanned: yes (ClamAV 0.97.5/15465/Tue Oct 16 12:00:29 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Subject: Re: [manet] DLEP: How RADIO side produce the information for the MANET router? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:57:01 -0000 --------------ms050809040405060602090800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/16/2012 12:51 PM, Abdussalam Baryun wrote: > Hi Henning, > > I agree with Martin, Router process is out of scope in DLEP. However, > understand your concerns which are important. > >> Otherwise the router will not be sure what the >> information means. > > I think that will be the routers problem, which the user or > router-developer should solve. We can see it with DLEP eyes: Will the > RADIO be sure about the router information needed? Do we make DLEP for > specific routers (AODVv2 or OLSRv2). I agree with not specific to such > router. If the radio is allowed to produce the same output to the router for=20 different input, the router cannot compensate for this. How shall a=20 router implementation drop a link which the radio does know nothing=20 about if the radio just signals "link is perfect". That is why I am also interested in more "raw data" metric TLVs. Just have a look at all the data you can get from a modern Linux wifi car= d. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050809040405060602090800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTYxMDU2NTdaMCMGCSqGSIb3DQEJBDEWBBTIrPWFOZDLaQorVqKusbDIf9oAWDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEACGeOSZcZ39IRjmFx/r/uRRbIEr40wH+4x6wi7MlhZpLj xCCy+T93V7GkjICVyvGwgxWWsLiDiJ7c2e+1H+gllhI71R+nlHFWb9V8TIr4yKcAxeB+mRl0 S3dkhtei/O9XmCgMAG/i0f8tidSK1jxLaXhLn6aKwfCqB9pGBELQRPWgZPShuPr/TZErQM5s H1V5PITcIGFYju8SZP9x7Rbn0EAOaw/C/n4pyat/RIIUJYbBh+M314c3Ml2ge4KvHHnBHqVM OvdUUKaloM47ftQU2zLGupNgvhF5Hn6i5XUCJC/itLccEKVjLFuWcV5uK5c5wT8EYPqR4avx 9HCvVjtT2gAAAAAAAA== --------------ms050809040405060602090800-- From henning.rogge@fkie.fraunhofer.de Tue Oct 16 05:41:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9CC21F894F for ; Tue, 16 Oct 2012 05:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaIeTT9qH8qc for ; Tue, 16 Oct 2012 05:41:56 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 3467121F8806 for ; Tue, 16 Oct 2012 05:41:56 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TO6T5-00045k-IC for manet@ietf.org; Tue, 16 Oct 2012 14:41:55 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TO6T5-00080C-Fb for manet@ietf.org; Tue, 16 Oct 2012 14:41:55 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Oct 2012 14:41:55 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 16 Oct 2012 14:41:54 +0200 Message-ID: <507D5611.2060303@fkie.fraunhofer.de> Date: Tue, 16 Oct 2012 14:41:53 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090907030707070504070001" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 16 Oct 2012 12:41:55.0260 (UTC) FILETIME=[9FC857C0:01CDAB9B] X-Virus-Scanned: yes (ClamAV 0.97.5/15465/Tue Oct 16 12:00:29 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Subject: Re: [manet] INTERFERENCE POWER X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 12:41:57 -0000 --------------ms090907030707070504070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/16/2012 11:27 AM, Abdussalam Baryun wrote: > On 10/16/12, Pr wrote: >>> >>> is there any formula to calculate noise >>> power based on transmitter power or receiver >>> power or based on distance between them? >>> I saw a formula in mathworks.in website >>> while generally searcing in google which is: >>> interference power=3Dtransmission power-signal power-noise power. >>> Is this a basic formula or derived from any other formula? > > It is a wrong formula, please notice that interference is the receiver > problem not the transmitter problem. The ITU have presented the answer > formulas, but IETF does not, because they are maybe out of scope. There is no generic or "right" way to calculate the noise floor level,=20 it depends on the model you are using to describe your environment. Most = existing formulas have a limited scope, especially for their environment = and frequency. If you have a link to a good model, it would help to post it here. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090907030707070504070001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTYxMjQxNTNaMCMGCSqGSIb3DQEJBDEWBBTRkSYgzg2cX66JGKzK2JShJ30zdjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAgtxDtEYqx4v/YNmAuGaA9xijL0jxm8axUesJSPgzUKot SuhpFcM9eNwl/tTp+bkzkYcdynx2eHwz/dI8kWHvYCkHJuV/N3nUYzgi3lzpI+YCaXg7VjBx 0s8KExOhX9eUmmbo+k4Zv4/kSYc2LRERkfZGthgVffP7JgPvYdJ5VRvmT3dSmeWtFNtmo3OR o0rX1ccNS0zOboLSXEyNapC/LUFFrjS31egfs+YNKZABgMEIPza9CaHBd+DMjUzwUE4cI7no zGfBMeV9AJQcD/vDwBYmidst783waszRJCp+jWxyRcmdgvMzqS/hmhNJ52R/9j0+0vPWh5kI pTPIonGCIwAAAAAAAA== --------------ms090907030707070504070001-- From ppcs2214@gmail.com Tue Oct 16 06:55:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC4221F8810 for ; Tue, 16 Oct 2012 06:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTuOQV-E7G2t for ; Tue, 16 Oct 2012 06:55:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49B5C21F880D for ; Tue, 16 Oct 2012 06:55:52 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so5714504qcg.31 for ; Tue, 16 Oct 2012 06:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PgmZkcdDr/SjpTdjM7XBqoPwZ3yd915J2QVRfLBWYBA=; b=fqT+oWf7cYu9Jn8vjMLYwJsGvddI8kPZiKCbj5evvGAUBHSLlRYnCUS4L4Jb69HOPI oHjff86P7P6u0SxVUzUHsvHiOUZY5NXT2YEPfJ4sYAdx3vhbdsDjwmqdCIXH0noGyPZB ZEuGc8z3EReyUmQTcac5c4REZPiYeNnqrnk+8h5JNcjsXaSwtuK7dfA62Nm4MtuwfXrO m58UnGB8P0y0w9RUXKNUs/9HQqZ2dAgi9ZHDvNDbcOkQZHvdVl4ZYC1bzBRUsDmwdBXh IVTkh3/EJrNQNS262YG3HI7Yk25Bf25oH/w6Bx4PdUQqfiA/V4l1tlaiJPtjk9nR1V/Y 4WvQ== MIME-Version: 1.0 Received: by 10.224.109.199 with SMTP id k7mr11537245qap.66.1350395751720; Tue, 16 Oct 2012 06:55:51 -0700 (PDT) Received: by 10.49.85.38 with HTTP; Tue, 16 Oct 2012 06:55:51 -0700 (PDT) Date: Tue, 16 Oct 2012 19:25:51 +0530 Message-ID: From: Pr To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf3074b3cc16684204cc2d8304 Subject: [manet] Interference power X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 13:55:53 -0000 --20cf3074b3cc16684204cc2d8304 Content-Type: text/plain; charset=ISO-8859-1 I need formula to calculate Interference power at a node in manet (due to interference from neighbour nodes). Environment is two tay ground model.... --20cf3074b3cc16684204cc2d8304 Content-Type: text/html; charset=ISO-8859-1
I need formula to calculate Interference power
at a node in manet (due to interference from neighbour nodes). Environment is two tay ground model....
--20cf3074b3cc16684204cc2d8304-- From cedric-2.lavenu@edf.fr Tue Oct 16 09:58:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A976521F8484 for ; Tue, 16 Oct 2012 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.148 X-Spam-Level: X-Spam-Status: No, score=-7.148 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnYjQQf+oGLh for ; Tue, 16 Oct 2012 09:58:41 -0700 (PDT) Received: from mtagate1.edf.fr (mtagate1.edf.fr [192.54.193.60]) by ietfa.amsl.com (Postfix) with ESMTP id EA1C321F847F for ; Tue, 16 Oct 2012 09:58:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,595,1344204000"; d="scan'208,145,147";a="399170842" Received: from unknown (HELO XHUB003AU.notes.edfgdf.fr) ([10.122.19.74]) by CLAF1MTA1.edf.fr with ESMTP; 16 Oct 2012 18:47:45 +0200 In-Reply-To: <50A05995-EE7B-44DA-B157-B83D62FE2E6C@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> To: c.chauvenet@watteco.com MIME-Version: 1.0 X-KeepSent: 68FDD132:42A36B60-C1257A99:005B8408; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF142 March 12, 2011 From: Cedric-2 LAVENU Message-ID: Date: Tue, 16 Oct 2012 18:58:32 +0200 Content-Type: multipart/related; boundary="=_related 005D40A9C1257A99_=" Cc: Chris.Dearlove@baesystems.com, manet@ietf.org, boberry@cisco.com, sratliff@cisco.com Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:58:42 -0000 Message en plusieurs parties au format MIME --=_related 005D40A9C1257A99_= Content-Type: multipart/alternative; boundary="=_alternative 005D40A9C1257A99_=" --=_alternative 005D40A9C1257A99_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDw6lkcmljLA0KDQpJJ20gbm90IHN1cmUgYWxsIHRoaXMgZGlzY3Vzc2lvbnMgcmVhbGx5 IG1ha2Ugc2Vuc2UgOg0KDQo+IEFuIExMTiBuZXR3b3JrIGlzIGRlZmluaXRlbHkgYSB0eXBlIG9m IE1BTkVUIGFjY29yZGluZyB0byB3aGF0IEFkcmlhbiANCnNhaWQgKGhlIGhhcyBiZWVuIHF1b3Rl ZCBzZXZlcmFsIHRpbWVzIGluIHRoZSBwYXN0IG1haWxzKS4gT25lIG9mIHRoZSANCmZpbGVkcyBM T0FEbmcgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcmUgQU1JIFBMQyBuZXR3b3JrcyB3aXRoIGxv dyANCmJhbmR3aWR0aCAoZmV3IGticHMgaW4gdGhlIGhhcnNoZXN0IGVudmlyb25tZW50cyksIGJ1 dCBjYW4gYmUgZXh0ZW5zaWJsZSANCnRvIG90aGVyIHR5cGVzIG9mIE1BTkVUcy4NCg0KQW5kIHJl Z2FyZGluZyB5b3VyIGNvbW1lbnQgYWJvdXQgZXhwZXJpZW5jZSB3aXRoIExPQURuZyA6DQoNCj4g TE9BRG5nIGlzIGEgcHJvdG9jb2wgZm9yIHdoaWNoIHNldmVyYWwgcnVubmluZyBpbXBsZW1lbnRh dGlvbnMgZXhpc3QgYW5kIA0KaW50ZXJvcGVyYXRlIGFzIHNob3duIGluIGRyYWZ0IDogDQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sYXZlbnUtbGxuLWxvYWRuZy1pbnRlcm9wZXJh YmlsaXR5LXJlcG9ydC0wMg0KPiBJbiBhZGRpdGlvbiwgTE9BRCAodGhlIHByZXZpb3VzIHZlcnNp b24pIHdhcyBzdWNjZXNzZnVsbHkgcnVuIGluIGEgMjAwMCANClBMQyBub2RlIHRyaWFsLg0KDQpJ IHRoaW5rIHRoYXQgYWxsIHRoZSBmYWN0cyBhcmUgb24gdGhlIHRhYmxlIHRvIHNheSB0aGF0IExP QUQgd291bGQgYmUgDQpzdWl0YWJsZSBmb3IgTUFORVRzIChMTE5zIGJlaW5nIGEgc3Vic2V0IG9m IE1BTkVUcykuIEluIGFkZGl0aW9uIGZpZWxkIGFuZCANCmxhYiBleHBlcmllbmNlIGRvZXMgZXhp c3QgYW5kIGRlbW9uc3RyYXRlZCB0aGF0IExPQURuZyBjYW4gYmUgdmVyeSANCmVmZmljaWVudC4N Cg0KUmVnYXJkcywNCkPDqWRyaWMNCg0KIA0KQ8OpZHJpYyBMQVZFTlUNClJlc2VhcmNoIEVuZ2lu ZWVyDQpFREYg4oCTIFImRA0KTUlSRSBEZXBhcnRtZW50DQoxIGF2ZW51ZSBkdSBnw6luw6lyYWwg ZGUgR2F1bGxlDQo5MjE0MSBDTEFNQVJUIC0gRlJBTkNFDQogDQpjZWRyaWMtMi5sYXZlbnVAZWRm LmZyDQpUw6lsLiA6ICszMyAxIDQ3IDY1IDI3IDI5DQpGYXggOiArMzMgMSA0NyA2NSA1NSA1Ng0K DQpVbiBnZXN0ZSBzaW1wbGUgcG91ciBsJ2Vudmlyb25uZW1lbnQsIG4naW1wcmltZXogY2UgbWVz c2FnZSBxdWUgc2kgdm91cyBlbiANCmF2ZXogbCd1dGlsaXTDqS4NCg0KDQoNCg0KRGUgOiAgICBj LmNoYXV2ZW5ldEB3YXR0ZWNvLmNvbQ0KQSA6ICAgICB1bHJpY2hAaGVyYmVyZy5uYW1lLCBpZXRm QHRob21hc2NsYXVzZW4ub3JnDQpDYyA6ICAgIHNyYXRsaWZmQGNpc2NvLmNvbSwgQ2hyaXMuRGVh cmxvdmVAYmFlc3lzdGVtcy5jb20sIG1hbmV0QGlldGYub3JnLCANCmJvYmVycnlAY2lzY28uY29t DQpEYXRlIDogIDE1LzEwLzIwMTIgMTg6MDENCk9iamV0IDogUmU6IFttYW5ldF0gTUFORVQgbWVl dGluZyBhdCBJRVRGODUNCkVudm95w6kgcGFyIDogICAgbWFuZXQtYm91bmNlc0BpZXRmLm9yZw0K DQoNCg0KSGkgdWxyaWNoIGFuZCBUaG9tYXMgDQoNCkxlIDE1IG9jdC4gMjAxMiDDoCAxNzoyMiwg VWxyaWNoIEhlcmJlcmcgYSDDqWNyaXQgOg0KDQpIaSBKUCwgDQoNCg0KT24gU3VuLCBPY3QgMTQs IDIwMTIgYXQgMTE6MjggUE0sIEpQIFZhc3NldXIgKGp2YXNzZXVyKSA8DQpqdmFzc2V1ckBjaXNj by5jb20+IHdyb3RlOg0KWy4uLl0NCg0KSlA+IEhlcmUgd2UgZG8gbm90IGRpc2FncmVlIGF0IGFs bC4gSSBhbSBub3Qgc2F5aW5nIHRoYXQgcmVhY3RpdmUgDQpwcm90b2NvbHMgYXJlIG5vdCBhcHBy b3ByaWF0ZSBpbiBhIG51bWJlciBvZiBzY2VuYXJpby4gQWxsIEkgYW0gc2F5aW5nIGlzIA0KdGhh dCAqaWYqIHlvdSBpbnRlbnQgdG8gc3BlY2lmeQ0KYSByZWFjdGl2ZSByb3V0aW5nIHByb3RvY29s IGZvciBMTE5zLCBrbm93aW5nIHRoZSB5ZWFycyBvZiBpbnRlbnNlIHdvcmsgDQphbmQgZWZmb3J0 cyBvZiB0aGUgUk9MTCBXRywgdGhlbiBpdCBzaG91bGQgYmUgZGlzY3Vzc2VkIHdpdGggYSB3aWRl ciANCmF1ZGllbmNlLiANCg0KDQpJIGFncmVlLiBCdXQgdGhhdCdzIG5vdCB3ZSBhcmUgaW50ZW5k aW5nIHRvIGRvLiBXZSBpbnRlbnQgdG8gcHJvZHVjZSBhIA0KcmVhY3RpdmUgcHJvdG9jb2wgZm9y IE1BTkVUcywgd2hpY2ggaXMgcmVxdWVzdGVkIGJ5IHRoZSBNQU5FVCBjaGFydGVyLiANCkxPQURu ZyBpcyBhIHByb3RvY29sIHRoYXQgY292ZXJzIGFsbCB0aGUgdXNlIGNhc2VzIG9mIE1BTkVUcywg b25lIG9mIHdoaWNoIA0KYmVpbmcgTExOcy4NCkFuZCB5ZXMsIHRoZSBpbnRyb2R1Y3Rpb24gYW5k IHRpdGxlIG9mIHRoZSBkcmFmdCBuZWVkcyB0byBiZSBjaGFuZ2VkDQoNCg0KIA0KT24gdGhlIG90 aGVyDQpoYW5kLCBpZiB5b3VyIGV4cGxpY2l0bHkgZXhjbHVkZSBMTE5zIGZyb20geW91ciBwcm90 b2NvbCBpbiB5b3VyIHByb3RvY29sLCANCml0IGlzIG5vIGxvbmdlciByZXF1aXJlZCB0byBpbnZv bHZlIHRoZSBST0xMIFdHLiBUaGUgb2JqZWN0aXZlIGlzIHNpbXBseSANCnRvIGF2b2lkIFdHIGNo YXJ0ZXINCm92ZXJsYXAgYnV0IG1vcmUgaW1wb3J0YW50bHkgdHJ5IHRvIGJlbmVmaXQgZnJvbSB0 aGUgYmVuZWZpdCBvZiBleHBlcnRzIGluIA0KdGhlIGFyZWEgb2YgTExOcyB0byBidWlsZCBhIGdv b2QgcHJvdG9jb2wgZm9yIHRoZSBJbnRlcm5ldC4NCg0KSSBhbSBwZXJzb25hbGx5IGFnYWluc3Qg cmVtb3ZpbmcgdG8gbWVudGlvbiBhIHVzZSBjYXNlIHdoZXJlIGFzIGEgbWF0dGVyIA0Kb2YgZmFj dCB0aGUgcHJvdG9jb2wgaXMgdXNlZCBpbiAoYXMgKm9uZSogdXNlLWNhc2Ugb3V0IG9mIG1hbnkp Lg0KDQpDaXRpbmcgQWRyaWFuIGZyb20gdGhlIGxhc3QgTUFORVQgbWVldGluZzoNCkFkcmlhbiBG YXJyZWxsOiBJZiB5b3Ugd2VyZSB0byBwaWNrIHVwIGEgcmVhY3RpdmUgcHJvdG9jb2wgZm9yIE1B TkVULCB5b3UgDQp3b3VsZCBiZSBpbiBjaGFydGVyLiBJZiB5b3UgcGljayB1cCBhIHByb3RvY29s IGFuZCB5b3VyIG1haW4gdXNlIGNhc2UgaXMgDQpmb3IgTExOcywgeW91IGhhdmUgZGl2ZXJnZWQg ZnJvbSBjaGFydGVyLiBNYWluIHVzZSBjYXNlIGlzIGRlbGljYXRlIHRoaW5nIA0KdG8gdGFsayBh Ym91dC4gSXQgaXMgY2xlYXIgdGhhdCBzb21lIGlmIG5vdCBhbGwgTExOcyBhcmUgTUFORVQuIE5v dCBhbGwgDQpNQU5FVHMgYXJlIExMTnMuIFNvIHlvdSBuZWVkIHRvIGJlIHByb2R1Y2luZyBhIHNp bmdsZSByZWFjdGl2ZSBwcm90b2NvbCANCmZvciBNQU5FVHMsIG5vdCBmb3IgKnNvbWUqIE1BTkVU cy4gWW91IG5lZWQgdG8gYmUgY2xlYXIgdGhhdCB0aGUgcHJvdG9jb2wgDQp5b3Ugd29yayBvbiBp cyBhcHBsaWNhYmxlIGFjcm9zcyBhbGwgTUFORVRzLiBJZiB0aGF0IHBpY2tzIHVwIHNvbWUgTExO cyANCmFjcm9zcyB0aGUgd2F5LCBubyBiaWcgZGVhbCwgYnV0IGl0IHNob3VsZCBub3QgYmUgbWFp biB1c2UgY2FzZS4gTG9vayBhdCANCmFsbCB1c2UgY2FzZXMgZm9yIE1BTkVUcyBhbmQgbWFrZSBz dXJlIHlvdSBhZGRyZXNzIGFsbCBvZiB0aG9zZS4NCg0KWW91J2xsIG5vdCB0aGUgIklmIHRoYXQg cGlja3MgdXAgc29tZSBMTE5zIGFjcm9zcyB0aGUgd2F5LCBubyBiaWcgZGVhbCwgDQpidXQgaXQg c2hvdWxkIG5vdCBiZSBtYWluIHVzZSBjYXNlIi4NCg0KVGhhdCBpcyB3aHkgSSBhc2tlZCBpbiBh IHByZXZpb3VzIG1haWwgdGhlIG5hdHVyZSBvZiBMT0FEbmcgZGVwbG95bWVudHMgDQp5b3Ugd2Vy ZSB0YWxraW5nIGFib3V0Lg0KSSBjYW5ub3QgZmluZCBhbnkgbWF0ZXJpYWwgb24gdGhpcy4NCklm IHRoZXkgYXJlIExMTiwgdGhlbiBpdCBzZWVtcyBpbiBkaXNhZ3JlZW1lbnQgd2l0aCB3aGF0IEFk cmlhbiBzdWdnZXN0Lg0KDQoNClRoaXMgaXMgZXhhY3RseSB3aGF0IHdlIGludGVuZCB0byBkby4N Cg0KDQoNCkl0IHdhcyBhbHNvIGFncmVlZCBhdCB0aGUgbGFzdCBNQU5FVCBtZWV0aW5nIHRoYXQg aWYgTE9BRG5nIHdhcyB0byBiZSANCmNvbnNpZGVyZWQgZm9yIE1BTkVULCBpdCBuZWVkcyB0byBk ZS1lbXBoYXNpemUgTExOcyAod2hpY2ggSSBoYXZlIG5vdCANCmhlYXJkIGFueWJvZHkgZGlzYWdy ZWUgd2l0aCBzbyBmYXIpLiBTbyBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB3ZSBhcmUgDQpldmVu IGRpc2N1c3NpbmcgaGVyZS4gDQoNCkpQPiBObywgdGhpcyB5b3VyIHJlY29sbGVjdGlvbiBvZiB0 aGUgZGlzY3Vzc2lvbi4gImxlc3MtZm9jdXNzZWQiIG9yIA0KImRlLWVtcGhhc2l6ZSIgd2FzIEkg dGhpbmsgeW91ciBpbnRlcnByZXRhdGlvbi4gTWluZSB3YXMgIm5vdCByZWZlcnJpbmcgdG8gDQpM TE5zIiBhdCBhbGwuIA0KDQoNCkkgc2luY2VyZWx5IHN1Z2dlc3QgdG8gd2FpdCB1bnRpbCB5b3Ug cmVhZCB0aGUgbmV3IHJldmlzaW9uLCBhcyB0aGlzIA0KZGlzY3Vzc2lvbiBpcyBoeXBvdGhldGlj YWwgd2l0aG91dCB0aGF0LiANCg0KQWdyZWUgdGhhdCB0aGUgbmV3IHZlcnNpb24gc2hvdWxkIGJl IGEgZ29vZCBwb2ludCBvZiBkaXNjdXNzaW9uLg0KDQpCZXN0LA0KDQpDw6lkcmljLg0KDQoNCiAN Ck90aGVyd2lzZSwgaXQgc2hvdWxkIGJlIHJldmlld2VkIGJ5IGJvdGggV0dzICh0byBiZSBkaXNj dXNzZWQgYmV0d2VlbiANCmNoYWlycyBhbmQgQUQpLg0KDQpCZXN0DQpVbHJpY2ggDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBs aXN0DQptYW5ldEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldA0KDQoNCgoKCkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOoY2VzIGpvaW50ZXMg KGNpLWFwcsOocyBsZSAnTWVzc2FnZScpIHNvbnQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhj bHVzaXZlIGRlcyBkZXN0aW5hdGFpcmVzIGV0IGxlcyBpbmZvcm1hdGlvbnMgcXVpIHkgZmlndXJl bnQgc29udCBzdHJpY3RlbWVudCBjb25maWRlbnRpZWxsZXMuIFRvdXRlIHV0aWxpc2F0aW9uIGRl IGNlIE1lc3NhZ2Ugbm9uIGNvbmZvcm1lIMOgIHNhIGRlc3RpbmF0aW9uLCB0b3V0ZSBkaWZmdXNp b24gb3UgdG91dGUgcHVibGljYXRpb24gdG90YWxlIG91IHBhcnRpZWxsZSwgZXN0IGludGVyZGl0 ZSBzYXVmIGF1dG9yaXNhdGlvbiBleHByZXNzZS4KClNpIHZvdXMgbifDqnRlcyBwYXMgbGUgZGVz dGluYXRhaXJlIGRlIGNlIE1lc3NhZ2UsIGlsIHZvdXMgZXN0IGludGVyZGl0IGRlIGxlIGNvcGll ciwgZGUgbGUgZmFpcmUgc3VpdnJlLCBkZSBsZSBkaXZ1bGd1ZXIgb3UgZCdlbiB1dGlsaXNlciB0 b3V0IG91IHBhcnRpZS4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIE1lc3NhZ2UgcGFyIGVycmV1ciwg bWVyY2kgZGUgbGUgc3VwcHJpbWVyIGRlIHZvdHJlIHN5c3TDqG1lLCBhaW5zaSBxdWUgdG91dGVz IHNlcyBjb3BpZXMsIGV0IGRlIG4nZW4gZ2FyZGVyIGF1Y3VuZSB0cmFjZSBzdXIgcXVlbHF1ZSBz dXBwb3J0IHF1ZSBjZSBzb2l0LiBOb3VzIHZvdXMgcmVtZXJjaW9ucyDDqWdhbGVtZW50IGQnZW4g YXZlcnRpciBpbW3DqWRpYXRlbWVudCBsJ2V4cMOpZGl0ZXVyIHBhciByZXRvdXIgZHUgbWVzc2Fn ZS4KCklsIGVzdCBpbXBvc3NpYmxlIGRlIGdhcmFudGlyIHF1ZSBsZXMgY29tbXVuaWNhdGlvbnMg cGFyIG1lc3NhZ2VyaWUgw6lsZWN0cm9uaXF1ZSBhcnJpdmVudCBlbiB0ZW1wcyB1dGlsZSwgc29u dCBzw6ljdXJpc8OpZXMgb3UgZMOpbnXDqWVzIGRlIHRvdXRlIGVycmV1ciBvdSB2aXJ1cy4KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgKHRoZSAnTWVzc2FnZScpIGFyZSBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSBhZGRyZXNzZWVzLiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgTWVzc2FnZSBpcyBjb25maWRlbnRpYWwuIEFueSB1c2Ugb2YgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgTWVzc2FnZSBub3QgaW4gYWNjb3JkIHdpdGggaXRzIHB1cnBvc2UsIGFueSBk aXNzZW1pbmF0aW9uIG9yIGRpc2Nsb3N1cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFsLCBpcyBw cm9oaWJpdGVkIGV4Y2VwdCBmb3JtYWwgYXBwcm92YWwuCgpJZiB5b3UgYXJlIG5vdCB0aGUgYWRk cmVzc2VlLCB5b3UgbWF5IG5vdCBjb3B5LCBmb3J3YXJkLCBkaXNjbG9zZSBvciB1c2UgYW55IHBh cnQgb2YgaXQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBhbmQgYWxsIGNvcGllcyBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1cm4gbWVzc2FnZS4KCkUtbWFpbCBjb21tdW5p Y2F0aW9uIGNhbm5vdCBiZSBndWFyYW50ZWVkIHRvIGJlIHRpbWVseSBzZWN1cmUsIGVycm9yIG9y IHZpcnVzLWZyZWUuCg== --=_alternative 005D40A9C1257A99_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgQ8OpZHJpYyw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknbSBub3Qgc3VyZSBhbGwgdGhp cyBkaXNjdXNzaW9ucyByZWFsbHkNCm1ha2Ugc2Vuc2UgOjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBBbiBMTE4gbmV0d29yayBpcyBkZWZpbml0 ZWx5IGENCnR5cGUgb2YgTUFORVQgYWNjb3JkaW5nIHRvIHdoYXQgQWRyaWFuIHNhaWQgKGhlIGhh cyBiZWVuIHF1b3RlZCBzZXZlcmFsDQp0aW1lcyBpbiB0aGUgcGFzdCBtYWlscykuIE9uZSBvZiB0 aGUgZmlsZWRzIExPQURuZyBpcyBpbnRlbmRlZCB0byBiZSB1c2VkDQphcmUgQU1JIFBMQyBuZXR3 b3JrcyB3aXRoIGxvdyBiYW5kd2lkdGggKGZldyBrYnBzIGluIHRoZSBoYXJzaGVzdCBlbnZpcm9u bWVudHMpLA0KYnV0IGNhbiBiZSBleHRlbnNpYmxlIHRvIG90aGVyIHR5cGVzIG9mIE1BTkVUcy48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZCByZWdh cmRpbmcgeW91ciBjb21tZW50IGFib3V0IGV4cGVyaWVuY2UNCndpdGggTE9BRG5nIDo8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgTE9BRG5nIGlz IGEgcHJvdG9jb2wgZm9yIHdoaWNoDQpzZXZlcmFsIHJ1bm5pbmcgaW1wbGVtZW50YXRpb25zIGV4 aXN0IGFuZCBpbnRlcm9wZXJhdGUgYXMgc2hvd24gaW4gZHJhZnQNCjogPC9mb250PjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxhdmVudS1sbG4tbG9hZG5nLWludGVy b3BlcmFiaWxpdHktcmVwb3J0LTAyIj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGF2ZW51LWxsbi1sb2FkbmctaW50ZXJvcGVy YWJpbGl0eS1yZXBvcnQtMDI8L2ZvbnQ+PC9hPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7IEluIGFkZGl0aW9uLCBMT0FEICh0aGUgcHJldmlvdXMNCnZlcnNpb24pIHdh cyBzdWNjZXNzZnVsbHkgcnVuIGluIGEgMjAwMCBQTEMgbm9kZSB0cmlhbC48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgdGhhdCBhbGwgdGhl IGZhY3RzIGFyZSBvbiB0aGUNCnRhYmxlIHRvIHNheSB0aGF0IExPQUQgd291bGQgYmUgc3VpdGFi bGUgZm9yIE1BTkVUcyAoTExOcyBiZWluZyBhIHN1YnNldA0Kb2YgTUFORVRzKS4gSW4gYWRkaXRp b24gZmllbGQgYW5kIGxhYiBleHBlcmllbmNlIGRvZXMgZXhpc3QgYW5kIGRlbW9uc3RyYXRlZA0K dGhhdCBMT0FEbmcgY2FuIGJlIHZlcnkgZWZmaWNpZW50LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkPDqWRyaWM8L2ZvbnQ+DQo8dGFibGU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCByb3dzcGFuPTI+PGltZyBzcmM9Y2lkOl8yXzBENzExRDQ4MEQ3MTE5NDgwMDVE NDAxOUMxMjU3QTk5Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9I2ZmODEwMCBm YWNlPSJBcmlhbCI+PGI+Q8OpZHJpYyBMQVZFTlU8L2I+PC9mb250Pjxmb250IHNpemU9MSBjb2xv cj0jZmY4MTAwIGZhY2U9IkFyaWFsIj48Yj48YnI+DQpSZXNlYXJjaCBFbmdpbmVlcjwvYj48L2Zv bnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSMwMDYyZTEgZmFjZT0iQXJpYWwiPjxicj4NCkVERiDigJMg UiZhbXA7RDxicj4NCk1JUkUgRGVwYXJ0bWVudDxicj4NCjEgYXZlbnVlIGR1IGfDqW7DqXJhbCBk ZSBHYXVsbGU8YnI+DQo5MjE0MSBDTEFNQVJUIC0gRlJBTkNFPC9mb250Pjxmb250IHNpemU9MSBj b2xvcj0jMDA2MmUxIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGNvbG9yPSMwMDYyZTEgZmFjZT0iQXJpYWwiPjxiPmNlZHJpYy0yLmxhdmVudUBlZGYu ZnI8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jMDA2MmUxIGZhY2U9IkFyaWFs Ij5Uw6lsLiA6ICszMyAxIDQ3IDY1IDI3IDI5PGJyPg0KRmF4IDogKzMzIDEgNDcgNjUgNTUgNTY8 L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0PjxpbWcgc3JjPWNpZDpfMV8wRDcx MkU0QzBENzEyQTc4MDA1RDQwMTlDMTI1N0E5OT48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgY29s b3I9IzAwNjJlMSBmYWNlPSJBcmlhbCI+VW4gZ2VzdGUgc2ltcGxlIHBvdXIgbCdlbnZpcm9ubmVt ZW50LA0KbidpbXByaW1leiBjZSBtZXNzYWdlIHF1ZSBzaSB2b3VzIGVuIGF2ZXogbCd1dGlsaXTD qS48L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EZSA6ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmMuY2hhdXZl bmV0QHdhdHRlY28uY29tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZh Y2U9InNhbnMtc2VyaWYiPkEgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj51bHJpY2hAaGVyYmVyZy5uYW1lLA0KaWV0ZkB0 aG9tYXNjbGF1c2VuLm9yZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBm YWNlPSJzYW5zLXNlcmlmIj5DYyZuYnNwOzogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+c3JhdGxpZmZAY2lzY28uY29tLA0K Q2hyaXMuRGVhcmxvdmVAYmFlc3lzdGVtcy5jb20sIG1hbmV0QGlldGYub3JnLCBib2JlcnJ5QGNp c2NvLmNvbTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5z LXNlcmlmIj5EYXRlIDogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTUvMTAvMjAxMiAxODowMTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5PYmpldCA6ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJlOiBbbWFuZXRdDQpNQU5FVCBtZWV0aW5nIGF0IElFVEY4NTwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5FbnZvecOpIHBhciA6ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SGkgdWxyaWNoIGFuZCBUaG9tYXMgPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9Mz5MZSAxNSBvY3QuIDIwMTIgw6AgMTc6MjIsIFVscmljaCBI ZXJiZXJnIGEgw6ljcml0IDo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkhpIEpQLCA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+ T24gU3VuLCBPY3QgMTQsIDIwMTIgYXQgMTE6MjggUE0sIEpQIFZhc3NldXIgKGp2YXNzZXVyKQ0K Jmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpqdmFzc2V1ckBjaXNjby5jb20gdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5qdmFzc2V1ckBjaXNjby5jb208L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTM+Jmd0Ow0Kd3JvdGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5b Li4uXTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SlAmZ3Q7IEhlcmUgd2UgZG8gbm90 IGRpc2FncmVlIGF0IGFsbC4gSSBhbSBub3Qgc2F5aW5nDQp0aGF0IHJlYWN0aXZlIHByb3RvY29s cyBhcmUgbm90IGFwcHJvcHJpYXRlIGluIGEgbnVtYmVyIG9mIHNjZW5hcmlvLiBBbGwNCkkgYW0g c2F5aW5nIGlzIHRoYXQgKmlmKiB5b3UgaW50ZW50IHRvIHNwZWNpZnk8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPmEgcmVhY3RpdmUgcm91dGluZyBwcm90b2NvbCBmb3IgTExOcywga25vd2luZyB0 aGUgeWVhcnMNCm9mIGludGVuc2Ugd29yayBhbmQgZWZmb3J0cyBvZiB0aGUgUk9MTCBXRywgdGhl biBpdCBzaG91bGQgYmUgZGlzY3Vzc2VkDQp3aXRoIGEgd2lkZXIgYXVkaWVuY2UuIDwvZm9udD4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SSBhZ3JlZS4gQnV0IHRoYXQncyBub3Qgd2Ug YXJlIGludGVuZGluZyB0byBkby4gV2UgaW50ZW50DQp0byBwcm9kdWNlIGEgcmVhY3RpdmUgcHJv dG9jb2wgZm9yIE1BTkVUcywgd2hpY2ggaXMgcmVxdWVzdGVkIGJ5IHRoZSBNQU5FVA0KY2hhcnRl ci4gTE9BRG5nIGlzIGEgcHJvdG9jb2wgdGhhdCBjb3ZlcnMgYWxsIHRoZSB1c2UgY2FzZXMgb2Yg TUFORVRzLA0Kb25lIG9mIHdoaWNoIGJlaW5nIExMTnMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mz5BbmQgeWVzLCB0aGUgaW50cm9kdWN0aW9uIGFuZCB0aXRsZSBvZiB0aGUgZHJhZnQgbmVlZHMN CnRvIGJlIGNoYW5nZWQ8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+T24gdGhlIG90aGVyPC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz5oYW5kLCBpZiB5b3VyIGV4cGxpY2l0bHkgZXhjbHVkZSBMTE5zIGZyb20geW91ciBw cm90b2NvbA0KaW4geW91ciBwcm90b2NvbCwgaXQgaXMgbm8gbG9uZ2VyIHJlcXVpcmVkIHRvIGlu dm9sdmUgdGhlIFJPTEwgV0cuIFRoZQ0Kb2JqZWN0aXZlIGlzIHNpbXBseSB0byBhdm9pZCBXRyBj aGFydGVyPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5vdmVybGFwIGJ1dCBtb3JlIGltcG9ydGFu dGx5IHRyeSB0byBiZW5lZml0IGZyb20gdGhlIGJlbmVmaXQNCm9mIGV4cGVydHMgaW4gdGhlIGFy ZWEgb2YgTExOcyB0byBidWlsZCBhIGdvb2QgcHJvdG9jb2wgZm9yIHRoZSBJbnRlcm5ldC48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkkgYW0gcGVyc29uYWxseSBhZ2FpbnN0IHJlbW92 aW5nIHRvIG1lbnRpb24gYSB1c2UgY2FzZQ0Kd2hlcmUgYXMgYSBtYXR0ZXIgb2YgZmFjdCB0aGUg cHJvdG9jb2wgaXMgdXNlZCBpbiAoYXMgKm9uZSogdXNlLWNhc2Ugb3V0DQpvZiBtYW55KS48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkNpdGluZyBBZHJpYW4gZnJvbSB0aGUgbGFzdCBN QU5FVCBtZWV0aW5nOjwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0zPkFkcmlhbiBGYXJyZWxs OiBJZiB5b3Ugd2VyZSB0byBwaWNrIHVwIGEgcmVhY3RpdmUNCnByb3RvY29sIGZvciBNQU5FVCwg eW91IHdvdWxkIGJlIGluIGNoYXJ0ZXIuIElmIHlvdSBwaWNrIHVwIGEgcHJvdG9jb2wNCmFuZCB5 b3VyIG1haW4gdXNlIGNhc2UgaXMgZm9yIExMTnMsIHlvdSBoYXZlIGRpdmVyZ2VkIGZyb20gY2hh cnRlci4gTWFpbg0KdXNlIGNhc2UgaXMgZGVsaWNhdGUgdGhpbmcgdG8gdGFsayBhYm91dC4gSXQg aXMgY2xlYXIgdGhhdCBzb21lIGlmIG5vdA0KYWxsIExMTnMgYXJlIE1BTkVULiBOb3QgYWxsIE1B TkVUcyBhcmUgTExOcy4gU28geW91IG5lZWQgdG8gYmUgcHJvZHVjaW5nDQphIHNpbmdsZSByZWFj dGl2ZSBwcm90b2NvbCBmb3IgTUFORVRzLCBub3QgZm9yICpzb21lKiBNQU5FVHMuIFlvdSBuZWVk DQp0byBiZSBjbGVhciB0aGF0IHRoZSBwcm90b2NvbCB5b3Ugd29yayBvbiBpcyBhcHBsaWNhYmxl IGFjcm9zcyBhbGwgTUFORVRzLg0KSWYgdGhhdCBwaWNrcyB1cCBzb21lIExMTnMgYWNyb3NzIHRo ZSB3YXksIG5vIGJpZyBkZWFsLCBidXQgaXQgc2hvdWxkIG5vdA0KYmUgbWFpbiB1c2UgY2FzZS4g TG9vayBhdCBhbGwgdXNlIGNhc2VzIGZvciBNQU5FVHMgYW5kIG1ha2Ugc3VyZSB5b3UgYWRkcmVz cw0KYWxsIG9mIHRob3NlLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5Zb3Un bGwgbm90IHRoZSAmcXVvdDs8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz5JZiB0aGF0IHBpY2tzDQp1 cCBzb21lIExMTnMgYWNyb3NzIHRoZSB3YXksIG5vIGJpZyBkZWFsLCBidXQgaXQgc2hvdWxkIG5v dCBiZSBtYWluIHVzZQ0KY2FzZSZxdW90Oy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+VGhhdCBpcyB3aHkgSSBhc2tlZCBpbiBhIHByZXZpb3VzIG1haWwgdGhlIG5hdHVyZSBv ZiBMT0FEbmcNCmRlcGxveW1lbnRzIHlvdSB3ZXJlIHRhbGtpbmcgYWJvdXQuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz5JIGNhbm5vdCBmaW5kIGFueSBtYXRlcmlhbCBvbiB0aGlzLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+SWYgdGhleSBhcmUgTExOLCB0aGVuIGl0IHNlZW1zIGluIGRpc2Fn cmVlbWVudCB3aXRoIHdoYXQNCkFkcmlhbiBzdWdnZXN0LjwvZm9udD4NCjxicj4NCjxicj4NCjxi cj48Zm9udCBzaXplPTM+VGhpcyBpcyBleGFjdGx5IHdoYXQgd2UgaW50ZW5kIHRvIGRvLjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SXQgd2FzIGFsc28gYWdyZWVk IGF0IHRoZSBsYXN0IE1BTkVUIG1lZXRpbmcgdGhhdCBpZiBMT0FEbmcNCndhcyB0byBiZSBjb25z aWRlcmVkIGZvciBNQU5FVCwgaXQgbmVlZHMgdG8gZGUtZW1waGFzaXplIExMTnMgKHdoaWNoIEkN CmhhdmUgbm90IGhlYXJkIGFueWJvZHkgZGlzYWdyZWUgd2l0aCBzbyBmYXIpLiBTbyBJIGRvbid0 IHVuZGVyc3RhbmQgd2hhdA0Kd2UgYXJlIGV2ZW4gZGlzY3Vzc2luZyBoZXJlLiA8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkpQJmd0OyBObywgdGhpcyB5b3VyIHJlY29sbGVjdGlvbiBv ZiB0aGUgZGlzY3Vzc2lvbi4gJnF1b3Q7bGVzcy1mb2N1c3NlZCZxdW90Ow0Kb3IgJnF1b3Q7ZGUt ZW1waGFzaXplJnF1b3Q7IHdhcyBJIHRoaW5rIHlvdXIgaW50ZXJwcmV0YXRpb24uIE1pbmUgd2Fz ICZxdW90O25vdA0KcmVmZXJyaW5nIHRvIExMTnMmcXVvdDsgYXQgYWxsLiA8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkkgc2luY2VyZWx5IHN1Z2dlc3QgdG8gd2FpdCB1bnRp bCB5b3UgcmVhZCB0aGUgbmV3IHJldmlzaW9uLA0KYXMgdGhpcyBkaXNjdXNzaW9uIGlzIGh5cG90 aGV0aWNhbCB3aXRob3V0IHRoYXQuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+QWdy ZWUgdGhhdCB0aGUgbmV3IHZlcnNpb24gc2hvdWxkIGJlIGEgZ29vZCBwb2ludCBvZiBkaXNjdXNz aW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+QmVzdCw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zPkPDqWRyaWMuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNp emU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPk90aGVyd2lzZSwgaXQgc2hvdWxk IGJlIHJldmlld2VkIGJ5IGJvdGggV0dzICh0byBiZSBkaXNjdXNzZWQNCmJldHdlZW4gY2hhaXJz IGFuZCBBRCkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5CZXN0PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz5VbHJpY2ggPC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWls aW5nIGxpc3Q8YnI+DQptYW5ldEBpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldD48dHQ+PGZvbnQgc2l6ZT0y Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2ZvbnQ+PC90dD48 L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NPHA+PC9wPgoKPHA+ PGJyPgpDZSBtZXNzYWdlIGV0IHRvdXRlcyBsZXMgcGnDqGNlcyBqb2ludGVzIChjaS1hcHLDqHMg bGUgJ01lc3NhZ2UnKSBzb250IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZXMg ZGVzdGluYXRhaXJlcyBldCBsZXMgaW5mb3JtYXRpb25zIHF1aSB5IGZpZ3VyZW50IHNvbnQgc3Ry aWN0ZW1lbnQgY29uZmlkZW50aWVsbGVzLiBUb3V0ZSB1dGlsaXNhdGlvbiBkZSBjZSBNZXNzYWdl IG5vbiBjb25mb3JtZSDDoCBzYSBkZXN0aW5hdGlvbiwgdG91dGUgZGlmZnVzaW9uIG91IHRvdXRl IHB1YmxpY2F0aW9uIHRvdGFsZSBvdSBwYXJ0aWVsbGUsIGVzdCBpbnRlcmRpdGUgc2F1ZiBhdXRv cmlzYXRpb24gZXhwcmVzc2UuPC9wPgoKPHA+U2kgdm91cyBuJ8OqdGVzIHBhcyBsZSBkZXN0aW5h dGFpcmUgZGUgY2UgTWVzc2FnZSwgaWwgdm91cyBlc3QgaW50ZXJkaXQgZGUgbGUgY29waWVyLCBk ZSBsZSBmYWlyZSBzdWl2cmUsIGRlIGxlIGRpdnVsZ3VlciBvdSBkJ2VuIHV0aWxpc2VyIHRvdXQg b3UgcGFydGllLiBTaSB2b3VzIGF2ZXogcmXDp3UgY2UgTWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJj aSBkZSBsZSBzdXBwcmltZXIgZGUgdm90cmUgc3lzdMOobWUsIGFpbnNpIHF1ZSB0b3V0ZXMgc2Vz IGNvcGllcywgZXQgZGUgbidlbiBnYXJkZXIgYXVjdW5lIHRyYWNlIHN1ciBxdWVscXVlIHN1cHBv cnQgcXVlIGNlIHNvaXQuIE5vdXMgdm91cyByZW1lcmNpb25zIMOpZ2FsZW1lbnQgZCdlbiBhdmVy dGlyIGltbcOpZGlhdGVtZW50IGwnZXhww6lkaXRldXIgcGFyIHJldG91ciBkdSBtZXNzYWdlLjwv cD4KCjxwPklsIGVzdCBpbXBvc3NpYmxlIGRlIGdhcmFudGlyIHF1ZSBsZXMgY29tbXVuaWNhdGlv bnMgcGFyIG1lc3NhZ2VyaWUgw6lsZWN0cm9uaXF1ZSBhcnJpdmVudCBlbiB0ZW1wcyB1dGlsZSwg c29udCBzw6ljdXJpc8OpZXMgb3UgZMOpbnXDqWVzIGRlIHRvdXRlIGVycmV1ciBvdSB2aXJ1cy48 YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3A+Cgo8cD5UaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICdNZXNzYWdlJykg YXJlIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBNZXNzYWdlIGlzIGNvbmZpZGVudGlhbC4gQW55IHVzZSBvZiBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBNZXNzYWdlIG5vdCBpbiBhY2NvcmQgd2l0aCBpdHMg cHVycG9zZSwgYW55IGRpc3NlbWluYXRpb24gb3IgZGlzY2xvc3VyZSwgZWl0aGVyIHdob2xlIG9y IHBhcnRpYWwsIGlzIHByb2hpYml0ZWQgZXhjZXB0IGZvcm1hbCBhcHByb3ZhbC48L3A+Cgo8cD5J ZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlLCB5b3UgbWF5IG5vdCBjb3B5LCBmb3J3YXJkLCBk aXNjbG9zZSBvciB1c2UgYW55IHBhcnQgb2YgaXQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgYWxsIGNvcGllcyBmcm9tIHlv dXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1cm4gbWVz c2FnZS48L3A+Cgo8cD5FLW1haWwgY29tbXVuaWNhdGlvbiBjYW5ub3QgYmUgZ3VhcmFudGVlZCB0 byBiZSB0aW1lbHkgc2VjdXJlLCBlcnJvciBvciB2aXJ1cy1mcmVlLjwvcD4= --=_alternative 005D40A9C1257A99_=-- --=_related 005D40A9C1257A99_= Content-Type: image/jpeg Content-ID: <_2_0D711D480D711948005D4019C1257A99> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgASwCSAwERAAIRAQMRAf/EALkAAAEEAgMBAQAAAAAAAAAA AAAHCAkKAwUCBAYBCwEAAQMFAQEAAAAAAAAAAAAAAAQHCQEDBQYIAgoQAAEEAgEDAgQCBgcJAQAA AAIDBAUGAQcAERIIEwkhIhQVMUFRkbEyQiNxgcFi0iQW8GGhUoKSQxcKNBEAAQMDAwIDBQQFCgUF AQAAAgEDBBIFBgARByITITIIMUFCUhRRYiMVYXGBkQnwodHhcoKSsjMksaJDUxbBwtI0Jhf/2gAM AwEAAhEDEQA/AL/HDRo4aNHDRo4aNHDRo4aNHDRo4aNHDRo4aNHDRo4aNHDRo4aNHDRpnflP5saY 8SkaujsF4/l7Ja5Jmkwp9ZBu+saNfJ6DeYtjxoosiLaHikPUyPfkTeLj6KOCLvIGc5Y5vwriFiMW RuG5PlOCgsNbE6jVWxvKikmwAm9O61OF0h8Sj0PwR6ZOSfUC7OcxFtmPZbeyZOTJNQRykUKTUUDQ VqedLbelKWgXuO7DShOWpN1quxqtB3akTsfZKtY2CMlDzMYthdo7aLD8P4cKIrJF1BVI8CqkqJAY iQ5xxyrBfrPlFoYv1gfblWeU2htOgu4kn/tJPKQrsQlUJIJJplcmxi/YbfpWM5REeh36G8TTzLqU kBD/AJhL2iQ1CYqhCSiqLr13MzrBaOGjRw0aOGjUffkB7mPin43X55rS+WewSdwimGHs7H0quOLK jXlVEfXbRc08buEW7OXco4E8IdSJMTHKvZ140OXc4cf4Vdzsd2kPOXJsajFhonaPlAyRdhMvl38P ip11pxJ6JufOZ8TazbFYMOPjsh6hg5sgYxSEQqSdYAkIjaEvCvwQlRaK9OE8dd1SXkBr5ltAtb2P XFWsvpSFFRtr+JVsFlrDhHBtbG8hopV0VdSfH1yg2cKkuSParnAiYjzcMMyZ7L7OF+WE9DgPdTHd IK3Wl8rpAKr26vHYSKqnx9+mh5i40h8R5g7go3mHeb9BqCcUUHUjx5Ql1RwedEfqFD43AFAE6gTe nfTgObdpqdHDRo4aNHDRo4aNHDRo4aNaebmIuuQ0vYZp4jHQ0FGP5qXkHB5FuwjItqq+fvVyx8QR atETM8/8o8Sy5MeDFdnSjFuMy2RmReUQBKiJf7KJvpbbLdOvNyj2e2Nk9cpTwMtNj5jddJAAB+8R EIpqmPE+7z5UUnyF2dtapWj/AFLre+X2VnUNO3tR1KVRjWRcAxgmEA4FT7pT36NfZNwUUYn6Crju VVQVIuRhxfUxndnzW4XuI73rFKmG59G9ubYhvsAh41NEIII7tkIqXUQlr6TLh/Dy4HybiGx4Ff4P 0WZ2m0tMFd4KC1KORTW+4+O3algUgzIRfHuC3s226CDqwb4f+6343eVa8PT3r9TUW4JL0WqWvrq6 bpITcgoPTLem2cfSibCaymM+m3z6D0uuB9HJc7O429QGEchduBX9DkJbD2HV6TL7GnfBC3+ESpNf DpXURHqI9BHM/AzcnIYrQ5Dx2xuRXCEJKTDafFMi9TselPMfWwnt7u2mO+cXudbppPl/Gaw8W0U7 VBaVjpZhtCCCBfWSKvFwlkUhkot+MQmpLNWGv0RRAF25pdsoquCneAiJMlzT6h8nx3kVuw8fB9U1 bAMZTXbJ0XnSpQxIR6qWOkRISGl2uqoUTXUHpf8AQ/xtk/p4fzjnUit90yZ5o7a/3wjuwobRF2nW +6qNEc8qyJtwT3jC0QUkRKkO83ObT3jcbbtS9r2W8WmSd5fWqf8Atkg6bRIj3fTx5C2QUZVyIi2w +kg2/lJN0g/D94uRtZxkGY59eJuT3cZUuZUpPHQRC0P2LSmwAKDsI9IiiUjqRm2WvBOL8dt2B4qE G12JlvtxWO62JO/M51EhyHXS6nHeojNf1JqQnwj8o9jeL78XC0XYbHoudk00rVEizfKxkY/VyKKs 7V5JVP7aznU+mPWbeoKT0flLtV7D5v3p99QuZcJTvqp0eZM4vkPIMgKSoaIiRO6wZdAvJ7wqFHU6 S+E2+QfU5wXhvOcXtNvw4fKcVlViu1gLroD4oxKaRe6bC/A7SRM+ZKm6h1Zyo15quyatEXSkzLWe rk60B5HyLM8EKgljqoiun8FWzxup1BZE8CqkY5EsYzyajE8rx7OMfjZPi8puZZJTdQOgv7xVPMBi vSYFsQklKj4ahAyjF79hd+k41ksZyLe4rlBtn/MQr7CAk6gMdxIeoVXXq+pfoL9SvNhoH7S/n1ga S+xP8X9WtTPz0LV4aTsVjk2ULBQzNaQlpaQcA1Yx7FsPqLu3a6vamiiiOO4iz+GOWJcuLAiOTZpi 3EbGozLwQUT2kS/ZrIWm03K+3Jiz2dhyTdZTgttNNjUZmXlABTxIl9ya2aS6Tpum4bqiqi4RBVBZ LoYmmsGFE1U8/gQkBYzjP58viQuAhNr0EPgukTjbjLpMvDS4JUkK+4k8yLqhL5LUi9a43pueqbSb SKNxaXi1ykyvIkSi82ynJJ5KRtibvCx2vWExFuEzQWDJB/D+IlgYl83tV2s2VXK334XBuSSnSPf4 xMiITEviExISEv2e7X1f8JZRi2ZcW43kGCGyWNuWuK0wLfgLJsNNtORyD/pm06JIYFsvxfFq594U JWpHxK8d0roqirY//U9PJ4TdkMekLVSKRUiEsNU/kE28MTdMy/8AIY5P+Lkl/GI3AePbMN0ISmfl 7W+w0+FPR4foCn+17dfNd6mnLC56gswLGhIbP/5BMoqOtakdIXSqX3E9Wop8Iqg+7Tpub5pjtHDR o4aNHDRo4aNHDRo4aNeB2Vr2u7YoFw1rcE5FWrXmvyVZn0omUfQsirFSzc2rxNrJxyyDxoZpKZx1 AvmHrgsEOSEsTe7PCyGzSbHcavoJTJNHQSgVJeBUkPiP8kXw1s2F5desAy63ZtjqsjfrXLaksK60 DwI60VQETTgkBohfMP3h2IUXVK73KfCyi+Ee2apSqHsaTukXeK5JWxvA2Fg3RslLiWsoEXHoSksx wjHziMquK2G6wINVf8qp3p/umUWXPPFdo4tyBiDZ5pSGZTKu9o0TutDVSNRD0mJ7HSqCPkJCH2Vf TB6LPUtlPqc4/n5LlVmZts61zGopPxzJY8x0mu64rTTlRsE0NFYE46P4oUn7RTR+3DqTZuyt9zFo 1LXYyy3vSWsrrtKmR824wyiFb+0YfYaDhw6UTNum5QsUum5bpqdgKqtfmIR7iwn4Hxy+XvLXp+PM i9dbbBdlNCq7D3xGln29KkjpiQiSoiqKe7qTJes3kHCcK4njWPkGY/BxXJr5Ctcw2RrdGAbnfn0g hVKKxmiaNR3URd8BJaU1k09XHjmZl9T7Ptdk1VfZfb7CRvc5NMZVGak5LBOGM1CWNZqJSEfPRc06 Vfssrj9Eq4dKkZCQoETZDJWVdn8SyWY9Z725cxJ90xPc9iISBzZKxcbIiIKukiM66SQavPIt5jsW 2PyBg0CDfsVj464EJhk2iZaa6XGHowl+G4w6wIsPUfjCDQIIkKuoMiMOlTLw7TsuY/YurXOsbDLk hWsjYEZrc75rGSkmvIIprI/5jYTwYVP7pkMdptS7BESJLuzE56y5FIG6uJdLK9a5Bk3H/FR26EgO u1BUP/3C7Q9+mlO10iIlRVx7cXMkxdgrL3rPfmb5Da3k/wC3JmzATrTQtrSvTADvF9Lv4i71ERCj m3Vs8vVfSgtitsTFESnqvaa0WkVmsxliKCTZxFsfs4PkhZMaas8fYdKGsRK/VNyJEe/t7WjzW92J hlnL0WRawlW+VH/JqXSDakmm+13BoGKRud0qyIxMD7Q1003rJb793JWHPfT3Uok6LJ/OhJqupSF0 +7QtZzBBvtCIJT2nEF3oq3lr9sjU1po+oZS7WGSlkGWyH6MlW6quuoEYxh2IqIJ2IWJdRRf2FTqX fjt72qSRfNgsFyQL0A8c5FivGj+XXyRKGJfHBOLEIi7QMN1D9TQvlckL5S6amgAupCHUfvre5AsO UchMYvZ2Y5SbK0rUiUKJ3DdPqWPX7246eFPjS6Rp4baku/6v9v1873oH5S/n/p1xLsP2l/N/RqBP 3rt8711/D0rVFVF3XdLbXrFijb1aWzFJXNll/rWiQ0XM0SZLQI5iRJY0wNJR+msQYIgAx5yZ6nct yqzxouP2+pnGbhHMX3UT/VOpPwK/g6OrZKSNC28qFqWH+GZxTxZl1yuee35W5nJePzo7sKKRqn0z VBr9b2N9n/xdgEiQhYIEJUQjFdNp8ZPeas+ntSQetdq6vkdqSdNjm8LVrhF2hnBv30IwSw3jGNsR ko95hZ5GtRFEXyGTJwkA96Xqdyh6Tg/qWm45j7dkv0By4PRWxBp0XRAiAekRdqEuoU8Kx8w+Yauo nr5t/htWTkbkCVm2B3xmwwLk+T0qI7FN8AfMqnTik2YUg4dR9g9kAiWg6KQGXbWFa8afcl1FqnyP 2h49wbuVWSl20OwuSIy0hEjFTrpg6Z4mGacanY684fRv1Df1U8oEB9whjJF16KscHCeacdgZpfrO ybtJiAv9ZDQ4QkNY09xtSGpKh2+77dR65xeua/RfyHfuGMFzCU3BEmidOGXaB3usC4J9o1dWPIEH KHKSrRRpIlpTSE+fkv7jzi3RmtPD+hOoLU7KqRi7m9Ux5VmdlkJUiWQWgWriaeNyrLCEbNUhTBmi Cqvd19Xs6AOp8uyeZznhY+OYqs48McVJ9hWhdIv+2KmQ9oQQUpoSovm26dOn6S7d6M2bA9m3qKuo Ss/duDojBmBKOO210kj5iyBfUm+REpE6agNO3bq6igg2dsD3DvHO0sX+2dh+R+t7BLEqpFylkuM8 rFzZIfFwmxfZfPIGUwj3fzEcZP5P3h7ecn3y78xYZOB/IJl6gy3PKTr50ufNSVRNr94dSsYRiXo/ 5ksLsTj+z4berRHpF1qPDYF1iryqYUA+1V8J7J1eVatTX6b9zixwHtib78yt2QRz9h8a4S4JOHrR j9ojdnysPHRuKcSZNxFq1XmZ6caMJBRsHpJF3KgHXPp47y9NeRXrl+0xYt22G5/XfTk+I7C6KCJq 6I+WpAVahHpqH3VdMJfrv4YxH08cru2rCz//ADsy2tTWopO912Gbpm2rBEW59usKmlcUjoLZaqai qzaE2L7r/uZal3x5uSvu8wHiw7pE9cB11oJHbK2rWthkalXmdlfQlbqNfnoZGr1sWj5CPYSLxtLO pF0J+vnPQ1SkAukLB8OnRMbbsJThcEO4/wBru0iRU1EZCVReYiESGkfZ8uo7o0u73iO9cfrhapIq ArpqpGryjt7v0fd/Tp4ni/7xvlf5N+xn7jczcdoWGG8r/DmqU3EBviqLt6xd5qo3uUSSrE4+cQ6T ZuNxhnVclGDx63BL6xuTdUxyuapqa7e+PbHZeSbSMdkSslwI6mC6gFxseoer4CqEkH4Vq91I6zFp v8m42Z8XjX6uOTfUJU1CRU+0fH3F4+bqHx36tIl4g6j98Ty99vp55/aO91ncr+xwEhs9RpoC2Ts+ ovYEtTy8gykGsfbX0lJV19LTiMWajRm+iwamRikqvjr38yl+nca2HKkxS5WSOLJUfjiI9Pd8tQiI kgj8RCVXv20gt8fIptq/NGZjhFTvQRH8KVfN/wDH9eltrXvceS3l57EHmlsZzfZXV/mX4rWfREBN bb1WZUaWtFU2DtakM4O6NWkQCLatzcxG/dIiXbNBSamaRmkCQK+mONc43s9i5Pt8MWRex+c2+SNO 9YiQNGRD1eYUXYhq6vmqp0peyGZLxiQ8h0z2Sb3ISp8Cdp+H7aS8vmHq6d9JR7eFI89vNDTOm95T n/0I2bUFovVzzHF4+3PY0nIXUloe6DCNYFZFTacA8eOrem2H0EcR3zA6TEe/u4uyyRi2O3CRbm8T GQy23V3waEQ8Qqq/0i8vxdXw6T2hu4To4yHLpSZEQ01n+pPj1fl5y7p0NUn/ADjtVD8qvKfd+xZT dVbp6Nbur3WdUYTaKzxl/wCvNbN2kKjOMBbrA8WOwWRaSdIot011ViVx8ghklQiz5cn2XkTPbpeH 7o3HCPKKO0JjUnZjiIVjT1EJl3DBBEiqLyiO5a+mT0vWLLOBeCcYw2DjM25uzLWFylGyqAf5hcSN 5WDqGgexHSO0ZmQCFPmIqQJIKnpmhQIJuKv5bVxo5k8uMyriBzPQrbECgsh9tTkGrCTRlV5Jdb1M /SdqpAZh3CCfe44186zWK1soMDJGWTc3rIe4g9vfpqEesi2qWgRJd6d6R3PTh5ByTll1Imb5x/Mc ZZp7Qv8AYeLvki90gI2laFtEp/F3ASRD2Ijpa1Jbovx4rHmXpu1U2AsUe58k/HhdSPqlzc4WZNt1 6kcLLFW21ly7UVe/cYV4CzJpIq5NVqkTVJwRgfUNrxrj60eofCbhYbLKZLlfGyX6eR5BuUAiLtC7 V4ibR7tA78AkwDpEJITfFHKnMN89N3JEDJLtDeb4XzAUclQxpMrNdhQfqCjUUh23gofdjjSDpd82 hEx2JrP+mNlJ3NvRJyPuKmwYSYRrTOrviknNkjpvC6aTeLj2pKqOAWNURynlH5CDtMSIfm5w5fLd nv8A5WGIzmrgWWMSPpwjqjpPi7VsIAHmQlKmmnzeCj8On3/PMLPGzyq1vW0cSlR1knKDtDHNjbcn XCpEVSneqvxEtxUd+nUmVY8LKu9sNGrexdzsZTdWfqrhtHVLR4pOzKFBhWwvnVah5Rvhx3XbAJ4R NBRQQIFTNIRFDuV6/wAb9I+P37KbDi+Z5aw5ym899RdLX3e6bUBukzYB4aqZqD0q2Z00kZglLBEf DuU+qC+WrHLzk2H4xIb4xZb+nttyo7QHOcqQXzYKneIXmAhHeoQAyqdpCaXS2yIDZVO+5VmmXmiR FfkVKihAX6mSFFk232NqzT7Y6GkRFVaESRWBJu6S7my3YXpEQjyYqFBi26Gzb4LYswI7QttNglIg 2CIIAI/CgiiIKfLqKGVKkTpTk6YZOTHnCMzJaiMzWoiIvepEu6rpXO7H6f2f4OKal+wv3Lqzsf8A JdeNvuvKPtKryVK2LVIK6VSXDASMBYY5vJRrnp17FCRXEsJrpZLOQUDIqBnPUSxzHXa0Wu+wTtl5 YZlQHPM24KEK/sX3/KvtTWw4nl2UYLfGcmw2fKtuQRy3bfjuE04O/tSofMJfEJbiXvTTAW3tE+CT ad+9Z1RJu0vVwtivPLxcXFYwQqYVyn9nKX9Im5duBykWSS7Ph28aIPTtxOMr6pbe4Q/9tX3la/wV +X7vl11s9/EL9VT1r/LPz9ltymn6gIMMZXs237va3q99SJVV476VfS/mN403Hd0/4i6i+oQmdV11 4k3KFg2LDXXoVVxHxUtWqo+avP8ANOa+T1MVMA1Bt8inpqn2Z5n8Z5Iwm5ZQ9x5jtQybeyu1ACkf ZpRE2miFfEgqH4afNSS060Hkr0481Y5xjE9QvIVJW2/TAUu++Z3GqULjrUiUBh0jIoJRUnVd8QrA ah0hHlj7ks/4h7jZ0zYHjXcpDVcu0ZlXdrRdmjEkrM7wkivOIQkWvGlHKuYMFxA2jmRauj6ep2im Q55qnIHNUvjvIgtt2sklywuCNEoXR/FX4+2NNNQb9QEYn8Xl06vAPovtXqH44cyTEs1trOeR3D+o tbsZ0ljBUQsE86LncEX6ahdCO60nk3UxXTi9e7L8SvcG1sm6j2VS2zXIiRbPJWlXeDarWCmTvoLJ ofeq3JCs5iXuW6ygpLp9zdce70lVB+PNzs974+5esyOMBHuEJsxI2XgTuMObdPcaLqAtt6STpL4V XTOZfhPqC9ImZlHlO3DH7zIZIGpsJ8xjzGKhq7MhqkXQqQVICpMFprAC0j/udeKcnv32z/Kbxe0d W4qKnbNp14y13UYRk3i2LyZqMhFW+ErUa1agg2RczjitgyR69oequPeWB6lx6OOJNrxLJLa8223H tUd4RpAUEAAhIKqR+EUKr+7rnHNbje8tGZcb1JkTr3KKs3XjJ1106q+ozUlJSXX57PtwWv2R6TSt i6992rxv22W+and5VWBucMexlAXr6bNizV1zYaXWbLAPqvaqrYY51kVnDQknQPO1VVAkO0+vMxj8 iS5TMzBpcb8ucbSoCEPNV5xMhKoSQh+Lpp+KrTO2B22RGXIlzCQLgkXUBmIl7PhQh6v3+3x2p1NB EWD2xNgey77yN+9ubx02f4+RLSrVGlXh3s+QskitsWvxEo0mKHaIl1K2S0QrMMvJSXbrMGzxV0yM AJx2iuhjjdvNZnD5AsEXLpbMo6jMO0KJQRDS4JUiJeWnxIaS+HylrZYpWx61yStzbja1APUREpDX 0/b8VXT/AGfm0lXta++l4c+BHtFSfj3ZX9yunlIhNb7c1bVlbp8wpFPH2wJyZdU51LXp02Rq7GHI XqSzz0lnD1MO4Qbmfy8yGbcaX/J8+G7M9tuyUsVOkY1Uh5qQ81Xy+UfveGkFlv8AFt9g+lVHCmU7 CNJD1KIj5i+99mmyePHhhuHx7/8Anm9zjyN3NWZihj5PTvi4nryAs0e4g5eSo2v94U1ZG8OIt8KT 6OjbVO2x1iPFYANdq3BcfkVAizN0yK33XlizWiAYuLDGVWo9QibjDnRV90R8flqp0gS2OxsWlSjE h7xNCifdF3p/zU/KS+zp1Lf7AHtA+3t5EeEvjL5q7P0qVo8iYbZU5b2V+TvV0YgjZNXbOdOKa8+x xc40gyCJUg22MokgQK+l8+C7s80HlTPMpteSTLDCfEbWTIjT2wLpMOrqIavGpffrZMXssQrYDhd4 TFwvDuGI+BfLVt+vVxWejFpiEmYhvKP4VxLxUhGoTMZlEZKIVfM1WqcnH5cJrNhfMCVwqjlQDHCg Y7sFj4c5ymRzlRHYjbhsm42QCYecKk2rHfdKh9qbj7U05FqmtW26Rrk8w3KajyAdJl3ftOiBiStO UqJUHtSexIVKrSqaqd+T/jN7ZPiBd3Wsrqw8vdq7RbxzOb+0IzbOp19+1kv5jeQVuT2DhGL5m4V7 xNaNRf8AYqBpn2mJDyOzknFOBOJ5h2u9t364XqlCo/CaAqh3Qu8rQ7ivzNA6lQkPmEtT88G82+t7 1E4uGcYy7x5YcGJ42O6TBypDZNeBAkMH3zAxSlRCSceoCEx3FRXSB6nu3icls6vKWfxXSYabJYmc 6yDZ2wrVfGbZxnGG8+Ms4k4yPkFov99Zkizbg4S6iJCfZnnMcTkHiFMxYK+4xThpHS6IzJTkhBX/ AKtXcBsiDzKAtALg1D0lSQuxn2Mc/OYPLCx54T3I9NbB/lsCLBMh8zHaFp1xsXfKDxvOE2VJFUNW pcvJCW0t4dwmlb54TxdRq9m2g1nJD/XccmVq+6a7QZsO6MVGecSLb6aVmnjcywYCqkqwIflISxx9 ufcnwr0/2nHco9PTUWLe7wL7n1bf+6rhILY9su/3RpddMS2JKxNjbpUSTUe/DNv5M9RVzybFfU5I uE6yWNxhv6Fxfpe1cCNz8VOwgFU0yBimyqBC/V1ISa8nTLN5AeSutd0b/bu6nHbL1ZFxECzu1bqc TBXGcrK7R8+ukK3m24j9FIsYUmxt1kRB16fqtwMcK4HjT2XIeZ+b+Pco5jiuwI+bY/HaaCXHitMT H4pC6UxoXwRKHWmKCZMEF0myNkCGsdbBklk4l4UzbGuJHmp7+E36Q6+cKRKdfhsSRIAhvkwXnaN/ uC4BqrVVDxCSt6ZBSLbYKNbYG+VyQWb2aAmm1gZSaqiiyq75FX1VvrlFcmq8Rfpkaa4nkvWSVIS/ e5wXjWaZDh2YQ82s8hxvIoMoZAGqqSq4JVFX8wueIuoXnEiQtxVddP5Nj9oyjHpWJ3pkSskuKUc2 kRBEQVKRoQekCbWkm9vIQiSezVpvS214LdetazsOvZEEJtmIyTDvE1oaca9qMxDuO3PUVGL3BCBF 0yolkFOnQ8c+kPiLk2y8v8fW7O7Go9mWz+K1vuTEgOl9gv7B+VV8TbUD2pLUEfJeA3bjPNJuH3ZP xorn4Tm3S8wXU06P6DD2/KdQe0dKp2F/v/7sf4eORsvyJ/y/0a0SovsHWNwjhdBVEjUTFZJRPKiJ 5TVD1MZHuTUx0yCg/ln8s8uGFYKH269tOdpwXUQSpJF8fFPD7U96ap4+UPlr7gtFs+wND7L2zsCv w0NPT0Ci5Rr8ZV5my1fD50nEvMW6KYJrSTOUisAX1DNf+YPd8/d3Y5G/nXIPL9qnTMTvlwmMxm3j bqoFo3WtyoXugPiJh8QF1fNr6LuC/T76RMpslo5WwqwWmZcpUVh9RKQ7KZjSqBV0Po3XCRo2nak7 brfT09NNOnRezB4x7MzuR15HT9bmKzrqv0ydgqtJzTN5HFd521EzbmtBpvU0lpKEjI1Bc13uO9E3 CqQgRkKnZvnpowa+Lka5nMZcZsrMUwaIxUe+btKdG/mARqqPy1EKDutVLF/xKOcMJTjcOGrRNjzs ymXJh+U0yYOfRMRayQX1BVFp910gEGfAxbFxSQUoqmP9xPRdg8hvFO/UGlVBlctgg6rk7RmTqQYx KzGZiZ6PWePmEhIkm0ReFXyeI4AzTFcVsp92O7nSPMeKTcywKZaLXGGRd6mjYEiEKTBwdyEi6d+3 WPtSrenUcXo65UtPD/PVoyzJrg5bcPJuSxOcFs3RNl1hwQA229yIPqOydQiVFFdPTqr/AOFMvvbR Hmjr2MqdPvLa8s7nFUfZ+vE4aUCTdUyYlm0bZGdqixRIWzCIbuvuDd44x6DdVAFQU7CzkuF+MZGW YryXDj2+NKG6jKBiVHoKomDMRdF1PhEBKsTLpEhEhKnU5HqZt3FnKnprvE6/XC1uYw5bXZtsuJPN doZjLROxziu1dRukP05tB+IYmQEFSJtdn5J5r5l9Nd2H4TeHu3Lbm+bQ8XtB7Auqhio4tdt1RSZ2 feqCWSFSQlJGFXeSJB+WVzU5mIeSZBAjfSw5spuN8oumI/sSrp/u6Ru2+C+XcdZbI/tpTSt51Hqk qE41WesdelrB00KPda3KmVvNCdMDUFYmTin5jc11ZoSyeDymTbs7x7unEKzpyyvru899b89Zdz/H vV/zav8A07CN9mgez8uyU/u9mk8hfETxQrj9rLV/xi8eYGUZKCqzkoXS2t4uQaKgXcCjV4xrKDlu oJfHGQIeK3L/AH98KHpswm/lJ5xU/wA2k4263tlU2wyJfoAf6NLDbabUb/X31TvdUrd1qsp9PiTr Vsg4yyQEj9I6RetPr4aYaPI159M8bJLJ+omXYqAkPzDjPMdHkyIboyIpuNvj5SAiEk/vD1aUuNNv DQ6IkH2Em6fu1jptHpeu4BrVdf0+r0WsMTXVZVum1+JrEC0VdKEs5Uaw8IzZR7c3CxZM8gmPeeeu fjysiTImOrIluOOvF8RkRF+8urQ202yNDQiIfYKbJ+7XreWtXNRt+57ojT+0vGW6XrYjT7bZtRwj +zUS5RyTfE1GShkignXyUVxj66CsrpRNu4annt7iFUOigDnnOfqew/Fr/wAWXG85AnbmWuOrsd4U TuCe6CLX3m3SURIfhKkx6h12X6HOVeRME5ttmK4efesmQygjToZkXYda6i+o6fI/HGpxt1OrzAVQ EuqsdbjMAmkSg4DOADJY6/DGe3uz+rkFd1lbmQj46nfvU6syQV36tWANQbl094leJWpq9fqXnYOy b1CSuyIipPYNFwzbxttlnLpgo5nZpk4jYuM+jST70Wv1Cvq4IiSHJ93JGcU5b409PHAFiteaW385 zO6RnZ7EU46EAtSHS7RG++BA02QCO4Ndw66iJsa6tRIciccci+oH1A3+8YpcvyfCrXKatzsoHiEy diNCLiCwwaOuu1qWxu0BTSIuFTTpi2zvInYW18O41ROEoNHcvlJAdc66i29Xq6joxEPrJtGOBu4s cl6KYBlZ3k/lAe0R7cc4F5R9QWZ8jC9a20i2bD3Hlc/Lrc0EWKpqlNbotCKyHKaUI3ycXpHbbZNd TYPw7h+AduY2sq7ZO20jf5jcXVlShFPgYU6hjt7qq0NbeJL1LUutronxs2j5ASptKPEAjCMnAt5u 4S2Sb12FznAnlFRYRJeQkPRLBC1bianxwRdg/NxJwt6eOR+dbqUfEY3bsrLgjImvbhHY38VGpEJT dp6habEj8RqpEq9IOVOaMH4jgpIyiQpXNwKmIbXVIe+8ieVturwV1ykfag1F06sBeNfjjAeN1PeV mGnpmxPpt6hLWCSk1vSaLyiTf6fKkTDpGTWJbZTzgc4HJqq4EcqGWcY6TnenzgOxen/E3MdtEyVO lynBdkuulSBOiNO7LCVC0Oy7eYjIUGsypGmJDmrmW78z5G3erjEiw40Vsmo7TQ7mLSlV+K6vU6W/ j47CO5UCO+nHfH9OP15/xcfzdPsLTN9f6P3f16yc9arrVSUPEzCYJS8XHyiSZeomlIMm71JNTGCH Cgg5SVADxgs464/Tyy9HjyEpfbbcD7woX/HSuHcZ9uNXbe+9HcIdlJsyBdv7qprupJAiAJpgCaSY CCaaYiIJgI9uMYwPQRERxjGMYx8OXkRESkfLpKRKSqbi1GXiqr79djhqmtQhDxLeTdzSETHITMgg g2fyyLJqEm9bNOv0zd4/BIXThFDr/LAzIQ/hxxOMaODxShbAZBCKEdKVKiewVLzLT7tLHLjcHoTd tdfeK2skRA0RkTYEXmIAqpEi+IhHcvfrb8UaR6OGjRw0aOGjRw0aOGjRw0ah/wDeK2QMHo2k6sau MA/2feGy7xuKhCspXacj93eY7MZ/mIryazNPOP73OG/XbmSWPjOJjDBoky6TKiHfq7UcaiX9XdNr Uh38ObDCunKNzzt8FWJY7WQgW3gkiYXaD9Si0Lpfs1DdqTxb3jtNxGNqnqy7PIqScs27ieWg3MTB tWLpwmm6e/dpfEexWQbtcmf8szMu35RzyMPD+E+VeQJ7LdhsdycguGH+4VgwYESXz950RaKnzbI5 vTqR7kDnTi/BWX3sgv1rbnstmQsC8Lr5GIqoh2mu4aERUj1CKePUSatL3jx31jsnV0Lqm519tIQl fhY+KgnrfAtpevrR0elHt5KCkBHK7F0IIY6/ikrjHaYmPw5OFmHCeA59x/H48yuG29aocVtpgx6X Y5A2IC6w57QLp8U8RP2GJD4aglxfmHOcLzqTnuNzHGbnMlOOvgXU1IFxwnCbfD2GPV/aH2gQr46g W8kfEHYPjnJKvXAr2rW7pzlKIvDNt24b4VLo3j7Q1T64iJLt+UVM/wCVcF+4Xd8gwjeoz0sZtwTc DuNJXHA3XKWJwD5Kl6GpQJv2Xfh3/wBNwvFst1oSV7hj1EYjzJCSM1TBzNtup2EZebb2nFNf9Vr3 qP8Aqtp5hp6tJzpba219UWdKb1RJTP16ppC+g2TR7Mw0+iJ//jmINqKoO+7HwFQBBdL+Ax42XDnK PKfGGShc+NHpX1ZEPdigBusyE+R5gfA/ul0mPjQYrrceS8AwLPrGVsz9mN9IIrQ+Zgy8wXztPlTR +kV3AviFdWEvHXfE1ueANS1awvGtLRHoIlItrBXJhjXZLJ5wP1VbmpBo3w7RIs9coq4FdL+/j5uT xcC813XluzKeR47eMfyNltCdGTFfaiu/DVFfdAa0q3qbLrD7THq1EJzFxVbeNbsg2G+2u9WR4l7Z R5DRyGvuyGGzKgvvjUBfdXp05Ltz+n/jn/DzoLq/kv8AVpmf2r/NrLw0aOGjRw0aOGjRw0aOGjXU kH7KKYPZSSdIMY6NaOX7966UFFszZM0TcOnThU84BJBugmRmWc9BHGc54nly40CK7OmuC1DZbJxw yVEEABFIiJV8EERRVVV8ERN9Xo0Z+ZIbiRQJyU6YgAim5ERKgiIoniqqqoiJ71XXYTUBVMFUiwaa oComY56iYGOCAhz+eCHPXHLwGLgI4C7gSIqL9qL4ourZCQEoEmxIuyp9iprqSMnHxDXL6TeN2LMV 2jYnLlQUksOH7tBgyR7y6Y9R09cppBj8SM8Yx8c8TzJsS3sLKnOA1HQgGol2SpwxbBN195GQiKe8 lRPfq9FiSZr308QCcfUSKkU3XYBUyXb7BESJfsRFXXe4q0n1orHaK5UI37xap2KrsThy2Z5kpl83 jmIuniuEWqBunSiSIGurnoOM5x15irzfLNj0P8xv0qPDgViHceMWwqNdhFSJUFFJfBN11kbXaLpe 5X0NnjvSplBFQ0BGdIpuSoIoqqiJ4r4awV+41S2Q2bFWLJCWCCHCmTloaTaSLBPKSIOFQVctVVU0 lUkFRMgLOCESxnOMYzjlq0ZHYL/bfzixzYsy1pvu6y4DgJsiEqKQqqIqCqKqLsqIqKqeOvdysd5s 078su0WRGuC7bNutkBruqiioJIiqiqioip4KqKiL4a0MnH60mndTuU3GU+VkXGGsfSrJKx0U+fZx OgL9s0rsk8QVco5lE24q9qBDlXCeCz1wOOmOmx8MuL0DIri1b35TlDcOQ4DZn+N1iMczRSTuolWw KlSDuu+3hlIFwzK2xZ2P22RcI8LxOXHaddbbVWehSfbAkEu2pKO5otNSontXdQcYxj4Yx0xj8Mc2 pERE8NavvuuvvK6Na+Qjo+XZOI2WYM5OOepEg8j5Bqg9ZO0Tx86Llq5BRFdIvzEhzjPEU+DBukM4 FzYZkQHhUTadAXGzFfaJgaKJIvvQkVF0ohzZlvktzYDrjExtUIHGyIDAk9iiQqhCqe5UXf8ATrFG wkNCIC2hoiLiWwdBBvGR7RggOP0Ck1RSAcf0Y5attls9oZSNaYsaLGT2Ay0DQp+oQEU1em3O5XR1 XrlIfkPL7SccJwl/Wpqq62vMlpDo4aNHDRo4aNHDRo4aNHDRpnV40/uW73i+T7C2lV4ZyTiLqUcv bbW3QOPxSW1fUcKxNbkvtTdvLycrIOMuCAJNso3QIOn485zyjjvkjJ8nut2iXBYNtNSaiNlKlCKt /RDHUlajOdoReddfcVxUSS2TbSjt7dPhj+bYNYLBbrbIhJLnAiOSDSPHJa/qieQUcfDuKTbbbIUI qsOCbiFvr5jxuuc5X5yKvGxpaZcPo9jBRaUbbb+whY6Ec3SelrEmqyXnXT2TdFT5gIpkT9w+NNNH GFFCwWS5ROGMkudolQMovMiS86yDDSNy57bLbJTH3ZCKBPkbpfSPJFZV9x9RENjJUVV0f/1KxW+5 R5mP2tlhttw3XFONDN03RitNsKhIyItj9S2sh1GQaRSLcRRURNdAPHfbTnFsRktsSwNZaft01Dox l1vbcUUXcVbmNQjnZYXTeM2zVaxoFJ5brkbsGKWMFnI8SDw9yA+lwbm3+QjEiXLeZFuZOFEQ2pYR Gz6kMBFZALJ7ZqrqMNpv4aUlybhjX0RxbMyrzMaM06pxYi7qLkY5Jj4KJESMGjFYIjaumu3jrOlo bdiLmeNPazfDV6q4OPSKXu7glzavnT6Bfy6L+TfRyTxoDKNbKAwQagogLnKuVzVEsXQ4p5NaflkF +DsOkStors0qlEyNg3kN020MECM2SMA0hAjyuK6RoqWy5EwJxqOJ2cu82iVqjcVNkIBB4G1BsDUS U3zFXjcVDVqhGxBU17Oj6SuFO2gVhxfpySobKrsYaJhpG3WyWlnMonFi2fylmRl13sZNLLyS7hyk eTD0ckAinjCY4xsuMcZZFjmcrePzaU9irUEGWmXJcp10nUaQTdko6RtvKTiuOCu6UbiiAiAO2Cv+ fWS+YilsW2x2siclm646EaO22LauVA2wraCbSICABJstWxKpbku6evPGfYM1CnFTN5ADbi8cIKMr bf1vulpxSbXW077JKuXgLMZWwS1ibu38ch3skAjxBIlPWV66hJ4Ty652xYFyuiIQIZCoS5692V9F KjJOcUjRQdfdkNuvxw3ZBI6A2R91zfZWOVsagT0mQbeqoSiioUeGnbj/AFUd9YgII7G2y2ybbLx7 OmrykaDQGt0noHY0WrJMoW7D9nKuWaBrDl5br23lKuEg8nmsIRt45ZJhZ8sa4tFI98llYmyjEsIj 0yBjkg4mzKC4/GttzT8uWHJYjEcucLsZHDfFncW1RuTRHWKFUitWyYVG02USRAXI+LywafnwF+t+ qYefEY0Qm5CgLJO9RopsVvpILZilDF1K13QkXZ6/0fsGDuKU/cLunYodje7Bbo6KzLWF+2at3EZb IiuIM4yUHLGLeMWdqLDkkjIVPpkcD8Bx0X4lxfl9ryMLtkV0SZbmrs/Lba7shwREm5TUdAad6GjA JS9xQVULtt7L0ppFkXIGNXCwrbrJb1izXLcxGNztsgRKhxnH1JxvrcEyjpQhIip3D39unYcfzTO+ /Rw1XWPH5f0Y/ZjnhfYn7deU9ifqTXIvw/r/ALOXE17H265cpqmjho0cNGjho0cNGjho0cNGjho0 cNGjho0cNGjho0cNGjho1jx+7/Vj9ueUTyp+v/11QfYn7P8AgmsnK6Pfo4arrHj8v6MfsxzwvsT9 uvKexP1JrkX4f1/2cuJr2Pt1y5TVNHDRr//Z --=_related 005D40A9C1257A99_= Content-Type: image/gif Content-ID: <_1_0D712E4C0D712A78005D4019C1257A99> Content-Transfer-Encoding: base64 R0lGODlhbgAeAPcRAD+J6O/1/d/r+5/E8y9/5g9r4s/h+R915I+68W+m7q/N9V+c7E+T6r/X93+w 8ABi4f///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAABEALAAAAABuAB4A AAj/ACMIHEiwoMGDCBMqXMiwocOHECNKnEixosWLEyFoDEDggcePIEOGTKCxpEmMKFOWdCCypcsH BkyeTEmz4sqXLgksYPmggcySNYNKvInz44EBATQK8OjzJwShUB3eJAChwQKXDmQ2YOr0adSvCYkm hTBA5ICfPJv+BMvWINGzGnl6ROD0AFenbfMKJFogJoQAHwE43Xp3rd62RB8UaAqgsMmOjmceBpvY I4EEHQ84TQBSrczJbCuPRBvSs2TQUEWDVGBSQOPSXVF/Vf3RZwAFV1uaBio7ddyXBOzi3K2xt28I cou6JO7VeM2Sr5Vjje38OQQEihM42M69u3fuuf1+XK5OE4KBAg/gdl0PgcEDAmNPk78IAbL0oiTH z8eYvGUB7pwVZdp+KN1noGDyETiRfQbilFWCCkYUgAMAVGjhhRhmiKF6vEVIEXsghlichx+KaCJe JKao4oos9hYQADs= --=_related 005D40A9C1257A99_=-- From jvasseur@cisco.com Tue Oct 16 10:18:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455D321F87CC for ; Tue, 16 Oct 2012 10:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-WCtjTo+LBb for ; Tue, 16 Oct 2012 10:18:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5961A21F86B2 for ; Tue, 16 Oct 2012 10:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20704; q=dns/txt; s=iport; t=1350407881; x=1351617481; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8TAJb8kPqSH+cx2FckI1U/pE43flgieTlpSY/du2j5o=; b=mzVTitekoq68pUEDrbcTuwMTDny1ppCaYnGd3skreWpvsXEdx8MeJ989 wkDlQWbIT7im6JefdpPMbF65rURucFZRvz2Loy0FyZhE5dAKjKKiQgl33 10LyxzrDotvOhh4oQBINnk8bmzR2cWRn215+x/xIH37l9yYdU8RaEIoIV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAEOWfVCtJV2Y/2dsb2JhbABFgku0XwGIWYEIgiABAQEDAQEBAQkGAVgDBQYFCwIBCCIdBycLFBECBA4FCBqHXAYLmw2PXJBPi08ahUNgA5cAjTKBa4JtgWM0 X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208,217";a="131981720" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 16 Oct 2012 17:17:56 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9GHHujq018180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 17:17:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 12:17:56 -0500 From: "JP Vasseur (jvasseur)" To: Cedric-2 LAVENU Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNq8IuxQdayxYbx0aw5eRdXfbe8w== Date: Tue, 16 Oct 2012 17:17:55 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FEA88D@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--49.211100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FEA88Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Stan Ratliff \(sratliff\)" , "" , "Bo Berry \(boberry\)" , "" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:18:03 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FEA88Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Cedric, On Oct 16, 2012, at 6:58 PM, Cedric-2 LAVENU wrote: Dear C=E9dric, I'm not sure all this discussions really make sense : > An LLN network is definitely a type of MANET according to what Adrian sai= d (he has been quoted several times in the past mails). One of the fileds L= OADng is intended to be used are AMI PLC networks with low bandwidth (few k= bps in the harshest environments), but can be extensible to other types of = MANETs. And regarding your comment about experience with LOADng : > LOADng is a protocol for which several running implementations exist and = interoperate as shown in draft : http://tools.ietf.org/html/draft-lavenu-ll= n-loadng-interoperability-report-02 > In addition, LOAD (the previous version) was successfully run in a 2000 P= LC node trial. I think that all the facts are on the table to say that LOAD would be suita= ble for MANETs (LLNs being a subset of MANETs). In addition field and lab e= xperience does exist and demonstrated that LOADng can be very efficient. JP> Note that an interop document is certainly extremely useful but cannot = be used as a proof that a protocol "works" especially at scale. I think that Cedric was looking for performance numbers, under which condit= ions, etc =85 That being, all I was saying on my side, was that if indeed a protocol is d= esigned to cover LLNs, then it should be ran by the WG in charge of LLNs. As you pointed out, AMI PLC network are definitely highly constrai= ned LLNs, with flappy/lossy links, low bandwidth, =85 Regards. JP. Regards, C=E9dric C=E9dric LAVENU Research Engineer EDF =96 R&D MIRE Department 1 avenue du g=E9n=E9ral de Gaulle 92141 CLAMART - FRANCE cedric-2.lavenu@edf.fr T=E9l. : +33 1 47 65 27 29 Fax : +33 1 47 65 55 56 Un geste simple pour l'environnement, n'imprimez ce message que si = vous en avez l'utilit=E9. De : c.chauvenet@watteco.com A : ulrich@herberg.name, ietf@thomasclau= sen.org Cc : sratliff@cisco.com, Chris.Dearlove@b= aesystems.com, manet@ietf.org, boberry@cisco.com Date : 15/10/2012 18:01 Objet : Re: [manet] MANET meeting at IETF85 Envoy=E9 par : manet-bounces@ietf.org ________________________________ Hi ulrich and Thomas Le 15 oct. 2012 =E0 17:22, Ulrich Herberg a =E9crit : Hi JP, On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) > wrote: [...] JP> Here we do not disagree at all. I am not saying that reactive protocols= are not appropriate in a number of scenario. All I am saying is that *if* = you intent to specify a reactive routing protocol for LLNs, knowing the years of intense work and= efforts of the ROLL WG, then it should be discussed with a wider audience. I agree. But that's not we are intending to do. We intent to produce a reac= tive protocol for MANETs, which is requested by the MANET charter. LOADng i= s a protocol that covers all the use cases of MANETs, one of which being LL= Ns. And yes, the introduction and title of the draft needs to be changed On the other hand, if your explicitly exclude LLNs from your protocol in your protocol, = it is no longer required to involve the ROLL WG. The objective is simply to= avoid WG charter overlap but more importantly try to benefit from the benefit of experts in = the area of LLNs to build a good protocol for the Internet. I am personally against removing to mention a use case where as a matter of= fact the protocol is used in (as *one* use-case out of many). Citing Adrian from the last MANET meeting: Adrian Farrell: If you were to pick up a reactive protocol for MANET, you w= ould be in charter. If you pick up a protocol and your main use case is for= LLNs, you have diverged from charter. Main use case is delicate thing to t= alk about. It is clear that some if not all LLNs are MANET. Not all MANETs = are LLNs. So you need to be producing a single reactive protocol for MANETs= , not for *some* MANETs. You need to be clear that the protocol you work on= is applicable across all MANETs. If that picks up some LLNs across the way= , no big deal, but it should not be main use case. Look at all use cases fo= r MANETs and make sure you address all of those. You'll not the "If that picks up some LLNs across the way, no big deal, but= it should not be main use case". That is why I asked in a previous mail the nature of LOADng deployments you= were talking about. I cannot find any material on this. If they are LLN, then it seems in disagreement with what Adrian suggest. This is exactly what we intend to do. It was also agreed at the last MANET meeting that if LOADng was to be consi= dered for MANET, it needs to de-emphasize LLNs (which I have not heard anyb= ody disagree with so far). So I don't understand what we are even discussin= g here. JP> No, this your recollection of the discussion. "less-focussed" or "de-em= phasize" was I think your interpretation. Mine was "not referring to LLNs" = at all. I sincerely suggest to wait until you read the new revision, as this discus= sion is hypothetical without that. Agree that the new version should be a good point of discussion. Best, C=E9dric. Otherwise, it should be reviewed by both WGs (to be discussed between chair= s and AD). Best Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') sont = =E9tablis =E0 l'intention exclusive des destinataires et les informations q= ui y figurent sont strictement confidentielles. Toute utilisation de ce Mes= sage non conforme =E0 sa destination, toute diffusion ou toute publication = totale ou partielle, est interdite sauf autorisation expresse. Si vous n'=EAtes pas le destinataire de ce Message, il vous est interdit de= le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou pa= rtie. Si vous avez re=E7u ce Message par erreur, merci de le supprimer de v= otre syst=E8me, ainsi que toutes ses copies, et de n'en garder aucune trace= sur quelque support que ce soit. Nous vous remercions =E9galement d'en ave= rtir imm=E9diatement l'exp=E9diteur par retour du message. Il est impossible de garantir que les communications par messagerie =E9lect= ronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es de tout= e erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for th= e addressees. The information contained in this Message is confidential. An= y use of information contained in this Message not in accord with its purpo= se, any dissemination or disclosure, either whole or partial, is prohibited= except formal approval. If you are not the addressee, you may not copy, forward, disclose or use an= y part of it. If you have received this message in error, please delete it = and all copies from your system and notify the sender immediately by return= message. E-mail communication cannot be guaranteed to be timely secure, error or vir= us-free. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FEA88Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0F2F2E847EAEF048A7524B577A2984EC@cisco.com> Content-Transfer-Encoding: quoted-printable Dear Cedric,

On Oct 16, 2012, at 6:58 PM, Cedric-2 LAVENU wrote:

Dear C=E9dri= c,

I'm not sure all this discussions real= ly make sense :

> An LLN network is definitely a ty= pe of MANET according to what Adrian said (he has been quoted several times= in the past mails). One of the fileds LOADng is intended to be used are AM= I PLC networks with low bandwidth (few kbps in the harshest environments), but can be extensible to other types o= f MANETs.

And regarding your comment about exper= ience with LOADng :

> LOADng is a protocol for which se= veral running implementations exist and interoperate as shown in draft : http://tools.iet= f.org/html/draft-lavenu-lln-loadng-interoperability-report-02
> In addition, LOAD (the previous v= ersion) was successfully run in a 2000 PLC node trial.

I think that all the facts are on the = table to say that LOAD would be suitable for MANETs (LLNs being a subset of= MANETs). In addition field and lab experience does exist and demonstrated = that LOADng can be very efficient.


JP> Note that an interop document is certainly extremely useful but= cannot be used as a proof that a protocol "works" especially at = scale.
I think that Cedric was looking for performance numbers, under which c= onditions, etc =85 
That being, all I was saying on my side, was that if indeed a protocol= is designed to cover LLNs, then it should be ran by the WG in charge =
of LLNs. As you pointed out, AMI PLC network are definitely highly con= strained LLNs, with flappy/lossy links, low bandwidth, =85 

Regards.

JP.

Regards,
C=E9dric
<Mail Attachment.jpeg>  
C=E9dric LAVENU
Research Engineer
EDF =96 R&D
MIRE Department
1 avenue du g=E9n=E9ral de Gaulle
92141 CLAMART - FRANCE

cedric-2.lavenu@edf.fr
T=E9l. : +33 1 47 65 = 27 29
Fax : +33 1 47 65 55 56
<Mail Attachment.gif>
 Un geste simple pour = l'environnement, n'imprimez ce message que si vous en avez l'utilit=E9.





De :     &= nbsp;  c.chauvenet@watteco.com
A :     &n= bsp;  ulrich@herberg.name, ietf@thomasclausen.org=
Cc :   &nb= sp;    sratliff@cisco.com, Chris.Dearlove@baesystems.= com, manet@ietf.org, boberry@cisco.com
Date :    =    15/10/2012 18:01<= /font>
Objet :    = ;    Re: [manet] MANE= T meeting at IETF85
Envoy=E9 par :  = ;      manet-bounces@ietf.org



Hi ulrich and Thomas

Le 15 oct. 2012 =E0 17:22, Ulrich Herberg a =E9crit :

Hi JP,


On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) &l= t;jvasseur@cisco.com= > wrote:
[...]

JP> Here we do not disagree at all. I am not saying tha= t reactive protocols are not appropriate in a number of scenario. All I am = saying is that *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of= intense work and efforts of the ROLL WG, then it should be discussed with = a wider audience.


I agree. But that's not we are intending to do. We intent = to produce a reactive protocol for MANETs, which is requested by the MANET = charter. LOADng is a protocol that covers all the use cases of MANETs, one = of which being LLNs.
And yes, the introduction and title of the draft needs to = be changed


 
On the other
hand, if your explicitly exclude LLNs from your protocol i= n your protocol, it is no longer required to involve the ROLL WG. The objec= tive is simply to avoid WG charter
overlap but more importantly try to benefit from the benef= it of experts in the area of LLNs to build a good protocol for the Internet= .

I am personally against removing to mention a use case whe= re as a matter of fact the protocol is used in (as *one* use-case out of ma= ny).

Citing Adrian from the last MANET meeting:
Adrian Farrell: If you were to pick up a reactive prot= ocol for MANET, you would be in charter. If you pick up a protocol and your= main use case is for LLNs, you have diverged from charter. Main use case i= s delicate thing to talk about. It is clear that some if not all LLNs are MANET. Not all MANETs are LLNs. So = you need to be producing a single reactive protocol for MANETs, not for *so= me* MANETs. You need to be clear that the protocol you work on is applicabl= e across all MANETs. If that picks up some LLNs across the way, no big deal, but it should not be main use ca= se. Look at all use cases for MANETs and make sure you address all of those= .

You'll not the "If that p= icks up some LLNs across the way, no big deal, but it should not be main us= e case".

That is why I asked in a previous mail the nature of LOADn= g deployments you were talking about.
I cannot find any material on this.
If they are LLN, then it seems in disagreement with what A= drian suggest.


This is exactly what we intend to do.



It was also agreed at the last MANET meeting that if LOADn= g was to be considered for MANET, it needs to de-emphasize LLNs (which I ha= ve not heard anybody disagree with so far). So I don't understand what we a= re even discussing here.

JP> No, this your recollection of the discussion. "= ;less-focussed" or "de-emphasize" was I think your interpret= ation. Mine was "not referring to LLNs" at all.


I sincerely suggest to wait until you read the new revisio= n, as this discussion is hypothetical without that.

Agree that the new version should be a good point of discu= ssion.

Best,

C=E9dric.


 
Otherwise, it should be reviewed by both WGs (to be discus= sed between chairs and AD).

Best
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') sont = =E9tablis =E0 l'intention exclusive des destinataires et les informations q= ui y figurent sont strictement confidentielles. Toute utilisation de ce Mes= sage non conforme =E0 sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf aut= orisation expresse.

Si vous n'=EAtes pas le destinataire de ce Message, il vous est interdit= de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou= partie. Si vous avez re=E7u ce Message par erreur, merci de le supprimer d= e votre syst=E8me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. No= us vous remercions =E9galement d'en avertir imm=E9diatement l'exp=E9diteur = par retour du message.

Il est impossible de garantir que les communications par messagerie =E9l= ectronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es de t= oute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for= the addressees. The information contained in this Message is confidential.= Any use of information contained in this Message not in accord with its pu= rpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use= any part of it. If you have received this message in error, please delete = it and all copies from your system and notify the sender immediately by ret= urn message.

E-mail communication cannot be guaranteed to be timely secure, error or = virus-free.

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

--_000_03B78081B371D44390ED6E7BADBB4A7721FEA88Dxmbrcdx02ciscoc_-- From hrogge@googlemail.com Tue Oct 16 10:30:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769E521F8A44 for ; Tue, 16 Oct 2012 10:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUvOP5M1Yl8C for ; Tue, 16 Oct 2012 10:30:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7792421F8A42 for ; Tue, 16 Oct 2012 10:30:53 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so6123920pbb.31 for ; Tue, 16 Oct 2012 10:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/nJnbhz9dIT3CfzchuotUoUfjjPS4rmztFVEBl9buxU=; b=a01Be0jGI8uByKr81RuQeYxfoF0hFSzpBjW7+RbIjtWGDTHtbvr1OCP+N3+NyJ9zlj r0W35Mv+7iR5FSIl2khtVvUh9Rob81OFeFAxkcZzikzQ4CNsXwpTwXb9qKGH72cjcpT6 5afdeP0p7qz/4zn1SLM5Se5jqQMkmbee5ZoKPcFfsSac7lVrnR8OW+gns44i0KjWX5Iw RC3XMh+8h2m0QAh86Oao7rEX3hzcaVsvtcIaAina/AfaMEc71N2xFytZQfYRbAvq08Ny iG7aMFHM7K9NMVp4iKC4Izmm9wFat3bfQ+MyJtAxU2kPkt6d7Uit7YxhOHNbLcpbrcfu Vopw== Received: by 10.68.138.198 with SMTP id qs6mr49071101pbb.151.1350408653179; Tue, 16 Oct 2012 10:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Tue, 16 Oct 2012 10:30:31 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FEA88D@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <50A05995-EE7B-44DA-B157-B83D62FE2E6C@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FEA88D@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Tue, 16 Oct 2012 19:30:31 +0200 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" , "" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:30:54 -0000 On Tue, Oct 16, 2012 at 7:17 PM, JP Vasseur (jvasseur) wrote: > That being, all I was saying on my side, was that if indeed a protocol is= designed to cover LLNs, then it should be ran by the WG in charge > of LLNs. As you pointed out, AMI PLC network are definitely highly constr= ained LLNs, with flappy/lossy links, low bandwidth, =85 LoadNG has been developed from AODV, which is a Manet protocol. Yes, there are MANET protocols which can handle low bandwidth... no surprise. And Lossy links are normal for many MANET, please do not pretend they are something special handled in ROLL. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Tue Oct 16 10:53:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4884521F87AF for ; Tue, 16 Oct 2012 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX8VxkcU1N2g for ; Tue, 16 Oct 2012 10:53:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C36FF21F8200 for ; Tue, 16 Oct 2012 10:53:32 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7611493vbb.31 for ; Tue, 16 Oct 2012 10:53:30 -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=EIPRktQqseXHb7QHuZoJdijhJsDfuxsPWGTZ6mDpgRQ=; b=d0UMD0FznOVjlJhDoxFFKia20rFxL40gXpmMZrVPVCq3y3TU5LNY5G4rxyHBLJ5pu7 +IGCV5t8WNPFDPexMYN8dbX7cRAcEhunV5vUad6++hWB6JbLxRsXqs5xsKdA+TKC5Sqe /nXiy5rZi+jUFddVbYnVw5iPuXb3ac03Kl+5s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EIPRktQqseXHb7QHuZoJdijhJsDfuxsPWGTZ6mDpgRQ=; b=Fr6PiQO2Z/CQQn4JCWJwoFNFKWVEf+K/2VVDTWWFOIzlImAhRXc1zeYQumrNxTvA8C xX4YDUCOszoT2t+ROGcLaosY8pdNUq6RY9977BRqNUO7E5NoloPfO86cZHnFYDWm867X 9iLqMGo8nWKguaRKXbIexWu5LWsqHUrEAJ3QjNmHkPA1Zkzd0UFw1QYTPIo3av0EneDw 6GCSFrjKX4NLOlZ5ILv7iSdK1fCmw13G1dsJY4xgaRHV5agsuq1O8i/SlysrxewjBfSF faZ9BKju/IqgIf0QaudZg8YhBybzQfL6S8yLWGvanwyGc7IoT7b388sLf3gLO+rrvMmB VgZw== MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr7497719vdb.95.1350410010361; Tue, 16 Oct 2012 10:53:30 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Tue, 16 Oct 2012 10:53:29 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> Date: Tue, 16 Oct 2012 10:53:29 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=20cf3071c69cf8012104cc30d42e X-Gm-Message-State: ALoCoQnMir63OPRRAvwhnkMUzfYmeMh1OjKBoQqvwYkxgb3IN01mSua0/ItUYXFvnMTwXx94fM81 Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:53:34 -0000 --20cf3071c69cf8012104cc30d42e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP, On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jvasseur) wrote: > [...] > > I agree. But that's not we are intending to do. We intent to produce a > reactive protocol for MANETs, which is requested by the MANET charter. > LOADng is a protocol that covers all the use cases of MANETs, one of whic= h > being LLNs. > > > JP> See previous email =85. then it should be run by the WG in charge of > routing protocol in LLN, that excluded the use of reactive routing > after years of work. > No. The reactive MANET protocol should be "run" by the WG that is chartered to produce a reactive MANET protocol. And if this protocol happens to be used in some large-scale LLN deployments, does not mean that it is automatically in overlap of charter, as long as that reactive protocol fullfils the general requirements of MANETs. > > And yes, the introduction and title of the draft needs to be changed > > > JP> No issue with this. > Good, so you don't have an issue with having that changed. In a previous email you said you also don't have an issue mentioning where a protocol is deployed. So I don't understand why we even continue this discussion. > [...] > > > JP> I cannot speak for our AD. As a WG co-chair, the minimum would be to > make sure that the ROLL WG reviews the work in great details. > Every individual is very welcome to review documents at any time. This is normal IETF procedure. If you suggest that there is a LC in ROLL for a document in MANET, that seems like a new procedure to me that I have not heard before. [...] > >> > > I sincerely suggest to wait until you read the new revision, as this > discussion is hypothetical without that. > > > JP> Sure, when can we expect to see it ? > As soon as possible. Monday October 22 is the deadline to submit new drafts before this IETF. Best regards Ulrich --20cf3071c69cf8012104cc30d42e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP,

On Mon, Oct 15, 2012 at 8:57 AM, J= P Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
[...]

I agree. But that's not we are intending to do. We intent to produ= ce a reactive protocol for MANETs, which is requested by the MANET charter.= LOADng is a protocol that covers all the use cases of MANETs, one of which= being LLNs.

JP> See previous email =85. then it should be run by the WG i= n charge of routing protocol in LLN, that excluded the use of reactive rout= ing=A0
after years of work.


No. The reactive MANET protocol should be "run&q= uot; by the WG that is chartered to produce a reactive MANET protocol. And = if this protocol happens to be used in some large-scale LLN deployments, do= es not mean that it is automatically in overlap of charter, as long as that= reactive protocol fullfils the general requirements of MANETs.


=A0
=

And yes, the introduction and title of the draft needs to be changed

JP> No issue with this.
<= div>
Good, so you don't have an issue with having that ch= anged. In a previous email you said you also don't have an issue mentio= ning where a protocol is deployed. So I don't understand why we even co= ntinue this discussion.

=A0
[...]

JP> I cannot speak for our AD. As a WG co-chair, the minimum = would be to make sure that the ROLL WG reviews the work in great details.


Every individual is very welcome to review documents at any time. This is n= ormal IETF procedure. If you suggest that there is a LC in ROLL for a docum= ent in MANET, that seems like a new procedure to me that I have not heard b= efore.=A0

[...]


I sincerely suggest to wait until you read the new revision, as this d= iscussion is hypothetical without that.=A0

JP> Sure, when can we expect to see it ?


As soon as possible. Mon= day October 22 is the deadline to submit new drafts before this IETF.

Best regards
Ulrich

=
--20cf3071c69cf8012104cc30d42e-- From Thomas.Goff@boeing.com Tue Oct 16 12:35:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3DE21F8557 for ; Tue, 16 Oct 2012 12:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEcXUkwzIiYX for ; Tue, 16 Oct 2012 12:35:02 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 95A3121F853A for ; Tue, 16 Oct 2012 12:35:02 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9GJYlhI006252 for ; Tue, 16 Oct 2012 12:34:47 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9GJYkK1006228 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Oct 2012 12:34:46 -0700 Received: from XCH-NW-18V.nw.nos.boeing.com ([130.247.25.77]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 16 Oct 2012 12:34:59 -0700 From: "Goff, Thomas" To: Bo Berry , Henning Rogge Date: Tue, 16 Oct 2012 12:34:58 -0700 Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: Ac2qyMQt/n5fez10SiyPCPQiOL7BkwBCmWnQ Message-ID: <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "manet@ietf.org" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:35:03 -0000 Just a couple of comments inline below. Tom > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Bo Berry > Sent: Monday, October 15, 2012 4:33 AM > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Some comments on manet-dlep-03 =20 >=20 > On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >=20 > > On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: > >> I've asked twice now (this email makes attempt number 3) for someone > to suggest some text to clarify what a router or modem would do with an > UNKNOWN metric. So far, what I've seen is a potentially new *way* of > specifying UNKNOWN - one that makes more sense than picking some > arbitrary code point. But no actual text to suggest what either of the > endpoints would *do* with the data. Maybe I'm old, feeble, and not very > bright - but I'm looking for suggestions that start with "A router > receiving a metric value of UNKNOWN MUST." or "An implementation > receiving an UNKNOWN indication SHOULD." or something along those > lines. Barring that, the only text I've got to insert is what I > suggested before: > >>> > >>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where > RLQ is supported, but not currently calculable. The authors have no > idea under what circumstances this would occur. Routers receiving a > value of RLQ_UNKNOWN are free to take any action deemed appropriate, > including (but not limited to) ignoring the value, producing log > messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was > added at the request of the working group, as consensus formed around > the key ideas that this MAY allow for innovation, even though none of > the working group members were able to note a set of circumstances > under which this innovation might take place. So, in an effort to stop > the email storm, the authors added the additional code point." > > > > If we use Teco's suggested solution (using 'length =3D 0' to make an > unknown but supported TLV): > > > > ---- > > Radio implementations MAY use a metric TLV without value and length 0 > to signal a not measurable but supported TLV. > > > > Most router implementations will process this metric TLV in the same > way as a missing metric TLV. > > ---- I would suggest that a TLV of length 0 could simply invalidate a previously= sent (optional) value without implying anything about measurability. > > The "will" in the second sentence could also be a "SHOULD" or "MAY", > I am not sure about this. > > > > "Metric TLV" would be a list of all DLEP TLVs that transport a metric > value like RLQ, delay, current/maximum link speed, ... > > >=20 > For my clarity, the proposal above only applies to metrics. Not > credits or other TLVs. >=20 > I understand the proposal to use 0-length but I'm still not > understanding the value. > If I'm developing the radio code to send the metrics, why send a 0- > length > TLV when the TLV can be omitted? This adds test vectors to be verified > for no > or little value. Maybe I'm missing something here, but it seems to me that this depends on i= f you assume a complete set of metrics is sent with each neighbor update. = If so then there's no ambiguity when an optional TLV is missing. Is this i= mplied by Section 22? If neighbor updates can contain incremental changes to optional items then = having a way to invalidate previous values could be useful. > Taking the extreme of the proposal the radio can send a Neighbor Up > filled with > 0-length TLVs which would have no value or purpose from a router's > perspective. >=20 >=20 >=20 > > Henning Rogge > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From jvasseur@cisco.com Tue Oct 16 13:15:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5D01F0C7E for ; Tue, 16 Oct 2012 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.496 X-Spam-Level: X-Spam-Status: No, score=-10.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP47AdQRwtS1 for ; Tue, 16 Oct 2012 13:15:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4232B1F0C60 for ; Tue, 16 Oct 2012 13:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1350418521; x=1351628121; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NGWDAzazVYMyPLDeFnFGnuzDnuXu9WE0wF0PoDYYTJc=; b=EJjRdPQvu4Jyd6egGTZkM/KZWz/C6h95w0WbAJv8jfJB7YMNj8CmNH6m fSpn32h/qUnmgUnyGm/23dPhcpTKC/03OxUbb3Czb3nB2pyM/+QMJF5rt jpGAVyu0rszHZ4Ya/em6tZ3S1WoJez9mTnKDU/z7WPA9Wt6Jt4pNi+Hf3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPS/fVCtJXG9/2dsb2JhbABFwAqBCIIgAQEBAwEBAQEPAVsLBQsCAQgOCgokJwslAgQOBQgah1wGC5p+j1yQRASLT4VdYAOkMoFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="132272960" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 16 Oct 2012 20:15:20 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9GKFKEQ010738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 20:15:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 15:15:20 -0500 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNq8IuxQdayxYbx0aw5eRdXfbe8w== Date: Tue, 16 Oct 2012 20:15:20 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FEB637@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <50A05995-EE7B-44DA-B157-B83D62FE2E6C@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FEA88D@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--42.011400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:15:21 -0000 On Oct 16, 2012, at 7:30 PM, Henning Rogge wrote: > On Tue, Oct 16, 2012 at 7:17 PM, JP Vasseur (jvasseur) > wrote: >> That being, all I was saying on my side, was that if indeed a protocol i= s designed to cover LLNs, then it should be ran by the WG in charge >> of LLNs. As you pointed out, AMI PLC network are definitely highly const= rained LLNs, with flappy/lossy links, low bandwidth, =85 >=20 > LoadNG has been developed from AODV, which is a Manet protocol. Yes, > there are MANET protocols which can handle low bandwidth... no > surprise. >=20 > And Lossy links are normal for many MANET, please do not pretend they > are something special handled in ROLL. JP> I do not pretend anything, just referring to the charter and work done = there. We will work together, no problem for the best of the Internet. Thanks. JP. >=20 > Henning Rogge >=20 > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Tue Oct 16 13:17:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A1E1F0C90 for ; Tue, 16 Oct 2012 13:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv7qIJrV3v0O for ; Tue, 16 Oct 2012 13:17:42 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 596411F0C69 for ; Tue, 16 Oct 2012 13:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7720; q=dns/txt; s=iport; t=1350418662; x=1351628262; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZwsWgmJ/izVZWdGiWw5U5BGJ0gK/zzztFSLTU4Ku5w8=; b=jSoGWbWLH1HG/XwPvdFbhICBVnrT8691klSttLxKs84p6LhVbJjhl3Cw KZTzU5EktHpsZvxLj6vLpV/qmftDocD7sHPF/Bmc+3ioLUGPUeVvIhnhq cYOiippzJDLOB/6BHeC4W+3m+WKZ+wXeVl38rvWrqmhsLEH86ngwEfX1S o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPS/fVCtJV2Y/2dsb2JhbABFwAqBCIIhAQEEEgFgBhACAQgiHQcyFBECBA4FCBqHYpsJj1yQSItPhV1gA6QygWuCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208,217";a="132273746" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 16 Oct 2012 20:17:41 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9GKHfeJ027146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 20:17:41 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 15:17:41 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w== Date: Tue, 16 Oct 2012 20:17:41 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FEB661@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--52.166700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FEB661xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:17:43 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FEB661xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, Real quick, let's do this =85 let's wait to see what comes out, and then al= l have a productive and fuirtful discussion. On your last point (and I am not saying that this is what has been decided = here, but get a document being reviewed by two WG does happen. Thanks. JP. On Oct 16, 2012, at 7:53 PM, Ulrich Herberg wrote: Hi JP, On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jvasseur) > wrote: [...] I agree. But that's not we are intending to do. We intent to produce a reac= tive protocol for MANETs, which is requested by the MANET charter. LOADng i= s a protocol that covers all the use cases of MANETs, one of which being LL= Ns. JP> See previous email =85. then it should be run by the WG in charge of ro= uting protocol in LLN, that excluded the use of reactive routing after years of work. No. The reactive MANET protocol should be "run" by the WG that is chartered= to produce a reactive MANET protocol. And if this protocol happens to be u= sed in some large-scale LLN deployments, does not mean that it is automatic= ally in overlap of charter, as long as that reactive protocol fullfils the = general requirements of MANETs. And yes, the introduction and title of the draft needs to be changed JP> No issue with this. Good, so you don't have an issue with having that changed. In a previous em= ail you said you also don't have an issue mentioning where a protocol is de= ployed. So I don't understand why we even continue this discussion. [...] JP> I cannot speak for our AD. As a WG co-chair, the minimum would be to ma= ke sure that the ROLL WG reviews the work in great details. Every individual is very welcome to review documents at any time. This is n= ormal IETF procedure. If you suggest that there is a LC in ROLL for a docum= ent in MANET, that seems like a new procedure to me that I have not heard b= efore. [...] I sincerely suggest to wait until you read the new revision, as this discus= sion is hypothetical without that. JP> Sure, when can we expect to see it ? As soon as possible. Monday October 22 is the deadline to submit new drafts= before this IETF. Best regards Ulrich --_000_03B78081B371D44390ED6E7BADBB4A7721FEB661xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

Real quick, let's do this =85 let's wait to see what comes out, and th= en all have a productive and fuirtful discussion.
On your last point (and I am not saying that this is what has been dec= ided here, but get a document being reviewed
by two WG does happen.

Thanks.

JP.

On Oct 16, 2012, at 7:53 PM, Ulrich Herberg wrote:

Hi JP,

On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
[...]

I agree. But that's not we are intending to do. We intent to produce a= reactive protocol for MANETs, which is requested by the MANET charter. LOA= Dng is a protocol that covers all the use cases of MANETs, one of which bei= ng LLNs.

JP> See previous email =85. then it should be run by the WG in char= ge of routing protocol in LLN, that excluded the use of reactive routing&nb= sp;
after years of work.


No. The reactive MANET protocol should be "run" by the WG th= at is chartered to produce a reactive MANET protocol. And if this protocol = happens to be used in some large-scale LLN deployments, does not mean that = it is automatically in overlap of charter, as long as that reactive protocol fullfils the general requirements of MAN= ETs.


 

And yes, the introduction and title of the draft needs to be changed

JP> No issue with this.

Good, so you don't have an issue with having that changed. In a previo= us email you said you also don't have an issue mentioning where a protocol = is deployed. So I don't understand why we even continue this discussion.

 
[...]

JP> I cannot speak for our AD. As a WG co-chair, the minimum would = be to make sure that the ROLL WG reviews the work in great details.


Every individual is very welcome to review documents at any time. This= is normal IETF procedure. If you suggest that there is a LC in ROLL for a = document in MANET, that seems like a new procedure to me that I have not he= ard before. 

[...]


I sincerely suggest to wait until you read the new revision, as this d= iscussion is hypothetical without that. 

JP> Sure, when can we expect to see it ?


As soon as possible. Monday October 22 is the deadline to submit new d= rafts before this IETF.

Best regards
Ulrich



--_000_03B78081B371D44390ED6E7BADBB4A7721FEB661xmbrcdx02ciscoc_-- From ulrich@herberg.name Tue Oct 16 13:22:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8B31F0C9C for ; Tue, 16 Oct 2012 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3a7u9e2Szru for ; Tue, 16 Oct 2012 13:22:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6B1F0C91 for ; Tue, 16 Oct 2012 13:22:49 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so7958707obq.31 for ; Tue, 16 Oct 2012 13:22:49 -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=b1MsUyG9E+VGpouyRGZGao1LFJo5j/ldmKpT9WKbIT4=; b=nMxlHNKKjX1HzeqcRkNy3+Fp7zokKpBhxXAiHjVnmIUktswV0cXqPm0U3WJXmiYBV6 BUE54IDOIV+dq01iH0SafxZjwv0MPn846nuDOjd4i3ZLEaEwy2WJ3Os7ui4cMJOh3m0W Se5+tIN7JRKQji55C5R12JBAGH7qNkSD4Mgi8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=b1MsUyG9E+VGpouyRGZGao1LFJo5j/ldmKpT9WKbIT4=; b=FNDloWY+A+k78IX//m5+l9iXP/p8hZ5RuQTjPI2Pp/yHq/WBsVYOQHQlizDJ+98Hgd 0ojyc68ukjjAj6+B+YB6WG763KrrEvjqMo9Y48FLEzOZnykAbddLUgjie8TkczON0bxf 7N31mdHbJLfg0p0/aZny2VLE6m3OV7vfhXAcJSr8UwirZWL/TqS4qm48iTsF8CzgLsIP Nyw72EBU8vtDwY3laredLzBNKyL8eLVFTeri2xqa651EdrKW9TKjWSkoFSCu64OoFPFI MHGm1u45++KxRPpkssA0msDgG2iiAOhFuDo5JZx+6sSJNIbKyKVJ1kjanKv7rwI/jLO9 /YRQ== MIME-Version: 1.0 Received: by 10.182.10.71 with SMTP id g7mr13286811obb.84.1350418969320; Tue, 16 Oct 2012 13:22:49 -0700 (PDT) Received: by 10.76.73.34 with HTTP; Tue, 16 Oct 2012 13:22:49 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FEB661@xmb-rcd-x02.cisco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FEB661@xmb-rcd-x02.cisco.com> Date: Tue, 16 Oct 2012 13:22:49 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=f46d0447a287f6dcdb04cc32ea59 X-Gm-Message-State: ALoCoQlEztbL0m0z27Kedh6mb6a/d4iOXG1OQjPEH7E/76nL5UKmylJ3QfNSiZ+mU9cG89X9rJI5 Cc: "Stan Ratliff \(sratliff\)" , " List" , "Bo Berry \(boberry\)" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:22:51 -0000 --f46d0447a287f6dcdb04cc32ea59 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP, On Tue, Oct 16, 2012 at 1:17 PM, JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > Real quick, let's do this =85 let's wait to see what comes out, and then > all have a productive and fuirtful discussion. > Sounds good. > On your last point (and I am not saying that this is what has been decide= d > here, but get a document being reviewed > by two WG does happen. > IETF is a never-ending learning process :-) Thanks. Best regards Ulrich > > Thanks. > > JP. > > On Oct 16, 2012, at 7:53 PM, Ulrich Herberg wrote: > > Hi JP, > > On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jvasseur) > wrote: > >> [...] >> >> I agree. But that's not we are intending to do. We intent to produce a >> reactive protocol for MANETs, which is requested by the MANET charter. >> LOADng is a protocol that covers all the use cases of MANETs, one of whi= ch >> being LLNs. >> >> >> JP> See previous email =85. then it should be run by the WG in charge o= f >> routing protocol in LLN, that excluded the use of reactive routing >> after years of work. >> > > > No. The reactive MANET protocol should be "run" by the WG that is > chartered to produce a reactive MANET protocol. And if this protocol > happens to be used in some large-scale LLN deployments, does not mean tha= t > it is automatically in overlap of charter, as long as that reactive > protocol fullfils the general requirements of MANETs. > > > > >> >> And yes, the introduction and title of the draft needs to be changed >> >> >> JP> No issue with this. >> > > Good, so you don't have an issue with having that changed. In a previous > email you said you also don't have an issue mentioning where a protocol i= s > deployed. So I don't understand why we even continue this discussion. > > > >> [...] >> >> >> JP> I cannot speak for our AD. As a WG co-chair, the minimum would be >> to make sure that the ROLL WG reviews the work in great details. >> > > > Every individual is very welcome to review documents at any time. This > is normal IETF procedure. If you suggest that there is a LC in ROLL for a > document in MANET, that seems like a new procedure to me that I have not > heard before. > > [...] >> >>> >> >> I sincerely suggest to wait until you read the new revision, as this >> discussion is hypothetical without that. >> >> >> JP> Sure, when can we expect to see it ? >> > > > As soon as possible. Monday October 22 is the deadline to submit new > drafts before this IETF. > > Best regards > Ulrich > > > > --f46d0447a287f6dcdb04cc32ea59 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi JP,

On Tue, Oct 16, 2012 at 1:17 PM, J= P Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
Hi Ulrich,

Real quick, let's do this =85 let's wait to see what comes out= , and then all have a productive and fuirtful discussion.

Sounds good.

=A0
On your last point (and I am not saying that this is what has been dec= ided here, but get a document being reviewed
by two WG=A0does happen.

I= ETF is a never-ending learning process :-) Thanks.

Best regards
Ulrich


=A0<= /div>

Thanks.

JP.

On Oct 16, 2012, at 7:53 PM, Ulrich Herberg wrote:

Hi JP,

On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
[...]

I agree. But that's not we are intending to do. We intent to produ= ce a reactive protocol for MANETs, which is requested by the MANET charter.= LOADng is a protocol that covers all the use cases of MANETs, one of which= being LLNs.

JP> See previous email =85. then it should be run by the WG in char= ge of routing protocol in LLN, that excluded the use of reactive routing=A0=
after years of work.


No. The reactive MANET protocol should be "run" by the WG th= at is chartered to produce a reactive MANET protocol. And if this protocol = happens to be used in some large-scale LLN deployments, does not mean that = it is automatically in overlap of charter, as long as that reactive protocol fullfils the general requirements of MAN= ETs.


=A0

And yes, the introduction and title of the draft needs to be changed

JP> No issue with this.

Good, so you don't have an issue with having that changed. In a pr= evious email you said you also don't have an issue mentioning where a p= rotocol is deployed. So I don't understand why we even continue this di= scussion.

=A0
[...]

JP> I cannot speak for our AD. As a WG co-chair, the minimum would = be to make sure that the ROLL WG reviews the work in great details.


Every individual is very welcome to review documents at any time. This= is normal IETF procedure. If you suggest that there is a LC in ROLL for a = document in MANET, that seems like a new procedure to me that I have not he= ard before.=A0

[...]


I sincerely suggest to wait until you read the new revision, as this d= iscussion is hypothetical without that.=A0

JP> Sure, when can we expect to see it ?


As soon as possible. Monday October 22 is the deadline to submit new d= rafts before this IETF.

Best regards
Ulrich




--f46d0447a287f6dcdb04cc32ea59-- From teco@inf-net.nl Tue Oct 16 13:30:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EB811E80D3 for ; Tue, 16 Oct 2012 13:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxsXc300Kz4N for ; Tue, 16 Oct 2012 13:30:32 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAAE921F8659 for ; Tue, 16 Oct 2012 13:30:31 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so4033524eek.31 for ; Tue, 16 Oct 2012 13:30:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=aDxwl4IF+Q1BYFgJzSCpT053hK7jgjPY00iUm1jI+pY=; b=Exj7heITFHehosCU5SW5BrDjVF90itrV625OdHtsE8oOZ+iQJxXXoTjei2vEmsGPJK wpSIDr6MNhnkFS/vpZnuxpTLVEIq/1vwzBbLLKBSi6k58sf7byNFP6adbWAnMpuYI85X hXn+Mm6OvKdCLe1e849W5UWioJzBo24kRccVwNx3xdqv/Sm8Y/JPTQhNpg2pUUsoHvTn pxVgz34h+MU735Y7Kt1DzVUqV0vOwfubOXZEiHijg6+cRF09DESzpAUVxVIjb6JnIWMT lSWmjO+n1bFieBt7i5aYpKuUCL6MslwivLaTFiRL0bau4hmyiJQslSYVbrfkSsE1u8lh zYTw== Received: by 10.14.193.134 with SMTP id k6mr17723829een.15.1350419430906; Tue, 16 Oct 2012 13:30:30 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:d194:5c0d:1412:4c1c? ([2001:470:7a9b:1:d194:5c0d:1412:4c1c]) by mx.google.com with ESMTPS id 7sm31771568eeg.5.2012.10.16.13.30.29 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 13:30:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Tue, 16 Oct 2012 22:30:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772 1FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmyvaaovx7xzFheOgCfqNvDbrU4MYXr3FVvBidyv/VAkmK3VSV4Z/t9KxCQmistYihu660y Cc: "Dearlove, Christopher \(UK\)" , " List" , "Stan Ratliff \(sratliff\)" , "Bo Berry \(boberry\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:30:32 -0000 Op 16 okt. 2012, om 19:53 heeft Ulrich Herberg het volgende geschreven: > Hi JP, >=20 > On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jvasseur) = wrote: >> [...] >>=20 >> I agree. But that's not we are intending to do. We intent to produce = a reactive protocol for MANETs, which is requested by the MANET charter. = LOADng is a protocol that covers all the use cases of MANETs, one of = which being LLNs. >=20 > JP> See previous email =85. then it should be run by the WG in charge = of routing protocol in LLN, that excluded the use of reactive routing=20 > after years of work. >=20 >=20 > No. The reactive MANET protocol should be "run" by the WG that is = chartered to produce a reactive MANET protocol. And if this protocol = happens to be used in some large-scale LLN deployments, does not mean = that it is automatically in overlap of charter, as long as that reactive = protocol fullfils the general requirements of MANETs. >=20 >=20 > =20 >=20 >> And yes, the introduction and title of the draft needs to be changed >=20 > JP> No issue with this. >=20 > Good, so you don't have an issue with having that changed. In a = previous email you said you also don't have an issue mentioning where a = protocol is deployed. So I don't understand why we even continue this = discussion. +1 >=20 > =20 > [...] >=20 > JP> I cannot speak for our AD. As a WG co-chair, the minimum would be = to make sure that the ROLL WG reviews the work in great details. >=20 >=20 > Every individual is very welcome to review documents at any time. This = is normal IETF procedure. If you suggest that there is a LC in ROLL for = a document in MANET, that seems like a new procedure to me that I have = not heard before.=20 -1 For me, it is not new at all that drafts pass WGLCs in multiple GWs. If LLN is mentioned on a MANET document, it shall pass ROLL. If the MANET protocols' name starts with L, standing for LLN, it should = not be submitted in MANET. >=20 >> [...] >>=20 >>=20 >> I sincerely suggest to wait until you read the new revision, as this = discussion is hypothetical without that.=20 >=20 > JP> Sure, when can we expect to see it ? >=20 >=20 > As soon as possible. Monday October 22 is the deadline to submit new = drafts before this IETF. No, deadline for new drafts has passed: 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) = submission by UTC 24:00, upload using IETF ID Submission Tool. You have to use a time machine to get this in next MANET meeting. Or use = draft-ietf-manet-dymo-23 placeholder. Why not put energy in get something out? Teco >=20 > Best regards > Ulrich >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Tue Oct 16 13:40:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C041F0CA1 for ; Tue, 16 Oct 2012 13:40:51 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVJPCEHc6vBG for ; Tue, 16 Oct 2012 13:40:51 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC1D1F0C98 for ; Tue, 16 Oct 2012 13:40:45 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so4039094eek.31 for ; Tue, 16 Oct 2012 13:40:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=YZKNYTEgwfxjSrHrbcrXL1RF4koIhlnU8ccbiietqOM=; b=CMSjvJ5eR90MVqNwffSsuQbhYGKtvNbE0vsH/mIvxa2PXG5meUT0It2g5Gqr7vdYZ2 poT4D7E4g+UI8Vqa0qzdiOPtLxGzg8LDmX0BfbozWJuqVRHUzcmBs84vZ1DuxxoS5FOc 9t/5F+L5J40a5ablR3B7wBHkLQQo1xMEWer5mT55WyHqInKQixYO3bvo9fwT8PsrtaJA 5kzn8OKthhN16D9WuBDqnEvBQ2M1dAuqYHwcHgF9cIRB2AafXL0pOSlMlgHcFF4WqdkN H1xsGlDm9Dvl8Y/Q9CastSj0a1wxZSLADUkyUdda2LgtffFKDimI/j8iSMscL4H/hS5M 0ytg== Received: by 10.14.179.1 with SMTP id g1mr23474544eem.14.1350420044405; Tue, 16 Oct 2012 13:40:44 -0700 (PDT) Received: from [10.175.173.28] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id r45sm31813819eem.6.2012.10.16.13.40.40 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 13:40:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> Date: Tue, 16 Oct 2012 22:40:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92F88E39-2E83-47C0-9D79-4B46E9954EB0@inf-net.nl> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> To: "Goff, Thomas" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm9YPiG3FvGQXUFWNDhionZn5BW+J2zR55rdlOhrqg4rfQb4Lh+epv2bTcMHvYBp7jK5jMU Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:40:52 -0000 Op 16 okt. 2012, om 21:34 heeft Goff, Thomas het volgende geschreven: > Just a couple of comments inline below. >=20 > Tom >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >> Of Bo Berry >> Sent: Monday, October 15, 2012 4:33 AM >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] Some comments on manet-dlep-03 >=20 >>=20 >> On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >>=20 >>> On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: >>>> I've asked twice now (this email makes attempt number 3) for = someone >> to suggest some text to clarify what a router or modem would do with = an >> UNKNOWN metric. So far, what I've seen is a potentially new *way* of >> specifying UNKNOWN - one that makes more sense than picking some >> arbitrary code point. But no actual text to suggest what either of = the >> endpoints would *do* with the data. Maybe I'm old, feeble, and not = very >> bright - but I'm looking for suggestions that start with "A router >> receiving a metric value of UNKNOWN MUST." or "An implementation >> receiving an UNKNOWN indication SHOULD." or something along those >> lines. Barring that, the only text I've got to insert is what I >> suggested before: >>>>>=20 >>>>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases = where >> RLQ is supported, but not currently calculable. The authors have no >> idea under what circumstances this would occur. Routers receiving a >> value of RLQ_UNKNOWN are free to take any action deemed appropriate, >> including (but not limited to) ignoring the value, producing log >> messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was >> added at the request of the working group, as consensus formed around >> the key ideas that this MAY allow for innovation, even though none of >> the working group members were able to note a set of circumstances >> under which this innovation might take place. So, in an effort to = stop >> the email storm, the authors added the additional code point." >>>=20 >>> If we use Teco's suggested solution (using 'length =3D 0' to make an >> unknown but supported TLV): >>>=20 >>> ---- >>> Radio implementations MAY use a metric TLV without value and length = 0 >> to signal a not measurable but supported TLV. >>>=20 >>> Most router implementations will process this metric TLV in the same >> way as a missing metric TLV. >>> ---- >=20 >=20 > I would suggest that a TLV of length 0 could simply invalidate a = previously sent (optional) value without implying anything about = measurability. >=20 >=20 >>> The "will" in the second sentence could also be a "SHOULD" or "MAY", >> I am not sure about this. >>>=20 >>> "Metric TLV" would be a list of all DLEP TLVs that transport a = metric >> value like RLQ, delay, current/maximum link speed, ... >>>=20 >>=20 >> For my clarity, the proposal above only applies to metrics. Not >> credits or other TLVs. >>=20 >> I understand the proposal to use 0-length but I'm still not >> understanding the value. >> If I'm developing the radio code to send the metrics, why send a 0- >> length >> TLV when the TLV can be omitted? This adds test vectors to be = verified >> for no >> or little value. >=20 >=20 > Maybe I'm missing something here, but it seems to me that this depends = on if you assume a complete set of metrics is sent with each neighbor = update. If so then there's no ambiguity when an optional TLV is = missing. Is this implied by Section 22? I did not read it that way. If we go for this alternative, we can skip = the add/drop indicator in address TLVs. A mix of two mechanisms sounds = crazy to me. Teco=20 >=20 > If neighbor updates can contain incremental changes to optional items = then having a way to invalidate previous values could be useful. >=20 >=20 >> Taking the extreme of the proposal the radio can send a Neighbor Up >> filled with >> 0-length TLVs which would have no value or purpose from a router's >> perspective. >>=20 >>=20 >>=20 >>> Henning Rogge >>>=20 >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From c.chauvenet@watteco.com Tue Oct 16 13:50:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D1821F87AA for ; Tue, 16 Oct 2012 13:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.925 X-Spam-Level: X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=1.673, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTBVOkdvC9rE for ; Tue, 16 Oct 2012 13:50:27 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 045F221F87AB for ; Tue, 16 Oct 2012 13:50:22 -0700 (PDT) Received: from mail241-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 20:50:21 +0000 Received: from mail241-tx2 (localhost [127.0.0.1]) by mail241-tx2-R.bigfish.com (Postfix) with ESMTP id 8D811560119; Tue, 16 Oct 2012 20:50:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zzbb2dI98dI9371Ic89bhc85eh1418Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh84d07hz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail241-tx2 (localhost.localdomain [127.0.0.1]) by mail241-tx2 (MessageSwitch) id 1350420619213225_15767; Tue, 16 Oct 2012 20:50:19 +0000 (UTC) Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.245]) by mail241-tx2.bigfish.com (Postfix) with ESMTP id 24CFC34009B; Tue, 16 Oct 2012 20:50:19 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 20:50:19 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0224.004; Tue, 16 Oct 2012 20:50:06 +0000 From: C Chauvenet To: Cedric-2 LAVENU Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAIAAdJeAgABi3ICAAIeagIAAER6AgACSLwCAAFx+AIAAlVYAgAAKlACAAaKFAIAAQLKA Date: Tue, 16 Oct 2012 20:50:05 +0000 Message-ID: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_BB1FA88B4E784CD7991565E49D8ECBA2wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" , "" , "" , "" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:50:32 -0000 --_000_BB1FA88B4E784CD7991565E49D8ECBA2wattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi C=E9dric, (Hope people will follow which cedric is talking !) Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit : Dear C=E9dric, I'm not sure all this discussions really make sense : > An LLN network is definitely a type of MANET As JP pointed out, if LLNs challenges can be addressed in MANET, why would= have ROLL being created ? I think that a protocol intend to LLNs, or if LLNs are included in the scop= e should be reviewed by the ROLL working group , as it is the place dedicat= ed by the IETF. Does that makes sense ? according to what Adrian said (he has been quoted several times in the past= mails). One of the fileds LOADng is intended to be used are AMI PLC networ= ks with low bandwidth (few kbps in the harshest environments), but can be e= xtensible to other types of MANETs. And regarding your comment about experience with LOADng : > LOADng is a protocol for which several running implementations exist and = interoperate as shown in draft : http://tools.ietf.org/html/draft-lavenu-ll= n-loadng-interoperability-report-02 yes it has been discussed, and explained that the goal of these test were f= ocused on validating the protocol behavior, not the performance. > In addition, LOAD (the previous version) was successfully run in a 2000 P= LC node trial. Very nice ! Would you mind to share some details on this ? C=E9dric. I think that all the facts are on the table to say that LOAD would be suita= ble for MANETs (LLNs being a subset of MANETs). In addition field and lab e= xperience does exist and demonstrated that LOADng can be very efficient. Regards, C=E9dric C=E9dric LAVENU Research Engineer EDF =96 R&D MIRE Department 1 avenue du g=E9n=E9ral de Gaulle 92141 CLAMART - FRANCE cedric-2.lavenu@edf.fr T=E9l. : +33 1 47 65 27 29 Fax : +33 1 47 65 55 56 Un geste simple pour l'environnement, n'imprimez ce message que si = vous en avez l'utilit=E9. De : c.chauvenet@watteco.com A : ulrich@herberg.name, ietf@thomasclau= sen.org Cc : sratliff@cisco.com, Chris.Dearlove@b= aesystems.com, manet@ietf.org, boberry@cisco.com Date : 15/10/2012 18:01 Objet : Re: [manet] MANET meeting at IETF85 Envoy=E9 par : manet-bounces@ietf.org ________________________________ Hi ulrich and Thomas Le 15 oct. 2012 =E0 17:22, Ulrich Herberg a =E9crit : Hi JP, On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) > wrote: [...] JP> Here we do not disagree at all. I am not saying that reactive protocols= are not appropriate in a number of scenario. All I am saying is that *if* = you intent to specify a reactive routing protocol for LLNs, knowing the years of intense work and= efforts of the ROLL WG, then it should be discussed with a wider audience. I agree. But that's not we are intending to do. We intent to produce a reac= tive protocol for MANETs, which is requested by the MANET charter. LOADng i= s a protocol that covers all the use cases of MANETs, one of which being LL= Ns. And yes, the introduction and title of the draft needs to be changed On the other hand, if your explicitly exclude LLNs from your protocol in your protocol, = it is no longer required to involve the ROLL WG. The objective is simply to= avoid WG charter overlap but more importantly try to benefit from the benefit of experts in = the area of LLNs to build a good protocol for the Internet. I am personally against removing to mention a use case where as a matter of= fact the protocol is used in (as *one* use-case out of many). Citing Adrian from the last MANET meeting: Adrian Farrell: If you were to pick up a reactive protocol for MANET, you w= ould be in charter. If you pick up a protocol and your main use case is for= LLNs, you have diverged from charter. Main use case is delicate thing to t= alk about. It is clear that some if not all LLNs are MANET. Not all MANETs = are LLNs. So you need to be producing a single reactive protocol for MANETs= , not for *some* MANETs. You need to be clear that the protocol you work on= is applicable across all MANETs. If that picks up some LLNs across the way= , no big deal, but it should not be main use case. Look at all use cases fo= r MANETs and make sure you address all of those. You'll not the "If that picks up some LLNs across the way, no big deal, but= it should not be main use case". That is why I asked in a previous mail the nature of LOADng deployments you= were talking about. I cannot find any material on this. If they are LLN, then it seems in disagreement with what Adrian suggest. This is exactly what we intend to do. It was also agreed at the last MANET meeting that if LOADng was to be consi= dered for MANET, it needs to de-emphasize LLNs (which I have not heard anyb= ody disagree with so far). So I don't understand what we are even discussin= g here. JP> No, this your recollection of the discussion. "less-focussed" or "de-em= phasize" was I think your interpretation. Mine was "not referring to LLNs" = at all. I sincerely suggest to wait until you read the new revision, as this discus= sion is hypothetical without that. Agree that the new version should be a good point of discussion. Best, C=E9dric. Otherwise, it should be reviewed by both WGs (to be discussed between chair= s and AD). Best Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') sont = =E9tablis =E0 l'intention exclusive des destinataires et les informations q= ui y figurent sont strictement confidentielles. Toute utilisation de ce Mes= sage non conforme =E0 sa destination, toute diffusion ou toute publication = totale ou partielle, est interdite sauf autorisation expresse. Si vous n'=EAtes pas le destinataire de ce Message, il vous est interdit de= le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou pa= rtie. Si vous avez re=E7u ce Message par erreur, merci de le supprimer de v= otre syst=E8me, ainsi que toutes ses copies, et de n'en garder aucune trace= sur quelque support que ce soit. Nous vous remercions =E9galement d'en ave= rtir imm=E9diatement l'exp=E9diteur par retour du message. Il est impossible de garantir que les communications par messagerie =E9lect= ronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es de tout= e erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for th= e addressees. The information contained in this Message is confidential. An= y use of information contained in this Message not in accord with its purpo= se, any dissemination or disclosure, either whole or partial, is prohibited= except formal approval. If you are not the addressee, you may not copy, forward, disclose or use an= y part of it. If you have received this message in error, please delete it = and all copies from your system and notify the sender immediately by return= message. E-mail communication cannot be guaranteed to be timely secure, error or vir= us-free. --_000_BB1FA88B4E784CD7991565E49D8ECBA2wattecocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6C456C2035EB2442AA7AD8E5F4FD59B5@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi C=E9dric, (Hope people will follow which cedric is talking !)

Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit :

Dear C=E9dri= c,

I'm not sure all this discussions real= ly make sense : 

> An LLN network is definitely a ty= pe of MANET

As JP pointed out, if LLNs challenges can be addressed  in MANET,= why would have ROLL being created ?
I think that a protocol intend to LLNs, or if LLNs are included in the= scope should be reviewed by the ROLL working group , as it is the place de= dicated by the IETF.

Does that makes sense ?

according to= what Adrian said (he has been quoted several times in the past mails). One= of the fileds LOADng is intended to be used are AMI PLC networks with low = bandwidth (few kbps in the harshest environments), but can be extensible to other types of MANETs.

And regarding your comment about exper= ience with LOADng :

> LOADng is a protocol for which se= veral running implementations exist and interoperate as shown in draft : http://tools.iet= f.org/html/draft-lavenu-lln-loadng-interoperability-report-02

yes it has been discussed, and explained that the goal of these test w= ere focused on validating the protocol behavior, not the performance.

> In addi= tion, LOAD (the previous version) was successfully run in a 2000 PLC node t= rial.

Very nice ! 
Would you mind to share some details on this ?

C=E9dric.


I think that all the facts are on the = table to say that LOAD would be suitable for MANETs (LLNs being a subset of= MANETs). In addition field and lab experience does exist and demonstrated = that LOADng can be very efficient. 

Regards,
C=E9dric
<Pi=E8ce jointe Mail.jpeg>  
C=E9dric LAVENU
Research Engineer
EDF =96 R&D
MIRE Department
1 avenue du g=E9n=E9ral de Gaulle
92141 CLAMART - FRANCE

cedric-2.lavenu@edf.fr
T=E9l. : +33 1 47 65 = 27 29
Fax : +33 1 47 65 55 56
<Pi=E8ce jointe Mail.gif>
 Un geste simple pour = l'environnement, n'imprimez ce message que si vous en avez l'utilit=E9.





De :     &= nbsp;  c.chauvenet@watteco.com
A :     &n= bsp;  ulrich@herberg.name, ietf@thomasclausen.org=
Cc :   &nb= sp;    sratliff@cisco.com, Chris.Dearlove@baesystems.= com, manet@ietf.org, boberry@cisco.com
Date :    =    15/10/2012 18:01<= /font>
Objet :    = ;    Re: [manet] MANE= T meeting at IETF85
Envoy=E9 par :  = ;      manet-bounces@ietf.org



Hi ulrich and Thomas

Le 15 oct. 2012 =E0 17:22, Ulrich Herberg a =E9crit :

Hi JP,


On Sun, Oct 14, 2012 at 11:28 PM, JP Vasseur (jvasseur) &l= t;jvasseur@cisco.com= > wrote:
[...]

JP> Here we do not disagree at all. I am not saying tha= t reactive protocols are not appropriate in a number of scenario. All I am = saying is that *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of= intense work and efforts of the ROLL WG, then it should be discussed with = a wider audience.


I agree. But that's not we are intending to do. We intent = to produce a reactive protocol for MANETs, which is requested by the MANET = charter. LOADng is a protocol that covers all the use cases of MANETs, one = of which being LLNs.
And yes, the introduction and title of the draft needs to = be changed


 
On the other
hand, if your explicitly exclude LLNs from your protocol i= n your protocol, it is no longer required to involve the ROLL WG. The objec= tive is simply to avoid WG charter
overlap but more importantly try to benefit from the benef= it of experts in the area of LLNs to build a good protocol for the Internet= .

I am personally against removing to mention a use case whe= re as a matter of fact the protocol is used in (as *one* use-case out of ma= ny).

Citing Adrian from the last MANET meeting:
Adrian Farrell: If you were to pick up a reactive prot= ocol for MANET, you would be in charter. If you pick up a protocol and your= main use case is for LLNs, you have diverged from charter. Main use case i= s delicate thing to talk about. It is clear that some if not all LLNs are MANET. Not all MANETs are LLNs. So = you need to be producing a single reactive protocol for MANETs, not for *so= me* MANETs. You need to be clear that the protocol you work on is applicabl= e across all MANETs. If that picks up some LLNs across the way, no big deal, but it should not be main use ca= se. Look at all use cases for MANETs and make sure you address all of those= .

You'll not the "If that p= icks up some LLNs across the way, no big deal, but it should not be main us= e case".

That is why I asked in a previous mail the nature of LOADn= g deployments you were talking about.
I cannot find any material on this.
If they are LLN, then it seems in disagreement with what A= drian suggest.


This is exactly what we intend to do.



It was also agreed at the last MANET meeting that if LOADn= g was to be considered for MANET, it needs to de-emphasize LLNs (which I ha= ve not heard anybody disagree with so far). So I don't understand what we a= re even discussing here.

JP> No, this your recollection of the discussion. "= ;less-focussed" or "de-emphasize" was I think your interpret= ation. Mine was "not referring to LLNs" at all.


I sincerely suggest to wait until you read the new revisio= n, as this discussion is hypothetical without that.

Agree that the new version should be a good point of discu= ssion.

Best,

C=E9dric.


 
Otherwise, it should be reviewed by both WGs (to be discus= sed between chairs and AD).

Best
Ulrich
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le 'Message') sont = =E9tablis =E0 l'intention exclusive des destinataires et les informations q= ui y figurent sont strictement confidentielles. Toute utilisation de ce Mes= sage non conforme =E0 sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf aut= orisation expresse.

Si vous n'=EAtes pas le destinataire de ce Message, il vous est interdit= de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou= partie. Si vous avez re=E7u ce Message par erreur, merci de le supprimer d= e votre syst=E8me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. No= us vous remercions =E9galement d'en avertir imm=E9diatement l'exp=E9diteur = par retour du message.

Il est impossible de garantir que les communications par messagerie =E9l= ectronique arrivent en temps utile, sont s=E9curis=E9es ou d=E9nu=E9es de t= oute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for= the addressees. The information contained in this Message is confidential.= Any use of information contained in this Message not in accord with its pu= rpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use= any part of it. If you have received this message in error, please delete = it and all copies from your system and notify the sender immediately by ret= urn message.

E-mail communication cannot be guaranteed to be timely secure, error or = virus-free.


--_000_BB1FA88B4E784CD7991565E49D8ECBA2wattecocom_-- From c.chauvenet@watteco.com Tue Oct 16 13:54:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA3D21F87AD for ; Tue, 16 Oct 2012 13:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.135 X-Spam-Level: X-Spam-Status: No, score=-5.135 tagged_above=-999 required=5 tests=[AWL=1.464, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v155J97BEhbO for ; Tue, 16 Oct 2012 13:54:07 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0D21F87AB for ; Tue, 16 Oct 2012 13:54:07 -0700 (PDT) Received: from mail149-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 20:54:06 +0000 Received: from mail149-tx2 (localhost [127.0.0.1]) by mail149-tx2-R.bigfish.com (Postfix) with ESMTP id 9EE6AA025E; Tue, 16 Oct 2012 20:54:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371Ic89bh936eI1432Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h946hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail149-tx2 (localhost.localdomain [127.0.0.1]) by mail149-tx2 (MessageSwitch) id 1350420844106840_1452; Tue, 16 Oct 2012 20:54:04 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.249]) by mail149-tx2.bigfish.com (Postfix) with ESMTP id 0B7012A006A; Tue, 16 Oct 2012 20:54:04 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 20:54:02 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0207.009; Tue, 16 Oct 2012 20:53:57 +0000 From: C Chauvenet To: Teco Boot Thread-Topic: [manet] MANET meeting at IETF85 Thread-Index: AQHNpmg4igmQIr97MkqXx7O11yc1M5e1bMUAgAAi0ACAABEIgIAACxyAgAAD6YCAAAqegIAAARgAgAAXIoCAAASLgIABcySAgAAZGACAAC2ZAIAAdJeAgABi3ICAAIeagIAAER6AgACSLwCAAFx+AIAAlVYAgAAJqwCAAbLIgIAAK9uAgAAGkYA= Date: Tue, 16 Oct 2012 20:53:57 +0000 Message-ID: <0CBE22E7-5CDC-47E5-A6B6-578FA5DF1596@watteco.com> References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772 1FDC303@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:54:08 -0000 Hi,=20 Le 16 oct. 2012 =E0 22:30, Teco Boot a =E9crit : >=20 > Op 16 okt. 2012, om 19:53 heeft Ulrich Herberg het volgende geschreven: >=20 >> Hi JP, >>=20 >> On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jvasseur) wrote: >>> [...] >>>=20 >>> I agree. But that's not we are intending to do. We intent to produce a = reactive protocol for MANETs, which is requested by the MANET charter. LOAD= ng is a protocol that covers all the use cases of MANETs, one of which bein= g LLNs. >>=20 >> JP> See previous email =85. then it should be run by the WG in charge of= routing protocol in LLN, that excluded the use of reactive routing=20 >> after years of work. >>=20 >>=20 >> No. The reactive MANET protocol should be "run" by the WG that is charte= red to produce a reactive MANET protocol. And if this protocol happens to b= e used in some large-scale LLN deployments, does not mean that it is automa= tically in overlap of charter, as long as that reactive protocol fullfils t= he general requirements of MANETs. >>=20 >>=20 >>=20 >>=20 >>> And yes, the introduction and title of the draft needs to be changed >>=20 >> JP> No issue with this. >>=20 >> Good, so you don't have an issue with having that changed. In a previous= email you said you also don't have an issue mentioning where a protocol is= deployed. So I don't understand why we even continue this discussion. > +1 >=20 >>=20 >>=20 >> [...] >>=20 >> JP> I cannot speak for our AD. As a WG co-chair, the minimum would be to= make sure that the ROLL WG reviews the work in great details. >>=20 >>=20 >> Every individual is very welcome to review documents at any time. This i= s normal IETF procedure. If you suggest that there is a LC in ROLL for a do= cument in MANET, that seems like a new procedure to me that I have not hear= d before.=20 > -1 > For me, it is not new at all that drafts pass WGLCs in multiple GWs. > If LLN is mentioned on a MANET document, it shall pass ROLL. Agree, seems fair. > If the MANET protocols' name starts with L, standing for LLN, it should n= ot be submitted in MANET. Indeed. C=E9dric. >=20 >>=20 >>> [...] >>>=20 >>>=20 >>> I sincerely suggest to wait until you read the new revision, as this di= scussion is hypothetical without that.=20 >>=20 >> JP> Sure, when can we expect to see it ? >>=20 >>=20 >> As soon as possible. Monday October 22 is the deadline to submit new dra= fts before this IETF. > No, deadline for new drafts has passed: > 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) su= bmission by UTC 24:00, upload using IETF ID Submission Tool. > You have to use a time machine to get this in next MANET meeting. Or use = draft-ietf-manet-dymo-23 placeholder. >=20 > Why not put energy in get something out? >=20 > Teco >=20 >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From jomullen@ad.nmsu.edu Tue Oct 16 15:42:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECC31F0CA6 for ; Tue, 16 Oct 2012 15:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUlEAl0KGmcS for ; Tue, 16 Oct 2012 15:42:08 -0700 (PDT) Received: from exchange.nmsu.edu (ex-ht-p2.nmsu.edu [128.123.34.10]) by ietfa.amsl.com (Postfix) with ESMTP id 657581F0CA4 for ; Tue, 16 Oct 2012 15:41:39 -0700 (PDT) Received: from EX-MBX-P2.ACN.ad.nmsu.edu ([169.254.2.33]) by EX-HT-P2.ACN.ad.nmsu.edu ([128.123.34.10]) with mapi id 14.02.0309.002; Tue, 16 Oct 2012 16:41:34 -0600 From: John Mullen To: "manet@ietf.org" Thread-Topic: [manet] INTERFERENCE POWER Thread-Index: AQHNq1mrksLrxuFiD06GcMsFQtKTSJe8DtyAgAB3IDA= Date: Tue, 16 Oct 2012 22:41:33 +0000 Message-ID: <96E29CF19751734389BE3A1B346841802C827905@EX-MBX-P2.ACN.ad.nmsu.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.123.3.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] INTERFERENCE POWER X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 22:42:09 -0000 Interference is a complex problem. Even in an ideal setting, the interferen= ce at a receiver will vary randomly over a very magnitude. Specifics depen= d on the hardware, waveform, frequency, relative humidity, air temperature,= etc. In a more complicated environment say in a city, there are multipath = problems, so moving a receiver closer to an interfering transmitter might a= ctually reduce interference.=20 For this working group, it is probably enough to acknowledge that interfere= nce is an issue and leave it at that.=20 John Mullen -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: Tuesday, October 16, 2012 3:28 AM To: Pr Cc: manet@ietf.org Subject: Re: [manet] INTERFERENCE POWER On 10/16/12, Pr wrote: >> >> is there any formula to calculate noise power based on transmitter=20 >> power or receiver power or based on distance between them? >> I saw a formula in mathworks.in website while generally searcing in=20 >> google which is: >> interference power=3Dtransmission power-signal power-noise power. >> Is this a basic formula or derived from any other formula? It is a wrong formula, please notice that interference is the receiver prob= lem not the transmitter problem. The ITU have presented the answer formulas= , but IETF does not, because they are maybe out of scope. AB >> > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From d.sturek@att.net Tue Oct 16 15:43:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B221F86D3 for ; Tue, 16 Oct 2012 15:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z0lc6ytXgYM for ; Tue, 16 Oct 2012 15:43:56 -0700 (PDT) Received: from nm29.bullet.mail.ac4.yahoo.com (nm29.bullet.mail.ac4.yahoo.com [98.139.52.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3CD21F86D1 for ; Tue, 16 Oct 2012 15:43:56 -0700 (PDT) Received: from [98.139.52.188] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 16 Oct 2012 22:43:51 -0000 Received: from [66.94.237.117] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 16 Oct 2012 22:43:51 -0000 Received: from [127.0.0.1] by omp1022.access.mail.mud.yahoo.com with NNFMP; 16 Oct 2012 22:43:51 -0000 X-Yahoo-Newman-Id: 20126.47563.bm@omp1022.access.mail.mud.yahoo.com Received: (qmail 9208 invoked from network); 16 Oct 2012 22:43:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1350427430; bh=Y3YyK5dFVw7AVMznCAu0KyUoytrBCHmcMuOEzccmHUs=; 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:Content-transfer-encoding; b=rffWCFwxoKQp/6pQPPCVdfWpooBHMnQNdX08sxSxtHTpHjlU0/IMhuVUPQILQT17DweTkHAnwZATAS+4Yf8vt3WnYqhYBxlYlbB4IIepqN2VU121fYGzAQ0QRyaoBO9YYUcOTTj6msKqOrQkrc31int6Droi0R4o1tHytReI52c= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1_LbCIAVM1mM74gku4qwI2TILLtUfEEK_eMtunS3PSSmrYS J2GjoVHkSw3KQA_ERPhcL8oj_5O5RpUPNNy5byX8YPlJX9uLmoXQStUpNzKH xXg1EAQFdO28MT8HkP2DbMr8qclmN.JzFjGloeHEiElyE1CdFpXD1nRXyb6G exptnXSqkTB5pMoS_tRC50UojyKNR0VUe5C.Hp8wNRkqeS6OPzw9dbTFtq59 hwtIzIIjhdfK5IbHSBcMofelSwEER6Vfb_z.1GxpBCGkwr2k0xQPWiRioR_j 9OZ4pIdOe3PxXZuB2lrGvM_y3ud6wvYIHOpam3BQuAcjl4JDmiqESsMicGwv KggytKL044kMkPrseKiuviQY2OCT2MIwBq_Leq.nZsqO8O7QnfDeRvh2J1nO SA0e8M4Qe41cI4wchRuTZeq9kSmjNqOd75gadyBzNQEgNeJWKjzYS72kD.Yj 75ylCBvAn7QmdD9AFRLLwoaYNoOWdfgIzQNeyrdrxg_SBs3xYJPu57lJMJTs PpbGugaF5R0i5G5O1f0pel29WtyaXT7IF X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.16.1.152] (d.sturek@115.125.248.113 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 16 Oct 2012 15:43:50 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 16 Oct 2012 06:07:03 -0700 From: Don Sturek To: Abdussalam Baryun , Henning Rogge Message-ID: Thread-Topic: [manet] MANET meeting at IETF85 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 22:43:57 -0000 Hi AB, What exactly do you mean regarding "ZigBee-Internet technologies"? All a commercial organization like ZigBee is doing is choosing a collection of IETF standards, defining how to configure and use them, then setting up a certification program around that profile. There is no "ZigBee-Internet technologies", only a defined set of IETF standards optimized for use in certain applications. Don On 10/16/12 2:55 AM, "Abdussalam Baryun" wrote: >I understand you ment that ROLL looks also in similar applications of >Zigbee as Home Networks. However, Zigbee is standard for another >organisation, but IETF does not standard that, IMHO, we don't discuss >*Zigbee standards* in IETF WGs, but we may discuss how to interoperate >MANETs or LLNs with Zigbee-Internet technologies. > >AB >+++ >On 10/16/12, Henning Rogge wrote: >> Its also the default description of MANET/MESH. >> >> > that makes it difficult and that justified forming a new WG at the >> IETF (ROLL). >>> Does that make sense ? >> >> ROLL looks (mostly) into Zigbee based stationary networks. This are >> reasonable fast networks and one of the basic assumptions of of ROLL >> seems to be that the link quality doesn't change that much over time (an >> assumption that makes sense because of the lack of mobility). >> >> This is a part of the "problem space" MANET looks into... similar to the >> fact that some MANET protocols are just normal routing protocols that >> have been optimized for less stable links. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From salo@saloits.com Tue Oct 16 15:54:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353CD1F0CAC for ; Tue, 16 Oct 2012 15:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vSxCrk2dLL3 for ; Tue, 16 Oct 2012 15:54:28 -0700 (PDT) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 745C71F0CAA for ; Tue, 16 Oct 2012 15:54:28 -0700 (PDT) Received: from [192.168.1.240] (mail.gdmfinancial.com [64.122.144.190] (may be forged)) by server.saloits.com (8.14.4/8.14.3) with ESMTP id q9GMsPeI029130; Tue, 16 Oct 2012 17:54:26 -0500 Message-ID: <507DE5A7.3060601@saloits.com> Date: Tue, 16 Oct 2012 17:54:31 -0500 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: manet@ietf.org References: <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <1242EF65-BCA3-42D1-8F7D-7F595B204012@thomasclausen.org> <03B78081B371D44390ED6E7BADBB4A7721FE2E2C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE2FFE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE42F2@xmb-rcd-x02.cisco.com> <507CF076.80809@fkie.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 22:54:29 -0000 > I understand you ment that ROLL looks also in similar applications of > Zigbee as Home Networks. However, Zigbee is standard for another > organisation, but IETF does not standard that, IMHO, we don't discuss > *Zigbee standards* in IETF WGs, but we may discuss how to interoperate > MANETs or LLNs with Zigbee-Internet technologies. > The IETF maintains liaisons with numerous other standards organizations. It is reasonable, sometimes even important, for the liaison to report during a working group meeting. The IETF maintains a liaison with the ZigBee Alliance: -tjs From abdussalambaryun@gmail.com Wed Oct 17 01:56:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C805221F8585 for ; Wed, 17 Oct 2012 01:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDtA7hddsE3O for ; Wed, 17 Oct 2012 01:56:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5E0021F8749 for ; Wed, 17 Oct 2012 01:56:35 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so8486168vcb.31 for ; Wed, 17 Oct 2012 01:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Cfuknt+cKlThEL1+xf8HlAyy43/zVV1a5DfXYxdlmoU=; b=SShbR19ldbNzG64gLhSASTN7iVZA+ZGPAxflFE4xRUEObchYV4IPFIl0ND6Pca1eyw TKeXnmuM08M4c0THI/3wXdePCBe3TKmCDPsxDwek77v3la/1GwBGOeyqXRl31spfjq7p f/vDXEBrnUeJEx2LwJd5DfWn1i3e257haIkWZ6sIXzACTDfh6sLz2ZNk3SzXKjNB6JcD eAQBxQiWL2lpUFxv62eOCO2Xwo8NoF9oVYnZc752yi+XJNCtYN2spGtMQKoDnHVKpmsS 7f/sQJ5G9Qk1Jv7lE+hZwUVkxIqT59K/7VIrPEw+nxRaPVH9mRc9XOjKIUnRCDqLhDqg JrUA== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr8089242vdi.55.1350464195309; Wed, 17 Oct 2012 01:56:35 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Wed, 17 Oct 2012 01:56:34 -0700 (PDT) In-Reply-To: References: <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FE361A@xmb-rcd-x02.cisco.com> Date: Wed, 17 Oct 2012 10:56:34 +0200 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET meeting at IETF85 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 08:56:36 -0000 I agree totally with Teco, thanks Teco very much, AB On 10/16/12, Teco Boot wrote: > > Op 16 okt. 2012, om 19:53 heeft Ulrich Herberg het volgende geschreven: > >> Hi JP, >> >> On Mon, Oct 15, 2012 at 8:57 AM, JP Vasseur (jvasseur) >> wrote: >>> [...] >>> >>> I agree. But that's not we are intending to do. We intent to produce a >>> reactive protocol for MANETs, which is requested by the MANET charter. >>> LOADng is a protocol that covers all the use cases of MANETs, one of >>> which being LLNs. >> >> JP> See previous email =85. then it should be run by the WG in charge of >> routing protocol in LLN, that excluded the use of reactive routing >> after years of work. >> >> >> No. The reactive MANET protocol should be "run" by the WG that is >> chartered to produce a reactive MANET protocol. And if this protocol >> happens to be used in some large-scale LLN deployments, does not mean th= at >> it is automatically in overlap of charter, as long as that reactive >> protocol fullfils the general requirements of MANETs. >> >> >> >> >>> And yes, the introduction and title of the draft needs to be changed >> >> JP> No issue with this. >> >> Good, so you don't have an issue with having that changed. In a previous >> email you said you also don't have an issue mentioning where a protocol = is >> deployed. So I don't understand why we even continue this discussion. > +1 > >> >> >> [...] >> >> JP> I cannot speak for our AD. As a WG co-chair, the minimum would be to >> make sure that the ROLL WG reviews the work in great details. >> >> >> Every individual is very welcome to review documents at any time. This i= s >> normal IETF procedure. If you suggest that there is a LC in ROLL for a >> document in MANET, that seems like a new procedure to me that I have not >> heard before. > -1 > For me, it is not new at all that drafts pass WGLCs in multiple GWs. > If LLN is mentioned on a MANET document, it shall pass ROLL. > If the MANET protocols' name starts with L, standing for LLN, it should n= ot > be submitted in MANET. > >> >>> [...] >>> >>> >>> I sincerely suggest to wait until you read the new revision, as this >>> discussion is hypothetical without that. >> >> JP> Sure, when can we expect to see it ? >> >> >> As soon as possible. Monday October 22 is the deadline to submit new >> drafts before this IETF. > No, deadline for new drafts has passed: > 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) > submission by UTC 24:00, upload using IETF ID Submission Tool. > You have to use a time machine to get this in next MANET meeting. Or use > draft-ietf-manet-dymo-23 placeholder. > > Why not put energy in get something out? > > Teco > >> >> Best regards >> Ulrich >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Wed Oct 17 02:04:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B92A21F8611 for ; Wed, 17 Oct 2012 02:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSIjGGNITn7N for ; Wed, 17 Oct 2012 02:04:35 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63D9C21F8505 for ; Wed, 17 Oct 2012 02:04:35 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so8494270vcb.31 for ; Wed, 17 Oct 2012 02:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HUJYtWPtaY+ihqJUR5804RKugvXOt9ViOSXymkMyVn4=; b=oAxnW0zyydhzuzf/9dmDrjKxco9MvUqYsaPd1Md4xzTxy0Whrr2dWRVd/ptuRlYWXX O2qgzPtd9pi28Rf8fcJf/PXSsOwYyQDJGyMHv4ZhuDXSl63OnAywiMtM1dVKdoEHd8JJ RbqN3L/6B6/kt5WGWgOeyS3lVtaNJ9TFwTjcJd0SCQzK0C9XPr5X2f7jDWZECOPg5noE HDEehIQSI/O8dMGFNL1uHVgNkgku5bZ99lhUyI/s6oRafy0FmheI97uCea/AaEPSeybc 33pRnSCJxMd7m5yrhMR5VPcvGYPZKn8ViDblKPkBCaL6wmLEmAS7lW8K59KIqUUAmxPT uqbg== MIME-Version: 1.0 Received: by 10.220.40.16 with SMTP id i16mr273187vce.31.1350464674798; Wed, 17 Oct 2012 02:04:34 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Wed, 17 Oct 2012 02:04:34 -0700 (PDT) Date: Wed, 17 Oct 2012 11:04:34 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] AODVv2, or DYMO, Is WG I-D X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 09:04:36 -0000 > Or use > draft-ietf-manet-dymo-23 placeholder. > I did not understand why we still not seen our I-D reactive protocol renewed. I don't agree to replace it with any other, please note no one allowed to replace including the dymo-authors only after the WG permission, AB From ppcs2214@gmail.com Wed Oct 17 02:13:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0C21F8532 for ; Wed, 17 Oct 2012 02:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rCqdvQZ1-5P for ; Wed, 17 Oct 2012 02:13:48 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDF921F8530 for ; Wed, 17 Oct 2012 02:13:48 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so270452qao.10 for ; Wed, 17 Oct 2012 02:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9vLldZ/8N41kNWYFgj+Tgd1ocHtiIH6L6Pfzte+5IQk=; b=0uCcoO05x5RKJZv5u+CMuYrIHtWSRlQ1AAXz9uD25jyyXqoI2xiJKzz1qCPge2ggmJ aF68WQ22bRzh2uuTVjz07jBRtKtDyXXIa5g7Uv19vn56hMHMOgqUE7KC70EhqF/JDIDb ocAg21n/frhBxuROm6sde3g1GaqZS9WQ+4HFR02xxhakhAJjkdHRCWeGqH8jprwtbBny CurHu1c7ClsAYFs0mNB13YADUyTErhNN2MHCiluN7DqeVDrFjpfuzmO6LKx0TwwkqizX pgxm01Hb8KvIg5OiysVl5zhL27NcqGcmd0ZNJAmYND/upWhSB1phhj35S0CbltDbDWSP JV3A== MIME-Version: 1.0 Received: by 10.229.135.73 with SMTP id m9mr8483551qct.130.1350465227702; Wed, 17 Oct 2012 02:13:47 -0700 (PDT) Received: by 10.49.85.38 with HTTP; Wed, 17 Oct 2012 02:13:47 -0700 (PDT) Date: Wed, 17 Oct 2012 14:43:47 +0530 Message-ID: From: Pr To: manet@ietf.org Content-Type: multipart/alternative; boundary=485b3918a9c82dc19504cc3db058 Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 09:13:48 -0000 --485b3918a9c82dc19504cc3db058 Content-Type: text/plain; charset=ISO-8859-1 What is the formula to calculate the coverage area of a node in MANET? --485b3918a9c82dc19504cc3db058 Content-Type: text/html; charset=ISO-8859-1 What is the formula to calculate the coverage area of a node
in MANET?
--485b3918a9c82dc19504cc3db058-- From henning.rogge@fkie.fraunhofer.de Wed Oct 17 04:53:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738EC21F87BA for ; Wed, 17 Oct 2012 04:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ4WdGpfZwgz for ; Wed, 17 Oct 2012 04:53:28 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0FA21F87A2 for ; Wed, 17 Oct 2012 04:53:28 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TOSBf-0000HE-AZ; Wed, 17 Oct 2012 13:53:23 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TOSBf-0005Kc-7w; Wed, 17 Oct 2012 13:53:23 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Oct 2012 13:53:23 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 17 Oct 2012 13:53:22 +0200 Message-ID: <507E9C2B.3030605@fkie.fraunhofer.de> Date: Wed, 17 Oct 2012 13:53:15 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020801000606090007080101" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 17 Oct 2012 11:53:23.0093 (UTC) FILETIME=[0268AC50:01CDAC5E] X-Virus-Scanned: yes (ClamAV 0.97.5/15469/Wed Oct 17 01:00:22 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e1a2c87e9561ebd0ec644701fc13d4ff Cc: thomas.r.henderson@boeing.com Subject: Re: [manet] suggestions for further DLEP development X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 11:53:30 -0000 --------------ms020801000606090007080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/16/2012 02:22 AM, Henderson, Thomas R wrote: > Hi, I had a chance today to finally read the -03 dlep draft, and > catch up on the list traffic since it was published. I'd like to > suggest a few things to try to make better progress. > > First, it is very hard to review the list traffic to figure out what > has reached either WG consensus or a decision point by the authors. > There are possibly hundreds of messages with the same subject line > "Some comments on manet-dlep-03", containing many separate technical > threads. Could people please make an effort in the future to > originate a new subject line when the topic forks, and to try to > keep topics organized and separated by thread that is clear in the > subject line? Yes, we should keep attention to change the subject to a relevant topic. > It was previously suggested to use the tracker to document these > issues and their wrapup/conclusion, an idea that I offer +1 to, I have no strong opinion on this. > but > if the WG chooses to not use the tracker, perhaps some kind of > informal convention could be adopted such as posting to the list > with a clear subject such as "Decision on RFC 5444 issue for DLEP". Yes, that is a good idea. > I'd also be in favor of recording this in a change log in the draft, > for that matter, but I would be happy with just using an issue > tracker or summary messages on the list if the authors do not want to > use the draft this way. I am not sure a changelog is necessary. It might be a lot of additional=20 work. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020801000606090007080101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTcxMTUzMjBaMCMGCSqGSIb3DQEJBDEWBBQcT5/fNhi+iVtxuiXZ/rgCy7Q8YzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAm1BrNwAS2lIEpzG1q3oOuXRWEH6tzl3kUQbqxKIBCZiz jSxiiCTMGr2NAsi7hnObdYxmW8k7rOANaVo+/FQ+jG/WM6chPxpr0kKvmXRg7ILmY9NeugPn xH9OXAy3opYujbfLqF89iDtkJfomg3b7ca591lKStLt/YYoc7x8eMfXAf523dG4lpvETVIVJ ZYIhxdF6pLZeP5IKdCAbWMJt9sRzy3Fbe1SwYV0CbpFcuCUSWAAkmbpabh7zaSybuGnmTn6I QOTfy7dyM6cPmxlO4XPHSNFgiRuXBt2WP/b6F/e6lQx0RdOuWi9//dzwlWlBWhbBWfFlXTbu dWp3Qtn9igAAAAAAAA== --------------ms020801000606090007080101-- From henning.rogge@fkie.fraunhofer.de Wed Oct 17 05:08:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3331D21F8525 for ; Wed, 17 Oct 2012 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKWPn5wxh1bs for ; Wed, 17 Oct 2012 05:08:48 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16421F8514 for ; Wed, 17 Oct 2012 05:08:48 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TOSQX-0005NP-LS; Wed, 17 Oct 2012 14:08:45 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TOSQX-0005m2-Im; Wed, 17 Oct 2012 14:08:45 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Oct 2012 14:08:45 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 17 Oct 2012 14:08:45 +0200 Message-ID: <507E9FCB.40908@fkie.fraunhofer.de> Date: Wed, 17 Oct 2012 14:08:43 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070502040303040303070400" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 17 Oct 2012 12:08:45.0427 (UTC) FILETIME=[2829AC30:01CDAC60] X-Virus-Scanned: yes (ClamAV 0.97.5/15469/Wed Oct 17 01:00:22 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b83ddddaea9b835749172584385debc9 Cc: thomas.r.henderson@boeing.com Subject: [manet] status of components DLEP and consensus on them X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 12:08:49 -0000 --------------ms070502040303040303070400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Split off from the first mail... On 10/16/2012 02:22 AM, Henderson, Thomas R wrote: > Regarding the draft itself, it seems to me that there are still many > fundamental disagreements or concerns about underspecification of the > basic protocol for message exchanges and management of state between > the entities. I'd suggest first that the group try to > document/decide basic aspects of the protocol without concern for the > finer details of some of the radio-specific parameters. Such as: > > - is DLEP transport independent or not? If so, what are the > anticipated transports? While the first drafts talked about "transport independence", the=20 consensus has shifted to "UDP" as the standard transport protocol. Teco has suggesting using TCP instead of DLEP-specific ACK mechanisms. > - is there a need for a stateful session? As far as I understand it, the session is needed for flow control, but=20 would not be needed for pure 'metric delivery' from radio to router. The = authors prefer to use a session for both. > - is there a need for a per-session identifier? DLEP-layer node > identifiers? DLEP needs a radio identifier to allow multi-line radios talking over=20 the same Ethernet interface to the router. IP address and port of the=20 radio agent might be okay for this, if the radio agent can run without a = well-known port of its own. > a message sequence number? > - what are the requirements for reliable message delivery, > unreliable message delivery, etc.? > - how do acknowledgments work? Are acknowledgments on a per-TLV or > per-message basis? Currently DLEP-03 contains no sequence number, which only allows for a=20 "stop and wait" delivery of messages (send one, wait for ACK, ...). The exact mechanism how the ACK system will work is not specified, just=20 the messages are in the draft. The ACK messages are marked as "optional", which raises (in my opinion)=20 the question how a sender which expects ACKs works together with a=20 receiver which does not support ACKs. Acknowledgements are message-specific. > - who can initiate or terminate a session? While DLEP-03 shifted from "Radio initiates discovery, router initiates=20 session" to "both radio and router can support both... or not", the=20 consensus seem to be that the DLEP-02 mechanism was sufficient for DLEP=20 and is not as error prone. I expect that in future revisions of DLEP the radio MUST send discovery=20 messages via multicast and the router MUST react to them. > - RFC 5444 or not? My suggestion would be to postpone this question until the basic=20 protocol mechanisms are well defined. > - what is the version number; what is the distinction between major > and minor numbers? At the moment I see no usage for the version number. I would suggest=20 dropping it completely. > - can messages mix optional TLVs with mandatory, reliable TLVs? Is > TLV ordering to be enforced? etc. Yes, mandatory and optional TLVs can be mixed. The order of TLVs is not=20 enforced (or at least its not specified). > I'd suggest that the working group focus first on writing down and > agreeing upon some requirements and detailed protocol just to cover > the session state aspects, such that it would be really hard to come > up with implementations that did not interoperate at that level. > Then move on to the radio-specific TLVs and issues there. I agree that making sure that DLEP-conform implementations are also=20 interoperable with each other is maybe the most important work. At the=20 moment the draft contains a lot of "optional" components and nearly no=20 advise how the different possible implementations will interoperate. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070502040303040303070400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTcxMjA4NDNaMCMGCSqGSIb3DQEJBDEWBBTx3kNqWkILkaXbpDQjN8/qJZbDczBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAxFM4lgg8ydo+P3XinYfbZ8gN38/2MOYIVZI+wQJSwy4W dRZE8+hDYt/ZFwmXC7OdgQyH/BLFzUFJFwfd95OKUnl/ynC0lRijyGSs2PTgNOXpceP3JMjr ks1jQ/5aIcxJK5813E7a4eXLFBwHzBS9AYlLSGqBtg5cB7mki5VetpzWp+C8J+EdNUnMQu0x xUEfaO0xS5tO9UP30DGfZFEOyUS12c8CFjLW9HpeRT7vH2N2SdaKraV2pHf38qjNedYuZxez xSDaSaGdK6MyaVuLUnW4xbwuCPZBYpIqNVFMF1xo+IbDwmss0vY+AVntZGt3ZFVa0XOll/zt xXDRWW6WswAAAAAAAA== --------------ms070502040303040303070400-- From thierry.lys@erdfdistribution.fr Wed Oct 17 09:01:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB4C21F8605 for ; Wed, 17 Oct 2012 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.389 X-Spam-Level: X-Spam-Status: No, score=-8.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml0S8idkdbKl for ; Wed, 17 Oct 2012 09:00:56 -0700 (PDT) Received: from mtagate4.edf.fr (mtagate4.edf.fr [192.196.142.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1559A21F85E7 for ; Wed, 17 Oct 2012 09:00:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,601,1344204000"; d="scan'208,147";a="149145982" Received: from unknown (HELO XHUB003BU.notes.edfgdf.fr) ([192.196.9.98]) by PCYF1MTA4.edf.fr with ESMTP; 17 Oct 2012 17:43:48 +0200 To: manet@ietf.org MIME-Version: 1.0 X-KeepSent: 38F683BD:8734DB37-C1257A9A:0055F173; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 HF1260 October 14, 2008 From: Thierry LYS Message-ID: Date: Wed, 17 Oct 2012 18:00:47 +0200 Content-Type: multipart/related; boundary="=_related 0057F717C1257A9A_=" Subject: [manet] Experiment with 2000 nodes with LOAD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:01:02 -0000 Message en plusieurs parties au format MIME --=_related 0057F717C1257A9A_= Content-Type: multipart/alternative; boundary="=_alternative 0057F717C1257A9A_=" --=_alternative 0057F717C1257A9A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi C=E9dric Chauvenet, As mentionned in Lavenu's previous mail we have rolled-out a 2000 G3 PLC=20 (an internationally standardized PLC technology) node trial and obtained=20 excellent performances : daily collection success rate of 98 % dicovery rate of 99,7 % (the remaining meters is facing in majority HW=20 problems) It is more than a year and a half that this experiment runs ! ...and believe me, PLC is a very harsh media and routing is playing a=20 critical role here. We see along the day a very stable communication rate=20 even in duty hours (around 8 AM and 6-9 PM) This experiment proves that LOAD is a good protocol for large PLC networks = characterized by low bandwidth, unstable links and link asymmetry. We use our experience to improve it and that's how LOADng has come up ! Finally, PLC media is probably not so far from mobile networks since=20 attenuation and noise is changing with time ! Best regards, Thierry Lys ERDF Thierry Lys Direction Comptage / Metering Division Building Crysalis - 345 Avenue Georges Cl=E9menceau - 92000 Nanterre -=20 France Tel : +33 (0)1 81 97 67 77 =20 Hi C=E9dric, (Hope people will follow which cedric is talking !)=20 Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit : Dear C=E9dric,=20 I'm not sure all this discussions really make sense :=20 > An LLN network is definitely a type of MANET=20 As JP pointed out, if LLNs challenges can be addressed in MANET, why=20 would have ROLL being created ? I think that a protocol intend to LLNs, or if LLNs are included in the=20 scope should be reviewed by the ROLL working group , as it is the place=20 dedicated by the IETF. Does that makes sense ? according to what Adrian said (he has been quoted several times in the=20 past mails). One of the fileds LOADng is intended to be used are AMI PLC=20 networks with low bandwidth (few kbps in the harshest environments), but=20 can be extensible to other types of MANETs.=20 And regarding your comment about experience with LOADng :=20 > LOADng is a protocol for which several running implementations exist and = interoperate as shown in draft :=20 http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report-= 02=20 yes it has been discussed, and explained that the goal of these test were=20 focused on validating the protocol behavior, not the performance. > In addition, LOAD (the previous version) was successfully run in a 2000=20 PLC node trial.=20 Very nice !=20 Would you mind to share some details on this ? C=E9dric. I think that all the facts are on the table to say that LOAD would be=20 suitable for MANETs (LLNs being a subset of MANETs). In addition field and = lab experience does exist and demonstrated that LOADng can be very=20 efficient.=20 Regards,=20 C=E9dric=20 --=_alternative 0057F717C1257A9A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi C=E9dric Chauvenet,

As mentionned in Lavenu's previous m= ail we have rolled-out a 2000 G3 PLC  (an internationally standardized PLC technology) node trial and obtained excellent performances :
  • daily collection success rate of 98 %
  • dicovery rate of 99,7 % (the remaini= ng meters is facing in majority HW problems)

It is more than a year and a half th= at this experiment runs !

...and believe me, PLC is a very har= sh media and routing is playing a critical role here. We see along the day a very stable communication rate even in duty hours (around 8 AM and 6-9 PM)
This experiment proves that LOAD is a good protocol for large PLC networks characterized by low bandwidth, unstable links and link asymmetry.
We use our experience to improve it and that's how LOADng has come up !
Finally, PLC media is probably not so far from mobile networks since attenuation and noise is changing with time !

Best regards,

Thierry Lys
ERDF
 Thierry Lys=
Direction Comptage / Metering Division
Building Crysalis - 345 Avenue Georges Cl=E9menceau - 92000 Nanterre - Fra= nce
Tel : +33 (0)1 81 97 67 77    

Hi C=E9dric, (Hope people will follow which cedric is ta= lking !)

Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit :

Dear C=E9dric,=

I'm not sure all this discussions really make sense :

> An LLN network is definitely a type of MANET

As JP pointed out, if LLNs challenges can be addressed  in MANET, why would have ROLL being created ?
I think that a protocol intend to LLNs, or if LLNs are included in the scope should be reviewed by the ROLL working group , as it is the place dedicated by the IETF.

Does that makes sense ?

according to what Adrian said (he has been quoted several times in the past mails). One of the fileds LOADng is intended to be used are AMI PLC networks with low bandwidth (few kbps in the harshest environments), but can be extensible to other types of MANETs.

And regarding your comment about experience with LOADng :

> LOADng is a protocol for which several running implementations exist and interoperate as shown in draft : http://tools.ietf.org/html/draft-lavenu-= lln-loadng-interoperability-report-02

yes it has been discussed, and explained that the goal of these test were focused on validating the protocol behavior, not the performance.

> In addition, LOAD (the previous version) was successfully run in a 2000 PLC node trial.

Very nice !
Would you mind to share some details on this ?

C=E9dric.


I think that all the facts are on the table to say that LOAD would be suita= ble for MANETs (LLNs being a subset of MANETs). In addition field and lab exper= ience does exist and demonstrated that LOADng can be very efficient.

Regards, C=E9dric --=_alternative 0057F717C1257A9A_=-- --=_related 0057F717C1257A9A_= Content-Type: image/gif Content-ID: <_1_0B2A5F080B2A5B200057F717C1257A9A> Content-Transfer-Encoding: base64 R0lGODlhgAAqAPcAAISavcLN3kdom/Hz9xhCgqO0zShOi+Hm72aBrDdbk8Dg5BCJmkChrvD4+dLa 5oDAyXWOtJSnxbPA1uDw8iCRodDo66DQ11Z0pGCwvDCZp5DI0HC4wlCptbDY3gCBkwk1ev///wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4+BIAAAIAAAAAEwCggxcAeAET AIwBAAADxkp4ycRKeODESngAAAAAAAAAAKhzSABoDRYASA0WAGSCFwAAAAAAJAACAAAAAAAAAAAA AAAAAIj5EgDw8hUABipGeAAAEwDo8hUAnPkSAFCCFwAGKkZ4AAATAEiCFwBQghcAeAETAHgBEwAw +hIAVR9GeEAGEwD/////QPoSAB7HSnjYBxMAUIIXAGSCFwBQghcAAQAAAAAAAAD4+RIAVR9GeCgl Rnj/////CPoSADBWRnhUVkZ4kAFLeDlWRnhoDRYASA0WAGSCFwAA4P1/AAAAAAAAAAB4ARMAeAET AHgBEwB4ARMAAAATAAcAAAAAAAAAZIIXAFCCFwABAAAAAQwWABAAS3is+RIAgPoSAID6EgBVH0Z4 KCVGeP////+Q+hIAqFnodwAAEwAAAAAAAQAAAL7P4HcAAAAAAQAAAADg/X9iAGQAOIAXAFCCFwAA AAAAIAEAAFT6EgAAAAAAsP8SAGAh7HdoHud3//////////9sTkMAUIIXAAAAEwCMAQAAiIIXAICC FwBoARMAAHczZSQAAAAAeVB/ADjIAQAAAACggxcAbPoSAHgBEwCAghcAiIIXACABAAABAAAAMgQ3 ADIENwA0+xIAVR9GeBglRnj/////RPsSANGR53cAABMACAAUABgBAAC+z+B3AAAAAAAAAAAAAAAA AAAAAOTCRAC2ghcATAAWALqCFwDac0gA/////4iCFwBOw0QAtoIXACwAAAAAgAAqAAAI/wBBCBxI sKDBgwMnBHAQYALChxAjSpxIsaJFiBwQbNCYwcOhDRdDihxJsiQIBh5SLkjpwaTLlzBJMji0gKZN hzFz6tw5EOXKnykD8BxKlOQEDzV/0syAs6jTpxAjqERKdYFQqFizCtxgMynSQy21inUqlSXQBQnG qh2qoevXmoHWytV5lqqHq3PzmhyQtOuhuHoDP/ygASLfqh44CF580ENaiAE8Js3AuLLAlR4GRByQ IQMDygYbavBIOoIFzRLRaQiwerVBhq1Zy7YQOrbtAwYnqJZtG+9EDBsWJPVtMRACyX6TIoDo4MIH TR+iR19O8It06NKjJ/B9PXt0DxcKBv947j069IplgXpwEBIz4roeqBvUgP2D9ejWNRFMUB869Pwf oDPQffaRR6AxEQwUwH/SEagfRVwp9dMDAlkAwAaFIcSXW151SFOGBFlQn3nehSdQAtlhcAGK2SWA GwglZlDeBwp65x95FB1VF2YJqEdcQjS9JyRmBjmXnwYDKOTdiyxah9oERj6XoXX5CTTBAPwVaECF DF5w5ZcvTsRBckH2VZNiB224QAZmJveVeCkSFEF2GRJyXVMwSneVB9kV5J1A40mHAUkDTLWjXfIZ NMBpVwYSgAWRmWVXQfQVaOJABkiXIAgJGCMdaiCgc92U1xUEQIGEgbCgpSaZ+dZbh+D/WVFbEi4A p6AL5criB5vu+gGkDO06qEB/EuRAduEF+h0AEQCggZcXqTnkRyTVRFpDlDJ4Y33Wmdgkedx+gBeV zxUkqnnLiWgjeT9OFIhwyYFGlLIzXveYnfVGFyYIfEpXkAP1JZuvJrJaNMAGESC8AahEVdotBgBA jEEEEgvIaX8GfnCpQA7CmR9lq1pnwMQSM2xZaHFG5KsDuNFJULEDWZAdAKqmvNYECDDAmskTOfzB Mwf59i1qPldX4IMDFvgFl6xCtYHOBcE7WUi+Li3nB/Lh+xxO9ILYb3QEndpnzYJC9YFHaA402lmH MGDRnA6C+1xmJ3oaHajORXepgwGw31afpwp2+VRwNuXG4YcV5XvdsLsSnFB2V61bHs2AZud2Ueml dJCOiHkAYkRQkoefgY/x658mDIM7LInbfgA4QZVCt/FOGLSJ0ARSd9UuQhFEoPUFGxVEccSJghBx xCZucLzEx38u0AESI+C8TAKhtkEChqbEs0Adwbf77QOwfLJICFjrZl8PBSDhV2mP79QGQ3YOUZlV xeo+VB66usD0A1WQf+H3cwr94OOBgvUELEMKoFMycDilTIRw61OgUxiAvc5pwIAH0YB6pCdBp1zJ AjZZWHto0sESmvCEKBRJQAAAOw== --=_related 0057F717C1257A9A_=-- From c.chauvenet@watteco.com Wed Oct 17 09:33:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7A121F8518 for ; Wed, 17 Oct 2012 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[AWL=1.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H07AgncT+6E for ; Wed, 17 Oct 2012 09:33:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id C814421F84B3 for ; Wed, 17 Oct 2012 09:33:36 -0700 (PDT) Received: from mail40-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Oct 2012 16:33:35 +0000 Received: from mail40-va3 (localhost [127.0.0.1]) by mail40-va3-R.bigfish.com (Postfix) with ESMTP id E61E54E00A8 for ; Wed, 17 Oct 2012 16:33:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzc89bhc85dh1418I11f6Nzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail40-va3 (localhost.localdomain [127.0.0.1]) by mail40-va3 (MessageSwitch) id 1350491613236136_13156; Wed, 17 Oct 2012 16:33:33 +0000 (UTC) Received: from VA3EHSMHS045.bigfish.com (unknown [10.7.14.247]) by mail40-va3.bigfish.com (Postfix) with ESMTP id 2DB41360049; Wed, 17 Oct 2012 16:33:33 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by VA3EHSMHS045.bigfish.com (10.7.99.55) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Oct 2012 16:33:32 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.246]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0224.004; Wed, 17 Oct 2012 16:33:27 +0000 From: C Chauvenet To: Thierry LYS Thread-Topic: [manet] Experiment with 2000 nodes with LOAD Thread-Index: AQHNrICkX9Q4I6nx+EWXPWrFiWjGfJe9sUYA Date: Wed, 17 Oct 2012 16:33:27 +0000 Message-ID: <484E1309-8330-4A65-A020-F602C35A06ED@watteco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.67.132] Content-Type: multipart/alternative; boundary="_000_484E130983304A65A020F602C35A06EDwattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" Subject: Re: [manet] Experiment with 2000 nodes with LOAD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:33:43 -0000 --_000_484E130983304A65A020F602C35A06EDwattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thierry, Thank you very much for these informations, it is very interesting. Do you plan to publish something about this experiment ? I agree that PLC is a harsh media : papers from G3 deployments show that RO= BO mode is very common, in particular when HT/BT transformers are on the pa= th. C=E9dric Chauvenet. Le 17 oct. 2012 =E0 18:00, Thierry LYS a =E9crit : Hi C=E9dric Chauvenet, As mentionned in Lavenu's previous mail we have rolled-out a 2000 G3 PLC (= an internationally standardized PLC technology) node trial and obtained exc= ellent performances : * daily collection success rate of 98 % * dicovery rate of 99,7 % (the remaining meters is facing in majority H= W problems) It is more than a year and a half that this experiment runs ! ...and believe me, PLC is a very harsh media and routing is playing a criti= cal role here. We see along the day a very stable communication rate even i= n duty hours (around 8 AM and 6-9 PM) This experiment proves that LOAD is a good protocol for large PLC networks = characterized by low bandwidth, unstable links and link asymmetry. We use our experience to improve it and that's how LOADng has come up ! Finally, PLC media is probably not so far from mobile networks since attenu= ation and noise is changing with time ! Best regards, Thierry Lys ERDF Thierry Lys Direction Comptage / Metering Division Building Crysalis - 345 Avenue Georges Cl=E9menceau - 92000 Nanterre - Fran= ce Tel : +33 (0)1 81 97 67 77 Hi C=E9dric, (Hope people will follow which cedric is talking !) Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit : Dear C=E9dric, I'm not sure all this discussions really make sense : > An LLN network is definitely a type of MANET As JP pointed out, if LLNs challenges can be addressed in MANET, why would= have ROLL being created ? I think that a protocol intend to LLNs, or if LLNs are included in the scop= e should be reviewed by the ROLL working group , as it is the place dedicat= ed by the IETF. Does that makes sense ? according to what Adrian said (he has been quoted several times in the past= mails). One of the fileds LOADng is intended to be used are AMI PLC networ= ks with low bandwidth (few kbps in the harshest environments), but can be e= xtensible to other types of MANETs. And regarding your comment about experience with LOADng : > LOADng is a protocol for which several running implementations exist and = interoperate as shown in draft : http://tools.ietf.org/html/draft-lavenu-ll= n-loadng-interoperability-report-02 yes it has been discussed, and explained that the goal of these test were f= ocused on validating the protocol behavior, not the performance. > In addition, LOAD (the previous version) was successfully run in a 2000 P= LC node trial. Very nice ! Would you mind to share some details on this ? C=E9dric. I think that all the facts are on the table to say that LOAD would be suita= ble for MANETs (LLNs being a subset of MANETs). In addition field and lab e= xperience does exist and demonstrated that LOADng can be very efficient. Regards, C=E9dric _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_484E130983304A65A020F602C35A06EDwattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0AF2EDCE17238D43A4224AD5FE3C7088@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Thierry, 

Thank you very much for these informations, it is very interesting.
Do you plan to publish something about this experiment ?

I agree that PLC is a harsh media : papers from G3 deployments show th= at ROBO mode is very common, in particular when HT/BT transformers are on t= he path.

C=E9dric Chauvenet.

Le 17 oct. 2012 =E0 18:00, Thierry LYS a =E9crit :


Hi C=E9dric Chauvenet,

As mentionned in Lavenu's previous mai= l we have rolled-out a 2000 G3 PLC  (an internationally standardized P= LC technology) node trial and obtained excellent performances :
  • daily collection success rate of 9= 8 %
  • dicovery rate of 99,7 % (the = remaining meters is facing in majority HW problems)

It is more than a year and a half that= this experiment runs !

...and believe me, PLC is a very harsh= media and routing is playing a critical role here. We see along the day a = very stable communication rate even in duty hours (around 8 AM and 6-9 PM)<= /font>
This experiment proves that LOAD is a = good protocol for large PLC networks characterized by low bandwidth, unstab= le links and link asymmetry.
We use our experience to improve it an= d that's how LOADng has come up !
Finally, PLC media is probably not so = far from mobile networks since attenuation and noise is changing with time = !

Best regards,

Thierry Lys
ERDF
<Pi=E8ce jointe Mail.gif>  Thierry= Lys
Direction Comptage / Metering Division
Building Crysalis - 345 Avenue Georges Cl=E9menceau - 92000 Nanterre - Fran= ce
Tel : +33 (0)1 81 97 67 77    


Hi C=E9dric, (Hope people will follow which cedric is talk= ing !)

Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit :

Dear C=E9dric,=

I'm not sure all this discussions really make sense :

> An LLN network is definitely a type of MANET

As JP pointed out, if LLNs challenges can be addressed &nb= sp;in MANET, why would have ROLL being created ?
I think that a protocol intend to LLNs, or if LLNs are inc= luded in the scope should be reviewed by the ROLL working group , as it is = the place dedicated by the IETF.

Does that makes sense ?

according to what Adrian said (he has = been quoted several times in the past mails). One of the fileds LOADng is i= ntended to be used are AMI PLC networks with low bandwidth (few kbps in the= harshest environments), but can be extensible to other types of MANETs.

And regarding your comment about experience with LOADng :

> LOADng is a protocol for which several running implementations exist a= nd interoperate as shown in draft : <= u>http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repor= t-02

yes it has been discussed, and explained that the goal of = these test were focused on validating the protocol behavior, not the perfor= mance.

> In addition, LOAD (the previous v= ersion) was successfully run in a 2000 PLC node trial.

Very nice !
Would you mind to share some details on this ?

C=E9dric.


I think that all the facts are on the table to say that LOAD would be suita= ble for MANETs (LLNs being a subset of MANETs). In addition field and lab e= xperience does exist and demonstrated that LOADng can be very efficient.

Regards,
C=E9dric ___________________________________= ____________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_484E130983304A65A020F602C35A06EDwattecocom_-- From hrogge@googlemail.com Wed Oct 17 09:36:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9510821F8518 for ; Wed, 17 Oct 2012 09:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTe3L4wDfdYl for ; Wed, 17 Oct 2012 09:36:32 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1E6421F8570 for ; Wed, 17 Oct 2012 09:36:32 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so7320950pbb.31 for ; Wed, 17 Oct 2012 09:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/x5xgXdiVkwRyZgGtJ8TecHZmxV9M2YpJmHDjLs+Wxo=; b=J+GWaMo76GrsIhlb5phTtQM7TD5sCF0zXeaytvD0L3jQEGUlAG93qIjpdntRlA7NP/ jp1iLqWqXYwseG4Y9RoRVS6asOYe5i3NXmmwlhYq/x3ChnsZ0gDSO4ywI9B7e1JqeZld GJfOz7DPKpswd31WpqZg4q41eCARuen5vYZ99Yo6038l4Vil0K2VVt2fw+NmXENmU7aG td7jbL0NZAlm2nKsPNZ/61liuBcZjEYtkW0rxUo/DPfTsBl2eNffTAvTGq4hX20HVu+4 0d1sMY2wKs1aS+PasyFTJbMhdC6iT0dQi3lY/AHpgFO2hAnVc/rtT5WPyFfTp0jeX244 WOKQ== Received: by 10.68.138.198 with SMTP id qs6mr58283763pbb.151.1350491790858; Wed, 17 Oct 2012 09:36:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.134.43 with HTTP; Wed, 17 Oct 2012 09:36:10 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 17 Oct 2012 18:36:10 +0200 Message-ID: To: Thierry LYS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Experiment with 2000 nodes with LOAD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:36:33 -0000 On Wed, Oct 17, 2012 at 6:00 PM, Thierry LYS wrote: > > > Hi C=E9dric Chauvenet, > > As mentionned in Lavenu's previous mail we have rolled-out a 2000 G3 PLC = (an internationally standardized PLC technology) node trial and obtained e= xcellent performances : > > * daily collection success rate of 98 % > * dicovery rate of 99,7 % (the remaining meters is facing in majority HW = problems) > > > It is more than a year and a half that this experiment runs ! > > ...and believe me, PLC is a very harsh media and routing is playing a cri= tical role here. We see along the day a very stable communication rate even= in duty hours (around 8 AM and 6-9 PM) > This experiment proves that LOAD is a good protocol for large PLC network= s characterized by low bandwidth, unstable links and link asymmetry. > We use our experience to improve it and that's how LOADng has come up ! > Finally, PLC media is probably not so far from mobile networks since atte= nuation and noise is changing with time ! I am curious... how many gateways did this network has? And whats the average packetloss on a link? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From jvasseur@cisco.com Wed Oct 17 09:39:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B2421F86A3 for ; Wed, 17 Oct 2012 09:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufsffBBpQbOA for ; Wed, 17 Oct 2012 09:39:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2B23721F8619 for ; Wed, 17 Oct 2012 09:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10726; q=dns/txt; s=iport; t=1350491950; x=1351701550; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mIb6t3b7Wo2ZKqDMHOirhsjlrQjVyD+MoZGrOHXlV3M=; b=PRopHFA8ZSbpofX9BBcnCjLDbKEqbIYMd0K8ubIQq4aCBIVZbzh42c7y x/DOjn1cRrdUBjwIz7PMeH9loz2htb9dJsr7ceaLuPfSd+1/DDKVNyQG/ E5FAPBj7mZOCUDn65TTqHv7c7d7vwfgIlsql1I4oTD6CbjHRqMCR2X9Zx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOrdflCtJV2Y/2dsb2JhbABFgkq0ewGIWoEIgiABAQEDAQEBAQ8BWAMLBQsCAQgiHQcnCxQRAgQOBQgah1wGC5stoC2LWAoQhUhgA5cAjTSBa4JvgVwHHBg X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208,217";a="132685802" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 17 Oct 2012 16:39:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9HGd6Wu031610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 16:39:06 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 11:39:06 -0500 From: "JP Vasseur (jvasseur)" To: Thierry LYS Thread-Topic: [manet] Experiment with 2000 nodes with LOAD Thread-Index: AQHNrIXsX9Q4I6nx+EWXPWrFiWjGfA== Date: Wed, 17 Oct 2012 16:39:06 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FF091C@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--46.726700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FF091Cxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Experiment with 2000 nodes with LOAD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:39:11 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FF091Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Thierry for your comments, this is useful. That being said, let's bear in mind that one deployment is not sufficient t= o draw performance conclusion. This is especially true with reactive protoc= ol where the control traffic is driven by the user traffic, by contrast with r= eactive routing where the topology is built regardless of the user traffic = profile. But let's discuss about it once we have the new revisions of the drafts, se= e what the options are, =85 ROLL co-chair hat on, if Load-ng deals with LLNs, all I am asking is to mak= e sure that ROLL gets involved considering the expertise of the WG on these environments (as you rightfully pointed out, AMI PLC are clearly a very con= strained LLNs). Best Regards. JP. On Oct 17, 2012, at 6:00 PM, Thierry LYS wrote: Hi C=E9dric Chauvenet, As mentionned in Lavenu's previous mail we have rolled-out a 2000 G3 PLC (= an internationally standardized PLC technology) node trial and obtained exc= ellent performances : * daily collection success rate of 98 % * dicovery rate of 99,7 % (the remaining meters is facing in majority H= W problems) It is more than a year and a half that this experiment runs ! ...and believe me, PLC is a very harsh media and routing is playing a criti= cal role here. We see along the day a very stable communication rate even i= n duty hours (around 8 AM and 6-9 PM) This experiment proves that LOAD is a good protocol for large PLC networks = characterized by low bandwidth, unstable links and link asymmetry. We use our experience to improve it and that's how LOADng has come up ! Finally, PLC media is probably not so far from mobile networks since attenu= ation and noise is changing with time ! Best regards, Thierry Lys ERDF Thierry Lys Direction Comptage / Metering Division Building Crysalis - 345 Avenue Georges Cl=E9menceau - 92000 Nanterre - Fran= ce Tel : +33 (0)1 81 97 67 77 Hi C=E9dric, (Hope people will follow which cedric is talking !) Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit : Dear C=E9dric, I'm not sure all this discussions really make sense : > An LLN network is definitely a type of MANET As JP pointed out, if LLNs challenges can be addressed in MANET, why would= have ROLL being created ? I think that a protocol intend to LLNs, or if LLNs are included in the scop= e should be reviewed by the ROLL working group , as it is the place dedicat= ed by the IETF. Does that makes sense ? according to what Adrian said (he has been quoted several times in the past= mails). One of the fileds LOADng is intended to be used are AMI PLC networ= ks with low bandwidth (few kbps in the harshest environments), but can be e= xtensible to other types of MANETs. And regarding your comment about experience with LOADng : > LOADng is a protocol for which several running implementations exist and = interoperate as shown in draft : http://tools.ietf.org/html/draft-lavenu-ll= n-loadng-interoperability-report-02 yes it has been discussed, and explained that the goal of these test were f= ocused on validating the protocol behavior, not the performance. > In addition, LOAD (the previous version) was successfully run in a 2000 P= LC node trial. Very nice ! Would you mind to share some details on this ? C=E9dric. I think that all the facts are on the table to say that LOAD would be suita= ble for MANETs (LLNs being a subset of MANETs). In addition field and lab e= xperience does exist and demonstrated that LOADng can be very efficient. Regards, C=E9dric _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7721FF091Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Thanks Thierry for your comments, this is useful.

That being said, let's bear in mind that one deployment is not suffici= ent to draw performance conclusion. This is especially true with reactive p= rotocol
where the control traffic is driven by the user traffic, by contrast w= ith reactive routing where the topology is built regardless of the user tra= ffic profile.
But let's discuss about it once we have the new revisions of the draft= s, see what the options are, =85 

ROLL co-chair hat on, if Load-ng deals with LLNs, all I am asking is t= o make sure that ROLL gets involved considering the expertise of the WG on = these
environments (as you rightfully pointed out, AMI PLC are clearly a ver= y constrained LLNs).

Best Regards.

JP.

On Oct 17, 2012, at 6:00 PM, Thierry LYS wrote:


Hi C=E9dric Chauvenet,

As mentionned in Lavenu's previous mai= l we have rolled-out a 2000 G3 PLC  (an internationally standardized P= LC technology) node trial and obtained excellent performances :
  • daily collection success rate of 9= 8 %
  • dicovery rate of 99,7 % (the = remaining meters is facing in majority HW problems)

It is more than a year and a half that= this experiment runs !

...and believe me, PLC is a very harsh= media and routing is playing a critical role here. We see along the day a = very stable communication rate even in duty hours (around 8 AM and 6-9 PM)<= /font>
This experiment proves that LOAD is a = good protocol for large PLC networks characterized by low bandwidth, unstab= le links and link asymmetry.
We use our experience to improve it an= d that's how LOADng has come up !
Finally, PLC media is probably not so = far from mobile networks since attenuation and noise is changing with time = !

Best regards,

Thierry Lys
ERDF
<Mail Attachment.gif>  Thierry= Lys
Direction Comptage / Metering Division
Building Crysalis - 345 Avenue Georges Cl=E9menceau - 92000 Nanterre - Fran= ce
Tel : +33 (0)1 81 97 67 77    


Hi C=E9dric, (Hope people will follow which cedric is talk= ing !)

Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit :

Dear C=E9dric,=

I'm not sure all this discussions really make sense :

> An LLN network is definitely a type of MANET

As JP pointed out, if LLNs challenges can be addressed &nb= sp;in MANET, why would have ROLL being created ?
I think that a protocol intend to LLNs, or if LLNs are inc= luded in the scope should be reviewed by the ROLL working group , as it is = the place dedicated by the IETF.

Does that makes sense ?

according to what Adrian said (he has = been quoted several times in the past mails). One of the fileds LOADng is i= ntended to be used are AMI PLC networks with low bandwidth (few kbps in the= harshest environments), but can be extensible to other types of MANETs.

And regarding your comment about experience with LOADng :

> LOADng is a protocol for which several running implementations exist a= nd interoperate as shown in draft : <= u>http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repor= t-02

yes it has been discussed, and explained that the goal of = these test were focused on validating the protocol behavior, not the perfor= mance.

> In addition, LOAD (the previous v= ersion) was successfully run in a 2000 PLC node trial.

Very nice !
Would you mind to share some details on this ?

C=E9dric.


I think that all the facts are on the table to say that LOAD would be suita= ble for MANETs (LLNs being a subset of MANETs). In addition field and lab e= xperience does exist and demonstrated that LOADng can be very efficient.

Regards,
C=E9dric ___________________________________= ____________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7721FF091Cxmbrcdx02ciscoc_-- From sratliff@cisco.com Wed Oct 17 10:04:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5349A21F8587 for ; Wed, 17 Oct 2012 10:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-rjeRiUS9xo for ; Wed, 17 Oct 2012 10:04:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4321F8562 for ; Wed, 17 Oct 2012 10:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5209; q=dns/txt; s=iport; t=1350493494; x=1351703094; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oDHzfTmkYjj4xc7Qlp3QkHl9oLer1lRD/itidA/5HSs=; b=ZM8vP+KWQyyj4/rKvM+RA2vVAjD1BIM8BfztMf00mcTvazJrs6Nmxg4A URHdEceNR5DDrqqON8oDSj8NIw1VmX1mreTTNSRjUo2PJfAyEGZQ0UU7E hygS5hbe/Zpw/iC5QWw97lPdOhs2O11xg+d9spRuUS5eujddapmYUJBrT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMnkflCtJXG8/2dsb2JhbABFwCCBCIIgAQEBAwEBAQEPAVsLDAQCAQgRBAEBAQodBycLFAkIAgQOBQgTB4dcBgubNKAsi1gUhU5gA4gjnBGBa4JvgVoJNA X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="129661393" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 17 Oct 2012 17:04:53 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9HH4rDj016625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 17:04:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 12:04:53 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4CAAAUlAIAAE+oAgAAjnQCAAAVpAIAAASmAgADq2wCAAELQAIAAFCoAgAAUKgCAAAbRAIAABH6AgAE84wCAAOzCgIAAXJkAgABihYCAAhkgAIAAElsAgAFWCgA= Date: Wed, 17 Oct 2012 17:04:52 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411530@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> <92F88E39-2E83-47C0-9D79-4B46E9954EB0@inf-net.nl> In-Reply-To: <92F88E39-2E83-47C0-9D79-4B46E9954EB0@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--50.116700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <206D3F563DAD4748A36667A70F3F130A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:04:55 -0000 On Oct 16, 2012, at 4:40 PM, Teco Boot wrote: >=20 > Op 16 okt. 2012, om 21:34 heeft Goff, Thomas het volgende geschreven: >=20 >> Just a couple of comments inline below. >>=20 >> Tom >>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>> Of Bo Berry >>> Sent: Monday, October 15, 2012 4:33 AM >>> To: Henning Rogge >>> Cc: manet@ietf.org >>> Subject: Re: [manet] Some comments on manet-dlep-03 >>=20 >>>=20 >>> On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >>>=20 >>>> On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: >>>>> I've asked twice now (this email makes attempt number 3) for someone >>> to suggest some text to clarify what a router or modem would do with an >>> UNKNOWN metric. So far, what I've seen is a potentially new *way* of >>> specifying UNKNOWN - one that makes more sense than picking some >>> arbitrary code point. But no actual text to suggest what either of the >>> endpoints would *do* with the data. Maybe I'm old, feeble, and not very >>> bright - but I'm looking for suggestions that start with "A router >>> receiving a metric value of UNKNOWN MUST." or "An implementation >>> receiving an UNKNOWN indication SHOULD." or something along those >>> lines. Barring that, the only text I've got to insert is what I >>> suggested before: >>>>>>=20 >>>>>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where >>> RLQ is supported, but not currently calculable. The authors have no >>> idea under what circumstances this would occur. Routers receiving a >>> value of RLQ_UNKNOWN are free to take any action deemed appropriate, >>> including (but not limited to) ignoring the value, producing log >>> messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was >>> added at the request of the working group, as consensus formed around >>> the key ideas that this MAY allow for innovation, even though none of >>> the working group members were able to note a set of circumstances >>> under which this innovation might take place. So, in an effort to stop >>> the email storm, the authors added the additional code point." >>>>=20 >>>> If we use Teco's suggested solution (using 'length =3D 0' to make an >>> unknown but supported TLV): >>>>=20 >>>> ---- >>>> Radio implementations MAY use a metric TLV without value and length 0 >>> to signal a not measurable but supported TLV. >>>>=20 >>>> Most router implementations will process this metric TLV in the same >>> way as a missing metric TLV. >>>> ---- >>=20 >>=20 >> I would suggest that a TLV of length 0 could simply invalidate a previou= sly sent (optional) value without implying anything about measurability. >>=20 >>=20 >>>> The "will" in the second sentence could also be a "SHOULD" or "MAY", >>> I am not sure about this. >>>>=20 >>>> "Metric TLV" would be a list of all DLEP TLVs that transport a metric >>> value like RLQ, delay, current/maximum link speed, ... >>>>=20 >>>=20 >>> For my clarity, the proposal above only applies to metrics. Not >>> credits or other TLVs. >>>=20 >>> I understand the proposal to use 0-length but I'm still not >>> understanding the value. >>> If I'm developing the radio code to send the metrics, why send a 0- >>> length >>> TLV when the TLV can be omitted? This adds test vectors to be verified >>> for no >>> or little value. >>=20 >>=20 >> Maybe I'm missing something here, but it seems to me that this depends o= n if you assume a complete set of metrics is sent with each neighbor update= . If so then there's no ambiguity when an optional TLV is missing. Is thi= s implied by Section 22? >=20 > I did not read it that way. If we go for this alternative, we can skip th= e add/drop indicator in address TLVs. A mix of two mechanisms sounds crazy = to me. >=20 > Teco=20 In either event, I don't think we can skip the add/drop indicator in addres= s TLVs. It is possible for an interface to have multiple IP addresses of th= e same family (IPv4 or IPv6) assigned, so merely sending a 0-length TLV wou= ld be ambiguous.=20 Stan >=20 >>=20 >> If neighbor updates can contain incremental changes to optional items th= en having a way to invalidate previous values could be useful. >>=20 >>=20 >>> Taking the extreme of the proposal the radio can send a Neighbor Up >>> filled with >>> 0-length TLVs which would have no value or purpose from a router's >>> perspective. >>>=20 >>>=20 >>>=20 >>>> Henning Rogge >>>>=20 >>>> -- >>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>> Kommunikationssysteme (KOM) >>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Wed Oct 17 10:16:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E40C21F8669 for ; Wed, 17 Oct 2012 10:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jexp4dYlDimt for ; Wed, 17 Oct 2012 10:16:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B1BF621F8665 for ; Wed, 17 Oct 2012 10:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6113; q=dns/txt; s=iport; t=1350494198; x=1351703798; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nCPSu/VYWX46wsRhrkodgar3YKQxphVZ6LhEnW5+eg0=; b=P3IOYgEWv/GUJcE/Q4xFDyzTJoyRK9ypgTvx82ElugGu4oE4nNdo1dcp itFQSDbA7/KNqmdRkr1IyA6TJ+E++PtETgKhQ55f4vC6/+E4O1CwHt3So QDaTIQJcykq3i8GNZFriAdR2Im77ae8ViHR5J6IVW/8osidyEsc3O6VHE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIrnflCtJV2b/2dsb2JhbABFwCCBCIIgAQEBAwEBAQEPAVsLBQsCAQgYCh0HJwsUEQIEDgUIGodcBgubNaAti1gahUhgA5I6kXqBa4JvgWM0 X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="132706102" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 Oct 2012 17:16:38 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9HHGcC8023060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 17:16:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 12:16:37 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] status of components DLEP and consensus on them Thread-Index: AQHNrGAu/+j41nraj0yLd51vAMHTQZe+EWWA Date: Wed, 17 Oct 2012 17:16:37 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> In-Reply-To: <507E9FCB.40908@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--67.224900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <2AB2EFD8A673764FA8C5290E10162FBA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [manet] status of components DLEP and consensus on them X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:16:40 -0000 On Oct 17, 2012, at 8:08 AM, Henning Rogge wrote: > Split off from the first mail... >=20 > On 10/16/2012 02:22 AM, Henderson, Thomas R wrote: >> Regarding the draft itself, it seems to me that there are still many >> fundamental disagreements or concerns about underspecification of the >> basic protocol for message exchanges and management of state between >> the entities. I'd suggest first that the group try to >> document/decide basic aspects of the protocol without concern for the >> finer details of some of the radio-specific parameters. Such as: >>=20 >> - is DLEP transport independent or not? If so, what are the >> anticipated transports? >=20 > While the first drafts talked about "transport independence", the consens= us has shifted to "UDP" as the standard transport protocol. Correct.=20 >=20 > Teco has suggesting using TCP instead of DLEP-specific ACK mechanisms. I disagree with the approach of using TCP, and jettisoning DLEP-specific AC= Ks. A protocol with its own ACKS *could* be moved to other transports; othe= rwise, they (the ACKs) would have to be "reinvented" if/when someone decide= s to take DLEP from TCP to something else.=20 >=20 >> - is there a need for a stateful session? >=20 > As far as I understand it, the session is needed for flow control, but wo= uld not be needed for pure 'metric delivery' from radio to router. The auth= ors prefer to use a session for both. The session exists between router and radio. That's the only one.=20 >=20 >> - is there a need for a per-session identifier? DLEP-layer node >> identifiers? >=20 > DLEP needs a radio identifier to allow multi-line radios talking over the= same Ethernet interface to the router. IP address and port of the radio ag= ent might be okay for this, if the radio agent can run without a well-known= port of its own. Actually, in the -04 draft I'm working on, I've removed the Identification = TLV. It's not needed; an implementation can use the UDP 4-tuple (Source add= ress, Source port, Destination address, destination port) to correlate the = traffic. >=20 > > a message sequence number? >> - what are the requirements for reliable message delivery, >> unreliable message delivery, etc.? >> - how do acknowledgments work? Are acknowledgments on a per-TLV or >> per-message basis? >=20 > Currently DLEP-03 contains no sequence number, which only allows for a "s= top and wait" delivery of messages (send one, wait for ACK, =85). That was an "Oopsie" on my part. Sequence numbers will re-appear in the -04= version.=20 >=20 > The exact mechanism how the ACK system will work is not specified, just t= he messages are in the draft. I'll attempt to clarify.=20 >=20 > The ACK messages are marked as "optional", which raises (in my opinion) t= he question how a sender which expects ACKs works together with a receiver = which does not support ACKs. Another "Oopsie" (well, it's actually a longer story than that, but that st= ory will suffice)=85 ;-) ACKs are becoming mandatory. >=20 > Acknowledgements are message-specific. >=20 >> - who can initiate or terminate a session? >=20 > While DLEP-03 shifted from "Radio initiates discovery, router initiates s= ession" to "both radio and router can support both... or not", the consensu= s seem to be that the DLEP-02 mechanism was sufficient for DLEP and is not = as error prone. Correct.=20 >=20 > I expect that in future revisions of DLEP the radio MUST send discovery m= essages via multicast and the router MUST react to them. The -04 specifies that the modem-initiated discovery can be sent to *either= * the multicast address, or to a unicast address (if the radio already has = some a-priori knowledge of the address of a router). >=20 >> - RFC 5444 or not? >=20 > My suggestion would be to postpone this question until the basic protocol= mechanisms are well defined. Hmmm=85 I consider the issue to be settled, and the answer is "not". At lea= st for this draft. If someone would like to come along behind DLEP and crea= te a "DLEP over 5444" draft... >=20 >> - what is the version number; what is the distinction between major >> and minor numbers? >=20 > At the moment I see no usage for the version number. I would suggest drop= ping it completely. Disagree. As we've put in the draft from the get-go, the major-minor versio= ns *MAY* be used by an implementation to determine interoperability - e.g. = I'm at version 4, rev 2, you're at version 1, rev 6. Helps to determine whe= ther or net we can participate in useful communication.=20 >=20 >> - can messages mix optional TLVs with mandatory, reliable TLVs? Is >> TLV ordering to be enforced? etc. >=20 > Yes, mandatory and optional TLVs can be mixed. The order of TLVs is not e= nforced (or at least its not specified). >=20 >> I'd suggest that the working group focus first on writing down and >> agreeing upon some requirements and detailed protocol just to cover >> the session state aspects, such that it would be really hard to come >> up with implementations that did not interoperate at that level. >> Then move on to the radio-specific TLVs and issues there. >=20 > I agree that making sure that DLEP-conform implementations are also inter= operable with each other is maybe the most important work. At the moment th= e draft contains a lot of "optional" components and nearly no advise how th= e different possible implementations will interoperate. I would welcome suggested text=85 Stan >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Oct 17 10:22:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711FF21F8673 for ; Wed, 17 Oct 2012 10:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKw-oGPNGu4V for ; Wed, 17 Oct 2012 10:22:53 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB0B721F867A for ; Wed, 17 Oct 2012 10:22:52 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so4429810wgb.13 for ; Wed, 17 Oct 2012 10:22:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IJ8he2+dYGgIVuk/fDShfEgTid+pG7KQDPlkQAE+wVg=; b=CwVylBJzFgPvLWHNz5YiXfazc4XKCdTKtr2k4ClP5TpbWRqozHEIxiqRNuId0TYpJ4 Ktwsvr3I32Q9e5RlzYvCxsteO2KwUe19P2R7CLh7ahLvbNwV/SRPoH54Gxv2tb5QNVfD 9ZFKUEloYoKrrYkIebcrnqvZjLoOjWty1t85qquq+gJFCUbocgfgYn6GDB2x+PE9fVe1 BwWs7Mstkd5D4CCeUGzDW2xLKPPW6elV0lCRC58E6Oz4um5OTzGKeBxJBeTEuggMEGWA gXoTW3u06VFTEuAuCxgWyZtU7qCIVQSJUQWy8mA95t5Q/U8xhPUXz42eZFldBSP31UFG 3xKw== Received: by 10.180.85.99 with SMTP id g3mr5525124wiz.5.1350494568501; Wed, 17 Oct 2012 10:22:48 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:d4a2:9f52:3b7d:f28f? ([2001:470:7a9b:1:d4a2:9f52:3b7d:f28f]) by mx.google.com with ESMTPS id cu1sm25223905wib.6.2012.10.17.10.22.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 10:22:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411530@xmb-aln-x03.cisco.com> Date: Wed, 17 Oct 2012 19:22:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> <92F88E39-2E83-47C0-9D79-4B46E9954EB0@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411530@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmC8zfwKxOwWv7xR8YyAvVhA8muRZqOcYQ7vWChYkt5dv1d1c2Wr9aK6UC6kYR5iEum4PWK Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:22:54 -0000 Op 17 okt. 2012, om 19:04 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Oct 16, 2012, at 4:40 PM, Teco Boot wrote: >=20 >>=20 >> Op 16 okt. 2012, om 21:34 heeft Goff, Thomas het volgende geschreven: >>=20 >>> Just a couple of comments inline below. >>>=20 >>> Tom >>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >>>> Of Bo Berry >>>> Sent: Monday, October 15, 2012 4:33 AM >>>> To: Henning Rogge >>>> Cc: manet@ietf.org >>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>=20 >>>>=20 >>>> On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >>>>=20 >>>>> On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: >>>>>> I've asked twice now (this email makes attempt number 3) for = someone >>>> to suggest some text to clarify what a router or modem would do = with an >>>> UNKNOWN metric. So far, what I've seen is a potentially new *way* = of >>>> specifying UNKNOWN - one that makes more sense than picking some >>>> arbitrary code point. But no actual text to suggest what either of = the >>>> endpoints would *do* with the data. Maybe I'm old, feeble, and not = very >>>> bright - but I'm looking for suggestions that start with "A router >>>> receiving a metric value of UNKNOWN MUST." or "An implementation >>>> receiving an UNKNOWN indication SHOULD." or something along those >>>> lines. Barring that, the only text I've got to insert is what I >>>> suggested before: >>>>>>>=20 >>>>>>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases = where >>>> RLQ is supported, but not currently calculable. The authors have no >>>> idea under what circumstances this would occur. Routers receiving a >>>> value of RLQ_UNKNOWN are free to take any action deemed = appropriate, >>>> including (but not limited to) ignoring the value, producing log >>>> messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was >>>> added at the request of the working group, as consensus formed = around >>>> the key ideas that this MAY allow for innovation, even though none = of >>>> the working group members were able to note a set of circumstances >>>> under which this innovation might take place. So, in an effort to = stop >>>> the email storm, the authors added the additional code point." >>>>>=20 >>>>> If we use Teco's suggested solution (using 'length =3D 0' to make = an >>>> unknown but supported TLV): >>>>>=20 >>>>> ---- >>>>> Radio implementations MAY use a metric TLV without value and = length 0 >>>> to signal a not measurable but supported TLV. >>>>>=20 >>>>> Most router implementations will process this metric TLV in the = same >>>> way as a missing metric TLV. >>>>> ---- >>>=20 >>>=20 >>> I would suggest that a TLV of length 0 could simply invalidate a = previously sent (optional) value without implying anything about = measurability. >>>=20 >>>=20 >>>>> The "will" in the second sentence could also be a "SHOULD" or = "MAY", >>>> I am not sure about this. >>>>>=20 >>>>> "Metric TLV" would be a list of all DLEP TLVs that transport a = metric >>>> value like RLQ, delay, current/maximum link speed, ... >>>>>=20 >>>>=20 >>>> For my clarity, the proposal above only applies to metrics. Not >>>> credits or other TLVs. >>>>=20 >>>> I understand the proposal to use 0-length but I'm still not >>>> understanding the value. >>>> If I'm developing the radio code to send the metrics, why send a 0- >>>> length >>>> TLV when the TLV can be omitted? This adds test vectors to be = verified >>>> for no >>>> or little value. >>>=20 >>>=20 >>> Maybe I'm missing something here, but it seems to me that this = depends on if you assume a complete set of metrics is sent with each = neighbor update. If so then there's no ambiguity when an optional TLV = is missing. Is this implied by Section 22? >>=20 >> I did not read it that way. If we go for this alternative, we can = skip the add/drop indicator in address TLVs. A mix of two mechanisms = sounds crazy to me. >>=20 >> Teco=20 >=20 > In either event, I don't think we can skip the add/drop indicator in = address TLVs. It is possible for an interface to have multiple IP = addresses of the same family (IPv4 or IPv6) assigned, so merely sending = a 0-length TLV would be ambiguous.=20 Sure. I ment that if I read that with each Neighbor Update, all Data Item TLVs = MUST be send, the drop is not needed. I did not read such a requirement, = so the radio just send actual updates.=20 This update mechanism has the add, modify and delete operators. The = address TLVs have such operator, add/drop is enough. For the others, = length can be used. Length!=3D0 is add (did not exists before) or modify = (the existing data object). Delete was missing and I suggested the = Length=3D0. If we have fixed this, there is the discussion on the peer defaults. I = think that we better skip this function, then we don't have to describe = how to handle late add, modify and delete operators of those defaults. Teco > Stan >=20 >=20 >>=20 >>>=20 >>> If neighbor updates can contain incremental changes to optional = items then having a way to invalidate previous values could be useful. >>>=20 >>>=20 >>>> Taking the extreme of the proposal the radio can send a Neighbor Up >>>> filled with >>>> 0-length TLVs which would have no value or purpose from a router's >>>> perspective. >>>>=20 >>>>=20 >>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> -- >>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>> Kommunikationssysteme (KOM) >>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Wed Oct 17 10:27:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF25021F867E for ; Wed, 17 Oct 2012 10:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-Q+xQfHTtAZ for ; Wed, 17 Oct 2012 10:27:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 907F421F8661 for ; Wed, 17 Oct 2012 10:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6881; q=dns/txt; s=iport; t=1350494834; x=1351704434; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KexclcmySzl/8kXGCtnPNcJaLn3i+DSh9fAyBfVMiCI=; b=YoDUUiMcZMaNOIWzlU7D7CX+4zTB4BGhRe0KJB2g8zJ1ZRE9yHdErPBD JT5HjF0456jDB0KWxBF2vDJvzCnTxnYMXJah0lk+qY+4u0iBfH8mgOh5t sGTlt6lga/RRhxjfXC9bCFP3xdPHTQib+OpBlI6uKVtTZJhXbXbUh5NPD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADfqflCtJXG//2dsb2JhbABFwCCBCIIgAQEBAwEBAQEPAVsLBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIEweHXAYLmzigLItYFIVOYAOII5wRgWuCb4FaCTQ X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="132711769" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 17 Oct 2012 17:27:13 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9HHRChe011905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 17:27:13 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 12:27:12 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4CAAAUlAIAAE+oAgAAjnQCAAAVpAIAAASmAgADq2wCAAELQAIAAFCoAgAAUKgCAAAbRAIAABH6AgAE84wCAAOzCgIAAXJkAgABihYCAAhkgAIAAElsAgAFWCgCAAAT+AIAAAT6A Date: Wed, 17 Oct 2012 17:27:12 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41184E@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> <92F88E39-2E83-47C0-9D79-4B46E9954EB0@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411530@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--49.322500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <94E72A7CEBCD034A89C57FE35ADDCD5F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:27:14 -0000 On Oct 17, 2012, at 1:22 PM, Teco Boot wrote: >=20 > Op 17 okt. 2012, om 19:04 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >=20 >>=20 >> On Oct 16, 2012, at 4:40 PM, Teco Boot wrote: >>=20 >>>=20 >>> Op 16 okt. 2012, om 21:34 heeft Goff, Thomas het volgende geschreven: >>>=20 >>>> Just a couple of comments inline below. >>>>=20 >>>> Tom >>>>=20 >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f >>>>> Of Bo Berry >>>>> Sent: Monday, October 15, 2012 4:33 AM >>>>> To: Henning Rogge >>>>> Cc: manet@ietf.org >>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>=20 >>>>>=20 >>>>> On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >>>>>=20 >>>>>> On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: >>>>>>> I've asked twice now (this email makes attempt number 3) for someon= e >>>>> to suggest some text to clarify what a router or modem would do with = an >>>>> UNKNOWN metric. So far, what I've seen is a potentially new *way* of >>>>> specifying UNKNOWN - one that makes more sense than picking some >>>>> arbitrary code point. But no actual text to suggest what either of th= e >>>>> endpoints would *do* with the data. Maybe I'm old, feeble, and not ve= ry >>>>> bright - but I'm looking for suggestions that start with "A router >>>>> receiving a metric value of UNKNOWN MUST." or "An implementation >>>>> receiving an UNKNOWN indication SHOULD." or something along those >>>>> lines. Barring that, the only text I've got to insert is what I >>>>> suggested before: >>>>>>>>=20 >>>>>>>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases wher= e >>>>> RLQ is supported, but not currently calculable. The authors have no >>>>> idea under what circumstances this would occur. Routers receiving a >>>>> value of RLQ_UNKNOWN are free to take any action deemed appropriate, >>>>> including (but not limited to) ignoring the value, producing log >>>>> messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was >>>>> added at the request of the working group, as consensus formed around >>>>> the key ideas that this MAY allow for innovation, even though none of >>>>> the working group members were able to note a set of circumstances >>>>> under which this innovation might take place. So, in an effort to sto= p >>>>> the email storm, the authors added the additional code point." >>>>>>=20 >>>>>> If we use Teco's suggested solution (using 'length =3D 0' to make an >>>>> unknown but supported TLV): >>>>>>=20 >>>>>> ---- >>>>>> Radio implementations MAY use a metric TLV without value and length = 0 >>>>> to signal a not measurable but supported TLV. >>>>>>=20 >>>>>> Most router implementations will process this metric TLV in the same >>>>> way as a missing metric TLV. >>>>>> ---- >>>>=20 >>>>=20 >>>> I would suggest that a TLV of length 0 could simply invalidate a previ= ously sent (optional) value without implying anything about measurability. >>>>=20 >>>>=20 >>>>>> The "will" in the second sentence could also be a "SHOULD" or "MAY", >>>>> I am not sure about this. >>>>>>=20 >>>>>> "Metric TLV" would be a list of all DLEP TLVs that transport a metri= c >>>>> value like RLQ, delay, current/maximum link speed, ... >>>>>>=20 >>>>>=20 >>>>> For my clarity, the proposal above only applies to metrics. Not >>>>> credits or other TLVs. >>>>>=20 >>>>> I understand the proposal to use 0-length but I'm still not >>>>> understanding the value. >>>>> If I'm developing the radio code to send the metrics, why send a 0- >>>>> length >>>>> TLV when the TLV can be omitted? This adds test vectors to be verifi= ed >>>>> for no >>>>> or little value. >>>>=20 >>>>=20 >>>> Maybe I'm missing something here, but it seems to me that this depends= on if you assume a complete set of metrics is sent with each neighbor upda= te. If so then there's no ambiguity when an optional TLV is missing. Is t= his implied by Section 22? >>>=20 >>> I did not read it that way. If we go for this alternative, we can skip = the add/drop indicator in address TLVs. A mix of two mechanisms sounds craz= y to me. >>>=20 >>> Teco=20 >>=20 >> In either event, I don't think we can skip the add/drop indicator in add= ress TLVs. It is possible for an interface to have multiple IP addresses of= the same family (IPv4 or IPv6) assigned, so merely sending a 0-length TLV = would be ambiguous.=20 > Sure. > I ment that if I read that with each Neighbor Update, all Data Item TLVs = MUST be send, the drop is not needed. That hasn't been the intent with DLEP to this point. I've always assumed a = "send only the changed data" model of operation. Now that I say that, I gue= ss there was a discussion about sending all TLVs in some sort of "session-l= ess" mode of operation, but that's gone by the wayside. Regards, Stan > I did not read such a requirement, so the radio just send actual updates.= =20 > This update mechanism has the add, modify and delete operators. The addre= ss TLVs have such operator, add/drop is enough. For the others, length can = be used. Length!=3D0 is add (did not exists before) or modify (the existing= data object). Delete was missing and I suggested the Length=3D0. >=20 > If we have fixed this, there is the discussion on the peer defaults. I th= ink that we better skip this function, then we don't have to describe how t= o handle late add, modify and delete operators of those defaults. >=20 > Teco >=20 >=20 >> Stan >>=20 >>=20 >>>=20 >>>>=20 >>>> If neighbor updates can contain incremental changes to optional items = then having a way to invalidate previous values could be useful. >>>>=20 >>>>=20 >>>>> Taking the extreme of the proposal the radio can send a Neighbor Up >>>>> filled with >>>>> 0-length TLVs which would have no value or purpose from a router's >>>>> perspective. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Henning Rogge >>>>>>=20 >>>>>> -- >>>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>>> Kommunikationssysteme (KOM) >>>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.d= e >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Oct 17 10:58:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627E821F8458 for ; Wed, 17 Oct 2012 10:58:31 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7vpogi8LCtH for ; Wed, 17 Oct 2012 10:58:30 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0CA621F850B for ; Wed, 17 Oct 2012 10:58:29 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so4448297wgb.13 for ; Wed, 17 Oct 2012 10:58:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=f/Cn7jPN6QyEXSUBY3Kt5gY1HBHrckI9Budu4r2D1ds=; b=kkVNDljq9EfPKNTZiBS6AMS/dNrfSGtxNta0Bvzvvz5Zq4Lk93R3EH6aeqy1Qcr3/w qR/7QyJXl2b2UPq/GzTMgaEh+JwtEQic6Dmq/H1O92FnLuRrqoZg56u7Ib3PRra0CCnF gJULxbh0Dpo5rK8czVwkbwYmrTINFsctAId3DRDwtNnTSyu9z7oPNAn84PEwtph3jqKA Ht6gRYADZV2IY+Luzje7cfhVYgdrD9uXPQ7m++oeyehVwoMw2oAmoUXIqhL7pf6/OZyI 8S6D/oQM/rbiuyDWbT677Eo9WXd2e7N8YEcaShIiW8ES2VTXzlBBh/8rY6ffAljcGJuF kAdg== Received: by 10.180.83.227 with SMTP id t3mr5673435wiy.13.1350496708286; Wed, 17 Oct 2012 10:58:28 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id v3sm25371670wiw.7.2012.10.17.10.58.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 10:58:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41184E@xmb-aln-x03.cisco.com> Date: Wed, 17 Oct 2012 19:58:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> <92F88E39-2E83-47C0-9D79-4B46E9954EB0@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411530@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41184E@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQk/6O7PVWRFdzvh5AjQRdRZ4vnpYpfHzXuOLy3BPX7rbMCePDt1AvLbSuxpZuNuzQmUrVLd Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:58:31 -0000 Op 17 okt. 2012, om 19:27 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Oct 17, 2012, at 1:22 PM, Teco Boot wrote: >=20 >>=20 >> Op 17 okt. 2012, om 19:04 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Oct 16, 2012, at 4:40 PM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 16 okt. 2012, om 21:34 heeft Goff, Thomas het volgende = geschreven: >>>>=20 >>>>> Just a couple of comments inline below. >>>>>=20 >>>>> Tom >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >>>>>> Of Bo Berry >>>>>> Sent: Monday, October 15, 2012 4:33 AM >>>>>> To: Henning Rogge >>>>>> Cc: manet@ietf.org >>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>=20 >>>>>>=20 >>>>>> On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >>>>>>=20 >>>>>>> On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: >>>>>>>> I've asked twice now (this email makes attempt number 3) for = someone >>>>>> to suggest some text to clarify what a router or modem would do = with an >>>>>> UNKNOWN metric. So far, what I've seen is a potentially new *way* = of >>>>>> specifying UNKNOWN - one that makes more sense than picking some >>>>>> arbitrary code point. But no actual text to suggest what either = of the >>>>>> endpoints would *do* with the data. Maybe I'm old, feeble, and = not very >>>>>> bright - but I'm looking for suggestions that start with "A = router >>>>>> receiving a metric value of UNKNOWN MUST." or "An implementation >>>>>> receiving an UNKNOWN indication SHOULD." or something along those >>>>>> lines. Barring that, the only text I've got to insert is what I >>>>>> suggested before: >>>>>>>>>=20 >>>>>>>>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases = where >>>>>> RLQ is supported, but not currently calculable. The authors have = no >>>>>> idea under what circumstances this would occur. Routers receiving = a >>>>>> value of RLQ_UNKNOWN are free to take any action deemed = appropriate, >>>>>> including (but not limited to) ignoring the value, producing log >>>>>> messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value = was >>>>>> added at the request of the working group, as consensus formed = around >>>>>> the key ideas that this MAY allow for innovation, even though = none of >>>>>> the working group members were able to note a set of = circumstances >>>>>> under which this innovation might take place. So, in an effort to = stop >>>>>> the email storm, the authors added the additional code point." >>>>>>>=20 >>>>>>> If we use Teco's suggested solution (using 'length =3D 0' to = make an >>>>>> unknown but supported TLV): >>>>>>>=20 >>>>>>> ---- >>>>>>> Radio implementations MAY use a metric TLV without value and = length 0 >>>>>> to signal a not measurable but supported TLV. >>>>>>>=20 >>>>>>> Most router implementations will process this metric TLV in the = same >>>>>> way as a missing metric TLV. >>>>>>> ---- >>>>>=20 >>>>>=20 >>>>> I would suggest that a TLV of length 0 could simply invalidate a = previously sent (optional) value without implying anything about = measurability. >>>>>=20 >>>>>=20 >>>>>>> The "will" in the second sentence could also be a "SHOULD" or = "MAY", >>>>>> I am not sure about this. >>>>>>>=20 >>>>>>> "Metric TLV" would be a list of all DLEP TLVs that transport a = metric >>>>>> value like RLQ, delay, current/maximum link speed, ... >>>>>>>=20 >>>>>>=20 >>>>>> For my clarity, the proposal above only applies to metrics. Not >>>>>> credits or other TLVs. >>>>>>=20 >>>>>> I understand the proposal to use 0-length but I'm still not >>>>>> understanding the value. >>>>>> If I'm developing the radio code to send the metrics, why send a = 0- >>>>>> length >>>>>> TLV when the TLV can be omitted? This adds test vectors to be = verified >>>>>> for no >>>>>> or little value. >>>>>=20 >>>>>=20 >>>>> Maybe I'm missing something here, but it seems to me that this = depends on if you assume a complete set of metrics is sent with each = neighbor update. If so then there's no ambiguity when an optional TLV = is missing. Is this implied by Section 22? >>>>=20 >>>> I did not read it that way. If we go for this alternative, we can = skip the add/drop indicator in address TLVs. A mix of two mechanisms = sounds crazy to me. >>>>=20 >>>> Teco=20 >>>=20 >>> In either event, I don't think we can skip the add/drop indicator in = address TLVs. It is possible for an interface to have multiple IP = addresses of the same family (IPv4 or IPv6) assigned, so merely sending = a 0-length TLV would be ambiguous.=20 >> Sure. >> I ment that if I read that with each Neighbor Update, all Data Item = TLVs MUST be send, the drop is not needed. >=20 > That hasn't been the intent with DLEP to this point. I've always = assumed a "send only the changed data" model of operation. You make this clear in -04, right? Teco > Now that I say that, I guess there was a discussion about sending all = TLVs in some sort of "session-less" mode of operation, but that's gone = by the wayside. >=20 > Regards, > Stan >=20 >=20 >> I did not read such a requirement, so the radio just send actual = updates.=20 >> This update mechanism has the add, modify and delete operators. The = address TLVs have such operator, add/drop is enough. For the others, = length can be used. Length!=3D0 is add (did not exists before) or modify = (the existing data object). Delete was missing and I suggested the = Length=3D0. >>=20 >> If we have fixed this, there is the discussion on the peer defaults. = I think that we better skip this function, then we don't have to = describe how to handle late add, modify and delete operators of those = defaults. >>=20 >> Teco >>=20 >>=20 >>> Stan >>>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> If neighbor updates can contain incremental changes to optional = items then having a way to invalidate previous values could be useful. >>>>>=20 >>>>>=20 >>>>>> Taking the extreme of the proposal the radio can send a Neighbor = Up >>>>>> filled with >>>>>> 0-length TLVs which would have no value or purpose from a = router's >>>>>> perspective. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Henning Rogge >>>>>>>=20 >>>>>>> -- >>>>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>>>> Kommunikationssysteme (KOM) >>>>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>>>> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Wed Oct 17 11:08:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11A521F84D3 for ; Wed, 17 Oct 2012 11:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilSv54ohPlFu for ; Wed, 17 Oct 2012 11:08:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 920B121F8661 for ; Wed, 17 Oct 2012 11:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7568; q=dns/txt; s=iport; t=1350497293; x=1351706893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e31+5lAa15mDDSS2aUfHmQwABv5/pMAxvWFai7R9mxg=; b=jmNuxkgTe3BR6k6Wzqln87SxbmXP5qdrxVMTS6/3gCieH2Cg1jIpMare 32z+PIgundOwAQZm9KBIAE8MxrgXQOLUSvDqDeFOJ06OnmfvuRVrNhawl jxiniM37nLA0hBCctbXynIXla0PtaX27URNm649x/pXIkq8QWqPw3h3Vo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHLzflCtJV2d/2dsb2JhbABFwCaBCIIgAQEBAwEBAQEPAVsLBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIEweHXAYLm0SgJQSLWBSFTmADpDSBa4JvgVoJNA X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="132723365" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 17 Oct 2012 18:08:13 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9HI8DBk016681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 18:08:13 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 13:08:10 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Some comments on manet-dlep-03 Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4CAAAUlAIAAE+oAgAAjnQCAAAVpAIAAASmAgADq2wCAAELQAIAAFCoAgAAUKgCAAAbRAIAABH6AgAE84wCAAOzCgIAAXJkAgABihYCAAhkgAIAAElsAgAFWCgCAAAT+AIAAAT6AgAAIuoCAAAK6AA== Date: Wed, 17 Oct 2012 18:08:10 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F4119F7@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F40CEB9@xmb-aln-x03.cisco.com> <507BA1AA.7080607@fkie.fraunhofer.de> <6AFD35BEDB60334C9A31FD694E13EF0D47CBDA0B87@XCH-NW-18V.nw.nos.boeing.com> <92F88E39-2E83-47C0-9D79-4B46E9954EB0@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411530@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41184E@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--51.959200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <0B89DFD41A7D244F8900BC1FE18F9635@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:08:15 -0000 On Oct 17, 2012, at 1:58 PM, Teco Boot wrote: >=20 > Op 17 okt. 2012, om 19:27 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >=20 >>=20 >> On Oct 17, 2012, at 1:22 PM, Teco Boot wrote: >>=20 >>>=20 >>> Op 17 okt. 2012, om 19:04 heeft Stan Ratliff (sratliff) het volgende ge= schreven: >>>=20 >>>>=20 >>>> On Oct 16, 2012, at 4:40 PM, Teco Boot wrote: >>>>=20 >>>>>=20 >>>>> Op 16 okt. 2012, om 21:34 heeft Goff, Thomas het volgende geschreven: >>>>>=20 >>>>>> Just a couple of comments inline below. >>>>>>=20 >>>>>> Tom >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Beh= alf >>>>>>> Of Bo Berry >>>>>>> Sent: Monday, October 15, 2012 4:33 AM >>>>>>> To: Henning Rogge >>>>>>> Cc: manet@ietf.org >>>>>>> Subject: Re: [manet] Some comments on manet-dlep-03 >>>>>>=20 >>>>>>>=20 >>>>>>> On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote: >>>>>>>=20 >>>>>>>> On 10/15/2012 02:08 AM, Stan Ratliff (sratliff) wrote: >>>>>>>>> I've asked twice now (this email makes attempt number 3) for some= one >>>>>>> to suggest some text to clarify what a router or modem would do wit= h an >>>>>>> UNKNOWN metric. So far, what I've seen is a potentially new *way* o= f >>>>>>> specifying UNKNOWN - one that makes more sense than picking some >>>>>>> arbitrary code point. But no actual text to suggest what either of = the >>>>>>> endpoints would *do* with the data. Maybe I'm old, feeble, and not = very >>>>>>> bright - but I'm looking for suggestions that start with "A router >>>>>>> receiving a metric value of UNKNOWN MUST." or "An implementation >>>>>>> receiving an UNKNOWN indication SHOULD." or something along those >>>>>>> lines. Barring that, the only text I've got to insert is what I >>>>>>> suggested before: >>>>>>>>>>=20 >>>>>>>>>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases wh= ere >>>>>>> RLQ is supported, but not currently calculable. The authors have no >>>>>>> idea under what circumstances this would occur. Routers receiving a >>>>>>> value of RLQ_UNKNOWN are free to take any action deemed appropriate= , >>>>>>> including (but not limited to) ignoring the value, producing log >>>>>>> messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was >>>>>>> added at the request of the working group, as consensus formed arou= nd >>>>>>> the key ideas that this MAY allow for innovation, even though none = of >>>>>>> the working group members were able to note a set of circumstances >>>>>>> under which this innovation might take place. So, in an effort to s= top >>>>>>> the email storm, the authors added the additional code point." >>>>>>>>=20 >>>>>>>> If we use Teco's suggested solution (using 'length =3D 0' to make = an >>>>>>> unknown but supported TLV): >>>>>>>>=20 >>>>>>>> ---- >>>>>>>> Radio implementations MAY use a metric TLV without value and lengt= h 0 >>>>>>> to signal a not measurable but supported TLV. >>>>>>>>=20 >>>>>>>> Most router implementations will process this metric TLV in the sa= me >>>>>>> way as a missing metric TLV. >>>>>>>> ---- >>>>>>=20 >>>>>>=20 >>>>>> I would suggest that a TLV of length 0 could simply invalidate a pre= viously sent (optional) value without implying anything about measurability= . >>>>>>=20 >>>>>>=20 >>>>>>>> The "will" in the second sentence could also be a "SHOULD" or "MAY= ", >>>>>>> I am not sure about this. >>>>>>>>=20 >>>>>>>> "Metric TLV" would be a list of all DLEP TLVs that transport a met= ric >>>>>>> value like RLQ, delay, current/maximum link speed, ... >>>>>>>>=20 >>>>>>>=20 >>>>>>> For my clarity, the proposal above only applies to metrics. Not >>>>>>> credits or other TLVs. >>>>>>>=20 >>>>>>> I understand the proposal to use 0-length but I'm still not >>>>>>> understanding the value. >>>>>>> If I'm developing the radio code to send the metrics, why send a 0- >>>>>>> length >>>>>>> TLV when the TLV can be omitted? This adds test vectors to be veri= fied >>>>>>> for no >>>>>>> or little value. >>>>>>=20 >>>>>>=20 >>>>>> Maybe I'm missing something here, but it seems to me that this depen= ds on if you assume a complete set of metrics is sent with each neighbor up= date. If so then there's no ambiguity when an optional TLV is missing. Is= this implied by Section 22? >>>>>=20 >>>>> I did not read it that way. If we go for this alternative, we can ski= p the add/drop indicator in address TLVs. A mix of two mechanisms sounds cr= azy to me. >>>>>=20 >>>>> Teco=20 >>>>=20 >>>> In either event, I don't think we can skip the add/drop indicator in a= ddress TLVs. It is possible for an interface to have multiple IP addresses = of the same family (IPv4 or IPv6) assigned, so merely sending a 0-length TL= V would be ambiguous.=20 >>> Sure. >>> I ment that if I read that with each Neighbor Update, all Data Item TLV= s MUST be send, the drop is not needed. >>=20 >> That hasn't been the intent with DLEP to this point. I've always assumed= a "send only the changed data" model of operation. > You make this clear in -04, right? >=20 Sigh=85 I thought it already was. ;-) I'll make a run at it, but as before,= suggest some text.=20 Stan > Teco >=20 >> Now that I say that, I guess there was a discussion about sending all TL= Vs in some sort of "session-less" mode of operation, but that's gone by the= wayside. >>=20 >> Regards, >> Stan >>=20 >>=20 >>> I did not read such a requirement, so the radio just send actual update= s.=20 >>> This update mechanism has the add, modify and delete operators. The add= ress TLVs have such operator, add/drop is enough. For the others, length ca= n be used. Length!=3D0 is add (did not exists before) or modify (the existi= ng data object). Delete was missing and I suggested the Length=3D0. >>>=20 >>> If we have fixed this, there is the discussion on the peer defaults. I = think that we better skip this function, then we don't have to describe how= to handle late add, modify and delete operators of those defaults. >>>=20 >>> Teco >>>=20 >>>=20 >>>> Stan >>>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> If neighbor updates can contain incremental changes to optional item= s then having a way to invalidate previous values could be useful. >>>>>>=20 >>>>>>=20 >>>>>>> Taking the extreme of the proposal the radio can send a Neighbor Up >>>>>>> filled with >>>>>>> 0-length TLVs which would have no value or purpose from a router's >>>>>>> perspective. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Henning Rogge >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>>>>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>>>>>>> Kommunikationssysteme (KOM) >>>>>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>>>>>>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>>>>>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer= .de >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From jpmacker@gmail.com Wed Oct 17 15:09:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26B221F8645 for ; Wed, 17 Oct 2012 15:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVehMhq4dSDC for ; Wed, 17 Oct 2012 15:09:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 075B121F8618 for ; Wed, 17 Oct 2012 15:09:32 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so8843622vbb.31 for ; Wed, 17 Oct 2012 15:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hl/UXxL7H4gUImLoDzGp7wDD1P2DylQZDGX7e61lzHc=; b=yQo+jtZIkQxkfWw2QPd6X6OsSk+iregoXFe7nrM846857boyATr9uFDpTUcC+iGVJ6 Fy5Psb+MtqBrHnJF87haEuhO19/gxhawboQJRIoXmbw+OnQsvO7xU+QmkUjU8SUeoiLT GHcdaXomoUCORyLSPCY4PvjUjHPtAK4EHHPWxAcCS18VKj7boKRkdpO317BhsHUwx/NJ eghfg4bT3mc3bd3tV4We0EoTqf51+1/vMPA+HxPvHsfHSlM2+4mS9R16/q8Jo4ljc3Gw VM0hgpMSbHeBOULgecn2UreVohS0FExIDFxI8+JXnl8v5hgqDIBg30Sw8W2O1nAc2Q55 lSZQ== MIME-Version: 1.0 Received: by 10.52.70.115 with SMTP id l19mr6141136vdu.127.1350511772444; Wed, 17 Oct 2012 15:09:32 -0700 (PDT) Received: by 10.59.5.6 with HTTP; Wed, 17 Oct 2012 15:09:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Oct 2012 18:09:32 -0400 Message-ID: From: Joseph Macker To: Pr Content-Type: multipart/alternative; boundary=20cf307abd037629dc04cc4886b7 Cc: manet@ietf.org Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:09:33 -0000 --20cf307abd037629dc04cc4886b7 Content-Type: text/plain; charset=ISO-8859-1 There is no answer to this. I also would like to desist from non-manet protocol related questions/comments etc. The manet mailing list is not a resource to discuss introductory wireless communication questions please take your question to a wiki or a textbook,etc where you can find free space propagation formulas,etc if that is what you seek. However, be aware that such questions do not have common answers but rather are dependent upon scenarios, environments, electromagnetic propagation theory, and alot of other nonlinear system variables. Simple unit disc circle models do not reflect reality but are sometimes used analytically in studying manet systems. On Wed, Oct 17, 2012 at 5:13 AM, Pr wrote: > What is the formula to calculate the coverage area of a node > in MANET? > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307abd037629dc04cc4886b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is no answer to this.

I also would like to desist from non-man= et protocol related questions/comments etc.=A0 The manet mailing list is no= t a resource to discuss introductory wireless communication questions pleas= e take your question to a wiki or a textbook,etc where you can find free sp= ace propagation formulas,etc if that is what you seek.=A0 However, be aware= that such questions do not have common answers but rather are dependent up= on scenarios, environments, electromagnetic propagation theory, and alot of= other nonlinear system variables.=A0 Simple unit disc circle models do not= reflect reality but are sometimes used analytically in studying manet syst= ems.

On Wed, Oct 17, 2012 at 5:13 AM, Pr <ppcs2= 214@gmail.com> wrote:
What is the formula to calculate the coverage area of a node
in MANET?<= br>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307abd037629dc04cc4886b7-- From thomas.r.henderson@boeing.com Wed Oct 17 19:26:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA5A11E808A for ; Wed, 17 Oct 2012 19:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5KAatUlQDrd for ; Wed, 17 Oct 2012 19:26:32 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1321F85A7 for ; Wed, 17 Oct 2012 19:26:32 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9I2QH9U030645 for ; Wed, 17 Oct 2012 19:26:18 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9I2QGaf030616 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 17 Oct 2012 19:26:16 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Wed, 17 Oct 2012 19:26:29 -0700 From: "Henderson, Thomas R" To: "'Stan Ratliff (sratliff)'" , Henning Rogge Date: Wed, 17 Oct 2012 19:26:29 -0700 Thread-Topic: DLEP session identifiers and link types (was RE: [manet] status of components DLEP and consensus on them) Thread-Index: AQHNrGAu/+j41nraj0yLd51vAMHTQZe+EWWAgABAbZA= Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C190@XCH-NW-16V.nw.nos.boeing.com> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.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 X-TM-AS-MML: No Cc: "" Subject: [manet] DLEP session identifiers and link types (was RE: status of components DLEP and consensus on them) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:26:32 -0000 > > > >> - is there a need for a per-session identifier? DLEP-layer node > >> identifiers? > > > > DLEP needs a radio identifier to allow multi-line radios talking over > the same Ethernet interface to the router. IP address and port of the > radio agent might be okay for this, if the radio agent can run without > a well-known port of its own. >=20 > Actually, in the -04 draft I'm working on, I've removed the > Identification TLV. It's not needed; an implementation can use the UDP > 4-tuple (Source address, Source port, Destination address, destination > port) to correlate the traffic. Is it possible to run DLEP over an unnumbered serial link? What will be th= e tuple in that case? Is it possible to run DLEP out-of-band (controlling a radio-router pair on = another interface pair)? If so, how are these interfaces referred to? Wha= t if the data path link is unnumbered serial? It seems that there is a need to uniquely identify control sessions for the= purposes of managing the state pertaining to a data path between radio and= router. The data path may be in band or out of band of the DLEP session t= raffic. I'm assuming that one DLEP session corresponds to exactly one data= path relationship. So, it seems like there would need to be two tuples (o= ne for control path, one for data path), and the issue could be complicated= by unnumbered links unless such links are out of scope. =20 - Tom From sratliff@cisco.com Wed Oct 17 19:40:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B33B21F85A1 for ; Wed, 17 Oct 2012 19:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYb1Z9InSiMS for ; Wed, 17 Oct 2012 19:40:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5811721F85A4 for ; Wed, 17 Oct 2012 19:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2342; q=dns/txt; s=iport; t=1350528015; x=1351737615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KBfoLiJMF8TI/PInQopNMbeXkRL/MbEmPjiAyb7WSOI=; b=CjVoSHc8MEgxYNF1qnfIe9kzxsDgM6KKZp7I+tWKxboTnhMe7FJOt423 uzkWdqJBa5LYqGjNF4c7/x7Xup4kpIAHurfCf6W/s1nwE2CuTCKjokEAB 3CmExVBBTPoRGyHRuza7tNAWm26plqB2DPOnC0pBJBSo0TFuWr+QZZj2X o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIBrf1CtJV2Z/2dsb2JhbAA7CsA4gQiCIAEBAQMBEgEnOAcQAgEIIhQFCzIlAgQODRqHXAacBaApi1gQhVJgA6Q0gWuCb4IX X-IronPort-AV: E=Sophos;i="4.80,604,1344211200"; d="scan'208";a="132838733" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 18 Oct 2012 02:40:15 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9I2eESa014705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 02:40:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 21:40:14 -0500 From: "Stan Ratliff (sratliff)" To: "Henderson, Thomas R" Thread-Topic: DLEP session identifiers and link types (was RE: [manet] status of components DLEP and consensus on them) Thread-Index: AQHNrNf9+oBiFYhO7kiAcwJkPjOd2Ze+re2A Date: Thu, 18 Oct 2012 02:40:14 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F412519@xmb-aln-x03.cisco.com> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C190@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C190@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.218] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--44.675200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP session identifiers and link types (was RE: status of components DLEP and consensus on them) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:40:16 -0000 On Oct 17, 2012, at 10:26 PM, Henderson, Thomas R wrote: >>>=20 >>>> - is there a need for a per-session identifier? DLEP-layer node >>>> identifiers? >>>=20 >>> DLEP needs a radio identifier to allow multi-line radios talking over >> the same Ethernet interface to the router. IP address and port of the >> radio agent might be okay for this, if the radio agent can run without >> a well-known port of its own. >>=20 >> Actually, in the -04 draft I'm working on, I've removed the >> Identification TLV. It's not needed; an implementation can use the UDP >> 4-tuple (Source address, Source port, Destination address, destination >> port) to correlate the traffic. >=20 > Is it possible to run DLEP over an unnumbered serial link? What will be = the tuple in that case? Good point. That makes the case for the Identification TLV. Should we keep = it? >=20 > Is it possible to run DLEP out-of-band (controlling a radio-router pair o= n another interface pair)? If so, how are these interfaces referred to? W= hat if the data path link is unnumbered serial? I have seen protocols run "out-of-band". I've even coded it. From a router = perspective, it's ridiculously complex. For example, consider a series of V= LANs. The DLEP session runs on one VLAN, the "data paths" are on the differ= ent VLANS. It required the radio to have knowledge about the VLAN configura= tion - e.g., metric packets had to basically identify "These metrics are fo= r VLAN x". All in all, the authors made the decision before the initial (no= n-WG) draft was published to only consider "in-band" management via DLEP. I= n the long run, it's much simpler.=20 >=20 > It seems that there is a need to uniquely identify control sessions for t= he purposes of managing the state pertaining to a data path between radio a= nd router. The data path may be in band or out of band of the DLEP session= traffic. I'm assuming that one DLEP session corresponds to exactly one da= ta path relationship. So, it seems like there would need to be two tuples = (one for control path, one for data path), and the issue could be complicat= ed by unnumbered links unless such links are out of scope. =20 See the above response. I don't think "out-of-band" management is a good id= ea.=20 Regards, Stan >=20 > - Tom From teco@inf-net.nl Wed Oct 17 22:50:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD75621F8608 for ; Wed, 17 Oct 2012 22:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWJi4gDXWF6o for ; Wed, 17 Oct 2012 22:50:21 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABD2A21F85F3 for ; Wed, 17 Oct 2012 22:50:19 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2181830eaa.31 for ; Wed, 17 Oct 2012 22:50:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CMYvbXtd4SReNNze3kdc99EEoLrQJ11iBruSVdM0/KM=; b=b7P2JilnyxTpeQIM2WNPpFrZvSsrIkTMiGApOEqIz25xqoa63ge5YhLVkxj1F+tskI oUnsYt/w30jJxxkwHgQcs4a3DLY8ldXmF3GFExqPqhCVxOj8kScaMwVJmiGg874GoPq4 QpbqLUxk4Sf0a4iJgK64drIKGyPL07c3NtjMadRvK1GLs8lsSNPClQQOYtJrBs+/7tf7 ZKDp8xrrIO4wGSjQB+/O0HyT9oY0PtcNcdd5WGjJI9iP6sTEYxBGbyZgJR6SLunbsL34 rhSdi3NBWZ/BOq0B0D5xz+TTk1hDCZzWgxCvjlcAlq0xEQZYbrwxw7LkQQGeUFnokgnZ N0Cg== Received: by 10.14.205.3 with SMTP id i3mr29779531eeo.18.1350539413606; Wed, 17 Oct 2012 22:50:13 -0700 (PDT) Received: from [10.87.7.40] ([80.187.201.33]) by mx.google.com with ESMTPS id z43sm19562214een.16.2012.10.17.22.50.11 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 22:50:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F412519@xmb-aln-x03.cisco.com> Date: Thu, 18 Oct 2012 07:50:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B595C63-F4F3-4C13-9688-55F99B46DFB1@inf-net.nl> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C190@XCH-NW-16V.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F412519@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnIhSE4qTzIJlDIFSxLazQYiXSieaxlX2EsaBU/L7X/74z8n348ylBM4hffgIX0KvrPyppr Cc: "Henderson, Thomas R" , "" Subject: Re: [manet] DLEP session identifiers and link types (was RE: status of components DLEP and consensus on them) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 05:50:21 -0000 Op 18 okt. 2012, om 04:40 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Oct 17, 2012, at 10:26 PM, Henderson, Thomas R wrote: >=20 >>>>=20 >>>>> - is there a need for a per-session identifier? DLEP-layer node >>>>> identifiers? >>>>=20 >>>> DLEP needs a radio identifier to allow multi-line radios talking = over >>> the same Ethernet interface to the router. IP address and port of = the >>> radio agent might be okay for this, if the radio agent can run = without >>> a well-known port of its own. >>>=20 >>> Actually, in the -04 draft I'm working on, I've removed the >>> Identification TLV. It's not needed; an implementation can use the = UDP >>> 4-tuple (Source address, Source port, Destination address, = destination >>> port) to correlate the traffic. >>=20 >> Is it possible to run DLEP over an unnumbered serial link? What will = be the tuple in that case? >=20 > Good point. That makes the case for the Identification TLV. Should we = keep it? Unnumbered router interfaces do have IP adresses. Would be "borrowed". On serial link, there must be a L2 protocol, and a filter for the DLEP = messages. The DLEP messages shall not be send over the wireless link. Question is what L2 protocol is used, and how DLEP can be implemented on = this L2 protocol. As I mentioned earlier, there is a need for a L2 link local, or some = smart (IP) filtering on the bridge. Teco >=20 >>=20 >> Is it possible to run DLEP out-of-band (controlling a radio-router = pair on another interface pair)? If so, how are these interfaces = referred to? What if the data path link is unnumbered serial? >=20 > I have seen protocols run "out-of-band". I've even coded it. =46rom a = router perspective, it's ridiculously complex. For example, consider a = series of VLANs. The DLEP session runs on one VLAN, the "data paths" are = on the different VLANS. It required the radio to have knowledge about = the VLAN configuration - e.g., metric packets had to basically identify = "These metrics are for VLAN x". All in all, the authors made the = decision before the initial (non-WG) draft was published to only = consider "in-band" management via DLEP. In the long run, it's much = simpler.=20 >=20 >>=20 >> It seems that there is a need to uniquely identify control sessions = for the purposes of managing the state pertaining to a data path between = radio and router. The data path may be in band or out of band of the = DLEP session traffic. I'm assuming that one DLEP session corresponds to = exactly one data path relationship. So, it seems like there would need = to be two tuples (one for control path, one for data path), and the = issue could be complicated by unnumbered links unless such links are out = of scope. =20 >=20 > See the above response. I don't think "out-of-band" management is a = good idea.=20 >=20 > Regards, > Stan >=20 >=20 >>=20 >> - Tom >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Oct 18 01:14:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5CC21F8611 for ; Thu, 18 Oct 2012 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB9xu1voV3DK for ; Thu, 18 Oct 2012 01:14:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40F8421F853B for ; Thu, 18 Oct 2012 01:14:41 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9345132vbb.31 for ; Thu, 18 Oct 2012 01:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=21e6vnzYGiYSUe5MyNCRIH4jzui9GYrufpw+3HKdeW8=; b=fBlGZGN7AiK0BbHZGZqJ9UuH9f3Xm0d+D+1IHcl6/0pHaosflW6MS3la++k6B4sT4M SnpeRADzozMBjCXC08ZFC6WeMmpkDikbynk1/tJEqlkw3PiacBUqEKEqbKkDrzToS5Ad WQDJrDCXwPiR72bRYFTceZcvuImIA+AYIHil0D3yXy0HbnB4sR/lXMpQ+9FT+T/VLGdS aO6j2iXxK9GzaMaELh2uyOA/EUQW4ap7yYJ96fsL4GQCXubBP3RmOu2mnznfesFWs8HF mfER/v2FhrCflCW65nrJayJs9GXN4GZmIhPE6VZZw3rPgaHlZ1mLtQxyl9IOcHoiQIqE tBXw== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr10923908vdj.99.1350548080734; Thu, 18 Oct 2012 01:14:40 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 18 Oct 2012 01:14:40 -0700 (PDT) Date: Thu, 18 Oct 2012 10:14:40 +0200 Message-ID: From: Abdussalam Baryun To: Thierry LYS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] [Roll] Is there comparisons reported between RPL and LOADng X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:14:56 -0000 Sub: Reply to a post in IETF MANET WG List, related to LLNs deployment Hi Thierry, Which LOAD specification was deployed, LOADng-05 or LOADng-04, because they are different specifications? because LOADng-05 uses MANET port and RFC5444 but LOADng-04 does not. AB +++++++++++++++++++++++++++++++++++++++++++ Sub: Re: [manet] Experiment with 2000 nodes with LOAD Date: Wed, 17 Oct 2012 18:00:47 +0200 > As mentionned in Lavenu's previous mail we have rolled-out a 2000 G3 PLC > (an internationally standardized PLC technology) node trial and obtained > excellent performances : > daily collection success rate of 98 % > dicovery rate of 99,7 % (the remaining meters is facing in majority HW > problems) > > It is more than a year and a half that this experiment runs ! > > ...and believe me, PLC is a very harsh media and routing is playing a > critical role here. We see along the day a very stable communication rate > even in duty hours (around 8 AM and 6-9 PM) > This experiment proves that LOAD is a good protocol for large PLC network= s > characterized by low bandwidth, unstable links and link asymmetry. > We use our experience to improve it and that's how LOADng has come up ! > Finally, PLC media is probably not so far from mobile networks since > attenuation and noise is changing with time ! > > Best regards, > > Thierry Lys > ERDF > > Thierry Lys > Direction Comptage / Metering Division > Building Crysalis - 345 Avenue Georges Cl=E9menceau - 92000 Nanterre - > France > Tel : +33 (0)1 81 97 67 77 > > Hi C=E9dric, (Hope people will follow which cedric is talking !) > > Le 16 oct. 2012 =E0 18:58, Cedric-2 LAVENU a =E9crit : > > Dear C=E9dric, > > I'm not sure all this discussions really make sense : > >> An LLN network is definitely a type of MANET > > As JP pointed out, if LLNs challenges can be addressed in MANET, why > would have ROLL being created ? > I think that a protocol intend to LLNs, or if LLNs are included in the > scope should be reviewed by the ROLL working group , as it is the place > dedicated by the IETF. > > Does that makes sense ? > > according to what Adrian said (he has been quoted several times in the > past mails). One of the fileds LOADng is intended to be used are AMI PLC > networks with low bandwidth (few kbps in the harshest environments), but > can be extensible to other types of MANETs. > > And regarding your comment about experience with LOADng : > >> LOADng is a protocol for which several running implementations exist and > interoperate as shown in draft : > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-repor= t-02 > > > > yes it has been discussed, and explained that the goal of these test were > focused on validating the protocol behavior, not the performance. > >> In addition, LOAD (the previous version) was successfully run in a 2000 > PLC node trial. > > Very nice ! > Would you mind to share some details on this ? > > C=E9dric. > > > I think that all the facts are on the table to say that LOAD would be > suitable for MANETs (LLNs being a subset of MANETs). In addition field an= d > lab experience does exist and demonstrated that LOADng can be very > efficient. > > Regards, > C=E9dric From jasteven@rockwellcollins.com Thu Oct 18 15:05:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A9F21F84BB for ; Thu, 18 Oct 2012 15:05: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQSn0RRZaKEj for ; Thu, 18 Oct 2012 15:05:49 -0700 (PDT) Received: from secvs02.rockwellcollins.com (secvs02.rockwellcollins.com [205.175.225.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6485B21F86E1 for ; Thu, 18 Oct 2012 15:05:49 -0700 (PDT) Received: from nosuchhost.198.131.in-addr.arpa (HELO collinscrsmtp02.rockwellcollins.com) ([131.198.63.133]) by mail-virt.rockwellcollins.com with ESMTP; 18 Oct 2012 17:05:48 -0500 To: manet@ietf.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes 652HF1303 November 21, 2007 From: jasteven@rockwellcollins.com Message-ID: Date: Thu, 18 Oct 2012 17:05:47 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 8.5.2FP2 HF162|May 16, 2011) at 10/18/2012 05:05:48 PM, Serialize complete at 10/18/2012 05:05:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0079609D86257A9B_=" Subject: [manet] DLEP discussion related to credit window per TDMA neighbor X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 22:05:51 -0000 This is a multipart message in MIME format. --=_alternative 0079609D86257A9B_= Content-Type: text/plain; charset="US-ASCII" Sorry about delay, but am finally catching up on several weeks of manet emails (whew!) On Tue, 4 Sep 2012 (was Subject Thread "Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt") , "Stan Ratliff" wrote: > > On Sep 4, 2012, at 9:17 AM, Henning Rogge wrote: > > > > If I understand DLEP right it handles a credit window per neighbor. How > > do we handle the common usecase where we have a radio with a "sender > > window", which means we have credits for sending data, but not to a > > specified receiver. > > I've never seen, nor dealt with, such a device, and we have the credit > windowing of RFC4938/RFC5578 deployed with multiple radios. What you > imply is a credit scheme that would exist from router to modem, and > the 03 DLEP specifically precludes that. > > > Lets say our radio (because of some TDMA waveform) has an outgoing > > credit window of 1000 bytes. > > Sorry, but I can't envision a TDMA radio that doesn't have a "specified > receiver". After all, isn't that the point of TDMA? That being, that > *someone* "out there" is listening at the time you're sending? Now, > there could be a broadcast/multicast slot, but that would be handled in > DLEP by using the correct MAC address (e.g. for the broadcast/multicast) > and creating a neighbor. FYI, many mobile broadcast networking radios and waveforms that I work with, dynamically assign TDMA time slot for one transmitter to be able to talk to multiple receivers (neighbors). So all of the receivers are listening in that time slot, but it is the transmitter that decides which neighbors to transmit to for each time slot based upon what packets are in its transmit queues. So a particular time slot could just include packet(s) for just a single receiver or it could include packet(s) intended for multiple receivers. The transmitter looks at the intended receiver list to select the actual transmission parameters on a per transmission basis. I.e., the transmitter picks the appropriate coding (data rate) and power to reach the intended receivers with the appropriate quality of service. These broadcast wireless networks are multihop and perform wireless routing below IP (analogous to "ethernet bridging (routing) below IP"). Thus, the transmitter can even decide whether to transmit at a high data rate to a neighbor node and let that neighbor node relay (transmit) at a high data rate to the destination (or another relay node) instead of transmitting at a low data rate directly to the destination (or another relay node) depending upon which provides the best overall wireless network performance. Network coding (whether for unicast or multicast) is similar. So in general, the payload capacity per TDMA transmission can change depending upon the set of intended receivers for that TDMA transmission. As you can image, flow control for such networks is complicated. In general, there have been different approaches depending upon the desired end-to-end QOS. For example, constant bit rate traffic (CBR) QOS is easiest to manage and maps well to a credit window per destination (whether unicast or multicast. Elastic watermarks, rate control with hysteresis, and other approaches are used for other QOS types. In general, I think that a credit scheme can work with most of these multihop broadcast networks as long as you define the neighbor as the IP neighbor and don't care if that IP neighbor is one, two, or N wireless relay hops away. Jim Stevens --=_alternative 0079609D86257A9B_= Content-Type: text/html; charset="US-ASCII"
Sorry about delay, but am finally catching up on several weeks of manet emails (whew!)

On Tue, 4 Sep 2012 (was Subject Thread "Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt") , "Stan Ratliff" wrote:
>
> On Sep 4, 2012, at 9:17 AM, Henning Rogge wrote:
> >
> > If I understand DLEP right it handles a credit window per neighbor. How
> > do we handle the common usecase where we have a radio with a "sender
> > window", which means we have credits for sending data, but not to a
> > specified receiver.
>
> I've never seen, nor dealt with, such a device, and we have the credit
> windowing of RFC4938/RFC5578 deployed with multiple radios.  What you
> imply is a credit scheme that would exist from router to modem, and
> the 03 DLEP specifically precludes that.
>
> > Lets say our radio (because of some TDMA waveform) has an outgoing
> > credit window of 1000 bytes.
>
> Sorry, but I can't envision a TDMA radio that doesn't have a "specified
> receiver". After all, isn't that the point of TDMA? That being, that
> *someone* "out there" is listening at the time you're sending? Now,
> there could be a broadcast/multicast slot, but that would be handled in
> DLEP by using the correct MAC address (e.g. for the broadcast/multicast)
> and creating a neighbor.

FYI, many mobile broadcast networking radios and waveforms that I work with, dynamically assign TDMA time slot for one transmitter to be able to talk to multiple receivers (neighbors). So all of the receivers are listening in that time slot, but it is the transmitter that decides which neighbors to transmit to for each time slot based upon what packets are in its transmit queues. So a particular time slot could just include packet(s) for just a single receiver or it could include packet(s) intended for multiple receivers.  The transmitter looks at the intended receiver list to select the actual transmission parameters on a per transmission basis.  I.e., the transmitter picks the appropriate coding (data rate) and power to reach the intended receivers with the appropriate quality of service.

These broadcast wireless networks are multihop and perform wireless routing below IP (analogous to "ethernet bridging (routing) below IP"). Thus, the transmitter can even decide whether to transmit at a high data rate to a neighbor node and let that neighbor node relay (transmit) at a high data rate to the destination (or another relay node) instead of transmitting at a low data rate directly to the destination (or another relay node) depending upon which provides the best overall wireless network performance.  Network coding (whether for unicast or multicast) is similar.

So in general, the payload capacity per TDMA transmission can change depending upon the set of intended receivers for that TDMA transmission.

As you can image, flow control for such networks is complicated. In general, there have been different approaches depending upon the desired end-to-end QOS. For example, constant bit rate traffic (CBR) QOS is easiest to manage and maps well to a credit window per destination (whether unicast or multicast. Elastic watermarks, rate control with hysteresis, and other approaches are used for other QOS types.

In general, I think that a credit scheme can work with most of these multihop broadcast networks as long as you define the neighbor as the IP neighbor and don't care if that IP neighbor is one, two, or N wireless relay hops away.

Jim Stevens --=_alternative 0079609D86257A9B_=-- From teco@inf-net.nl Thu Oct 18 23:13:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068EB21F8584 for ; Thu, 18 Oct 2012 23:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpVSjRR8r2DZ for ; Thu, 18 Oct 2012 23:13:52 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B022D21F8575 for ; Thu, 18 Oct 2012 23:13:50 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so63272wgb.13 for ; Thu, 18 Oct 2012 23:13:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=aVECI+jHEBdnQbb3hZkqdVnq5Nzf00l8+qtibQsqmLM=; b=MNA9r/oLVJ+CJOGyJZwWpuRn5Q+8qzkHJhlYEv7u6fgoAGqDqvYX2wFDcsa7G0rFvh hLw4EGjc9IMoGLh582ewxFO0cWOcMVKAPK6WNlKTPjuDCfcywlcMKovBSL6QIZhTTXTd P3y0/TFjqPTGQbTd8way0D0kX6ApOsySmN+fNh9I1tOBG/YKUeJdPvIDRt74tNbjMvzw Ms4X2Dl9xUuoEXMTw/3a4Pfzf6NMsaLSNQvS0vwvCqJDFE9hkU6jkIECY3SHfyseQ0UR Gq3TcXK7IvAVsyUaRcbZUAOEkprcHT0cEZs2xGKdBL3nIe6j5qBivlg1LhqJqezXeQtv QUDA== Received: by 10.180.87.132 with SMTP id ay4mr701568wib.5.1350627229965; Thu, 18 Oct 2012 23:13:49 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:20da:2203:9e12:3870? ([2001:470:7a9b:1:20da:2203:9e12:3870]) by mx.google.com with ESMTPS id fp6sm13111243wib.0.2012.10.18.23.13.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 23:13:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 19 Oct 2012 08:13:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5599554F-35B0-4BEF-82AE-7E4241822180@inf-net.nl> References: To: jasteven@rockwellcollins.com X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkhqFNC/z0JR++HesP4sIqadQWl/09iu6nrvymiR28wt+xYUnSPVxUb6Cxdpi6sKcDp6h3D Cc: manet@ietf.org Subject: Re: [manet] DLEP discussion related to credit window per TDMA neighbor X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 06:13:53 -0000 Op 19 okt. 2012, om 00:05 heeft jasteven@rockwellcollins.com het = volgende geschreven: >=20 > Sorry about delay, but am finally catching up on several weeks of = manet emails (whew!)=20 >=20 > On Tue, 4 Sep 2012 (was Subject Thread "Re: [manet] I-D Action: = draft-ietf-manet-dlep-03.txt") , "Stan Ratliff" wrote:=20 > >=20 > > On Sep 4, 2012, at 9:17 AM, Henning Rogge wrote:=20 > > > > > > If I understand DLEP right it handles a credit window per = neighbor. How > > > do we handle the common usecase where we have a radio with a = "sender > > > window", which means we have credits for sending data, but not to = a > > > specified receiver.=20 > > > > I've never seen, nor dealt with, such a device, and we have the = credit=20 > > windowing of RFC4938/RFC5578 deployed with multiple radios. What = you=20 > > imply is a credit scheme that would exist from router to modem, and=20= > > the 03 DLEP specifically precludes that.=20 > >=20 > > > Lets say our radio (because of some TDMA waveform) has an outgoing > > > credit window of 1000 bytes. > >=20 > > Sorry, but I can't envision a TDMA radio that doesn't have a = "specified=20 > > receiver". After all, isn't that the point of TDMA? That being, that=20= > > *someone* "out there" is listening at the time you're sending? Now,=20= > > there could be a broadcast/multicast slot, but that would be handled = in=20 > > DLEP by using the correct MAC address (e.g. for the = broadcast/multicast)=20 > > and creating a neighbor. >=20 > FYI, many mobile broadcast networking radios and waveforms that I work = with, dynamically assign TDMA time slot for one transmitter to be able = to talk to multiple receivers (neighbors). So all of the receivers are = listening in that time slot, but it is the transmitter that decides = which neighbors to transmit to for each time slot based upon what = packets are in its transmit queues. So a particular time slot could just = include packet(s) for just a single receiver or it could include = packet(s) intended for multiple receivers. The transmitter looks at the = intended receiver list to select the actual transmission parameters on a = per transmission basis. I.e., the transmitter picks the appropriate = coding (data rate) and power to reach the intended receivers with the = appropriate quality of service.=20 >=20 > These broadcast wireless networks are multihop and perform wireless = routing below IP (analogous to "ethernet bridging (routing) below IP"). = Thus, the transmitter can even decide whether to transmit at a high data = rate to a neighbor node and let that neighbor node relay (transmit) at a = high data rate to the destination (or another relay node) instead of = transmitting at a low data rate directly to the destination (or another = relay node) depending upon which provides the best overall wireless = network performance. Network coding (whether for unicast or multicast) = is similar.=20 >=20 > So in general, the payload capacity per TDMA transmission can change = depending upon the set of intended receivers for that TDMA transmission.=20= >=20 > As you can image, flow control for such networks is complicated. In = general, there have been different approaches depending upon the desired = end-to-end QOS. For example, constant bit rate traffic (CBR) QOS is = easiest to manage and maps well to a credit window per destination = (whether unicast or multicast. Elastic watermarks, rate control with = hysteresis, and other approaches are used for other QOS types.=20 >=20 > In general, I think that a credit scheme can work with most of these = multihop broadcast networks as long as you define the neighbor as the IP = neighbor and don't care if that IP neighbor is one, two, or N wireless = relay hops away.=20 You described an advanced media access mechanism, which looks familiar = to what I have worked with. Such is not easy to abstract to a flow = control mechanism. For example, there must be flow control for each dscp = codepoint. With multi-hop sub-IP paths, the flow control shall act on = bottlenecks on radio's not directly connected to the router. And there = could be nodes without a router, were all QoS handling is on the radio. = That's why I don't see flow control as a preferred solution. Handling = QoS on the radio's can easily outperform flow control for multiple = reasons. Radio's I work with just do that. I don't say I cannot see any advantage. I just say it doesn't belong in = the IETF DLEP proposed standard. Teco >=20 > Jim Stevens_______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Fri Oct 19 01:41:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D25921F85AE for ; Fri, 19 Oct 2012 01:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB8XKctF0vO9 for ; Fri, 19 Oct 2012 01:41:53 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0950321F859E for ; Fri, 19 Oct 2012 01:41:53 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TP89P-0007Tp-Ts for manet@ietf.org; Fri, 19 Oct 2012 10:41:51 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TP89P-0004lH-RH for manet@ietf.org; Fri, 19 Oct 2012 10:41:51 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Oct 2012 10:41:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 19 Oct 2012 10:41:51 +0200 Message-ID: <5081124E.9020700@fkie.fraunhofer.de> Date: Fri, 19 Oct 2012 10:41:50 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <5599554F-35B0-4BEF-82AE-7E4241822180@inf-net.nl> In-Reply-To: <5599554F-35B0-4BEF-82AE-7E4241822180@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000100030901000604010708" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 19 Oct 2012 08:41:51.0690 (UTC) FILETIME=[95D33AA0:01CDADD5] X-Virus-Scanned: yes (ClamAV 0.97.5/15476/Fri Oct 19 03:56:11 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Subject: Re: [manet] DLEP discussion related to credit window per TDMA neighbor X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:41:54 -0000 --------------ms000100030901000604010708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/19/2012 08:13 AM, Teco Boot wrote: > You described an advanced media access mechanism, which looks > familiar to what I have worked with. Such is not easy to abstract to > a flow control mechanism. For example, there must be flow control for > each dscp codepoint. With multi-hop sub-IP paths, the flow control > shall act on bottlenecks on radio's not directly connected to the > router. And there could be nodes without a router, were all QoS > handling is on the radio. That's why I don't see flow control as a > preferred solution. Handling QoS on the radio's can easily outperform > flow control for multiple reasons. Radio's I work with just do that. > > I don't say I cannot see any advantage. I just say it doesn't belong > in the IETF DLEP proposed standard. The problem is not only QoS but also buffer management. You either have=20 to manage the buffer exactly before the bottleneck (in this case the=20 radio, because its slower than the ethernet) or you have to move the=20 bottleneck (with flow control for example). Otherwise you get lots of latency. Its difficult to move the "buffer management" rules from the router to=20 the radio, so restricting the routers output to the radio (which moved=20 the bottleneck to the router) is a good strategy. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000100030901000604010708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMTkwODQxNTBaMCMGCSqGSIb3DQEJBDEWBBSm2UtzL8GWO+LgYX6ue4jqt4qg2jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAc+dBDmWXeg+zf8Qqd2E3IA+4NXU1OTYcnd1bte6c33kf pfPAEpfyAYAELTcs4kAc1Je7HPAxyr31oLkaJab1BhHQ84pJtSsk4HM/VNXBeMR3TWjSe7W0 vvBACIa18orS7NQ29mkhe1N4AeijVPOicQA2hIK+kwid22aauA9DoQRwNn76rA8Mofu3bfWG eNL8Mc9e0Dn2zu/ObxrG7kFHqSRNsmmzdaj/co3yWpCiwQpJtVbuutilzT5IqQhJjTS2F7lb 2Pv4Dm396tj87Q5VECPcyc+0tkcyJwveqP+kzSAXID46u2ch8edKst4X9IbNbjB8uPNQxWJj D/XLtZ0mhwAAAAAAAA== --------------ms000100030901000604010708-- From teco@inf-net.nl Fri Oct 19 02:16:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C9721F89A7 for ; Fri, 19 Oct 2012 02:16:37 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYcFyT3rI9am for ; Fri, 19 Oct 2012 02:16:36 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id CEACB21F88E5 for ; Fri, 19 Oct 2012 02:16:35 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id fm10so15944wgb.1 for ; Fri, 19 Oct 2012 02:16:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=HttA37WNE2IiRJotfdiiq2+XUlwbgs8ii3kwlU7pqH0=; b=bZNkfgM+Bb52rHjDHKF2/tHngJgG9iDtOUj2iTxgpAUHsJInfBRm8qKOktKQP1oPb0 b5tobHZiBfjpvlrSP1Cdf5eUz5UTo+fzvSyFvdLSqx62oylvyBtneRZaP2iTrLAAokfm s20HJahSs3PTUM5Euo/fd9jzypePAuiWt+BUSMGJoHMgEfeLXp12jV70YImC5eLdT2K4 49pDuCB/7vZsiii/xWEugdMALZdBK+RfnsG0ajk2byD3C/doo4jZ6zUDgklNJ5S0nDpb WVovSxq80ji+s//bDvFM049AbMd2kDeWkhamMTAqZC/HRDRNQORwVPhNKPFjr3wKb3eF 2NoQ== Received: by 10.216.141.16 with SMTP id f16mr462306wej.130.1350638193957; Fri, 19 Oct 2012 02:16:33 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id hv8sm144348wib.0.2012.10.19.02.16.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 02:16:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <5081124E.9020700@fkie.fraunhofer.de> Date: Fri, 19 Oct 2012 11:16:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <314D6E0B-639C-4E25-A51A-BD63166800A6@inf-net.nl> References: <5599554F-35B0-4BEF-82AE-7E4241822180@inf-net.nl> <5081124E.9020700@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnFovIdkUiOgb1ajmeI3TEtv33d2PSM39xwP0V6nOuJcis5CujLN8zPAlkWYSq/ikCRirrW Cc: manet@ietf.org Subject: Re: [manet] DLEP discussion related to credit window per TDMA neighbor X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 09:16:37 -0000 Op 19 okt. 2012, om 10:41 heeft Henning Rogge het volgende geschreven: > On 10/19/2012 08:13 AM, Teco Boot wrote: >> You described an advanced media access mechanism, which looks >> familiar to what I have worked with. Such is not easy to abstract to >> a flow control mechanism. For example, there must be flow control for >> each dscp codepoint. With multi-hop sub-IP paths, the flow control >> shall act on bottlenecks on radio's not directly connected to the >> router. And there could be nodes without a router, were all QoS >> handling is on the radio. That's why I don't see flow control as a >> preferred solution. Handling QoS on the radio's can easily outperform >> flow control for multiple reasons. Radio's I work with just do that. >>=20 >> I don't say I cannot see any advantage. I just say it doesn't belong >> in the IETF DLEP proposed standard. >=20 > The problem is not only QoS but also buffer management. You either = have to manage the buffer exactly before the bottleneck (in this case = the radio, because its slower than the ethernet) or you have to move the = bottleneck (with flow control for example). >=20 > Otherwise you get lots of latency. I don't get this. The QoS packet dispatch function shall handle = congestion, in that flows that cannot tolerate large latency doesn't = suffer from such. And yes, bufferbloat is something that needs to be = fixed.=20 >=20 > Its difficult to move the "buffer management" rules from the router to = the radio, Why? Is it more difficult than distributing policies to routers? Cannot = be so. Not in my designs. > so restricting the routers output to the radio (which moved the = bottleneck to the router) is a good strategy. Only for radio's that cannot provide basic QoS services. And it = introduces other problems, e.g. it only works for 1-hop L2 networks so = it doesn't work well in the scenario Jim Stevens described. So the options are: fix QoS on radio or, IMHO 2nd best, transfer = bottleneck from radio to router. My suggestion is to separate this from link metric exchange. These are = very different functions.=20 Teco >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From trac+manet@trac.tools.ietf.org Thu Oct 18 17:22:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDF721F84B5 for ; Thu, 18 Oct 2012 17:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t818Q+CVX+pS for ; Thu, 18 Oct 2012 17:22:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0F71921F84B2 for ; Thu, 18 Oct 2012 17:22:08 -0700 (PDT) Received: from localhost ([127.0.0.1]:35225 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TP0LZ-00082P-R6; Fri, 19 Oct 2012 02:22:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Fri, 19 Oct 2012 00:21:53 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/manet/trac/ticket/1 Message-ID: <061.72177d73cfafe05daea3d2d786e8793b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 19 Oct 2012 06:56:30 -0700 Cc: manet@ietf.org Subject: [manet] #1: Discussion about naming for the IETF reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 00:22:09 -0000 #1: Discussion about naming for the IETF reactive protocol The name DYMO was chosen for the reactive protocol as a compromise to avoid the appearance of favoritism. The two experimental reactive protocols were named "DSR" and "AODV" (standing for "Dynamic Source Routing" and "Ad-hoc Distance Vector" routing respectively). In the meantime, AODV has maintained quite a bit more interest within the IETF community compared to DSR, and there is quite a bit less name recognition for "DYMO" compared to either AODV or DSR. After discussions at IETF 82 and also preceding IETF 83, it was decided to capitalize on the name recognition of AODV by renaming the IETF reactive protocol to be "AODVv2", in analogy to the choice of OLSRv2 for the IETF standard proactive protocol derived from OLSR which was published as an IETF Experimental Protocol. For the publication of future IETF reactive protocol documents, it is proposed to adhere to the name AODVv2, even though that acronym does not yet appear in the filename for the reactive protocol specification. -- --------------------------------+----------------------------- Reporter: charliep@… | Owner: Charlie Perkins Type: task | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: reactive naming --------------------------------+----------------------------- Ticket URL: manet From charliep@computer.org Fri Oct 19 09:18:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1462121F85ED for ; Fri, 19 Oct 2012 09:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cEQXSRQQRfh for ; Fri, 19 Oct 2012 09:18:06 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 86C4821F85A4 for ; Fri, 19 Oct 2012 09:18:06 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TPFGv-0008MW-MR for manet@ietf.org; Fri, 19 Oct 2012 12:18:05 -0400 Message-ID: <50817D31.1080700@computer.org> Date: Fri, 19 Oct 2012 09:17:53 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867ce92f544deceb467e7cfc28c221cb71350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: [manet] Reactive protocol specification document status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:18:07 -0000 Hello folks, I am the manet WG's designated editor for the chartered reactive protocol specification document, currently draft-dymo. An alternative reactive protocol has been documented in draft-loadng. The authors of both documents were tasked to see whether they could work together to produce a combined reactive protocol specification for the WG. This email represents my summary of where we are and what next steps I will be taking. Working with the authors of draft-loadng, I attempted to merge the LOADng ideas into the existing IETF MANET reactive protocol draft. However, my efforts to craft a mutually acceptable merged document, and to establish an editorial process to manage further changes to the merged document, have not been successful. During this time, draft-loadng has continued to evolve, and the authors expressed their consensus opinion to abandon the current WG draft and replace it with draft-loadng. I do not believe this is the best way forward. I will be submitting a new revision of AODVv2/DYMO on Monday. For transparency, the IETF Issue tracker has been set up to track further changes to this Internet Draft. I believe that this draft can serve very well as the basis for expedient completion of the reactive charter item, and that it also satisfies the technical requirements of the LOADng protocol. Please review the draft after it is posted, and contribute issues that can be added to the tracker and then resolved. -- Regards, Charlie P. From charliep@computer.org Fri Oct 19 09:20:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B6D21F8727 for ; Fri, 19 Oct 2012 09:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 315H1YD-zTj9 for ; Fri, 19 Oct 2012 09:20:10 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E921F85C4 for ; Fri, 19 Oct 2012 09:20:09 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TPFIo-0001St-KJ for manet@ietf.org; Fri, 19 Oct 2012 12:20:02 -0400 Message-ID: <50817DA6.1060300@computer.org> Date: Fri, 19 Oct 2012 09:19:50 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: manet References: <50817D31.1080700@computer.org> In-Reply-To: <50817D31.1080700@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865890f0cdd7107a74bfc164ab160c83a6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: Re: [manet] Reactive protocol specification document status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:20:11 -0000 Hello again folks, PS. If anyone is interested in a more detailed history - just drop an email. Regards, Charlie P. On 10/19/2012 9:17 AM, Charles E. Perkins wrote: > Hello folks, > > I am the manet WG's designated editor for the chartered reactive protocol > specification document, currently draft-dymo. An alternative reactive > protocol has been documented in draft-loadng. The authors of both > documents > were tasked to see whether they could work together to produce a combined > reactive protocol specification for the WG. This email represents my > summary of where we are and what next steps I will be taking. > > Working with the authors of draft-loadng, I attempted to merge the LOADng > ideas into the existing IETF MANET reactive protocol draft. However, my > efforts to craft a mutually acceptable merged document, and to > establish an > editorial process to manage further changes to the merged document, have > not been successful. During this time, draft-loadng has continued to > evolve, > and the authors expressed their consensus opinion to abandon the current > WG draft and replace it with draft-loadng. I do not believe this is > the best > way forward. > > I will be submitting a new revision of AODVv2/DYMO on Monday. For > transparency, the IETF Issue tracker has been set up to track further > changes > to this Internet Draft. I believe that this draft can serve very > well as > the basis for expedient completion of the reactive charter item, and > that it > also satisfies the technical requirements of the LOADng protocol. > > Please review the draft after it is posted, and contribute issues that > can be added to the tracker and then resolved. > > -- > Regards, > Charlie P. -- Regards, Charlie P. From abdussalambaryun@gmail.com Fri Oct 19 09:32:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0451F21F884D for ; Fri, 19 Oct 2012 09:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCP-nQXeuZ0O for ; Fri, 19 Oct 2012 09:32:34 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD0621F8A45 for ; Fri, 19 Oct 2012 09:32:34 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so795628vcb.31 for ; Fri, 19 Oct 2012 09:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fbaVilqUcJVO9MI/051mSxfmDba0uMlBfrgiIkxfWfA=; b=AhKkB4K6UyuE5NfwGMrwo9piHIH31zqhbRLhzapbBlOF3y1/59XMw6wjdKLfOI5bc/ xriV9MeTQ0bA7IGTg0rzlyfTCc5hVlqPpgSfILISJYah23C3aKPBByDYHNfV9vqiSAjC OYqjx1DpXK/n2EVSnuWdhQmagnYtwZfI94TXy/af3kNtRVLj49cCnt+VwFWdRtfJ0nm4 rNPFyPJi6R6AiVUgcAgiRp+D8/uWx40G8fjwt69aVNv8L0Tu9nn0sQ+gwukN1YAunWvN 11SYJknQFgtKEWyDIhn0KHrZMvREEh+lGy8s4hGMtDYXCb/NHlH/yWHtQ94Mn7ZFWBW3 65bA== MIME-Version: 1.0 Received: by 10.220.40.16 with SMTP id i16mr2362931vce.31.1350664350180; Fri, 19 Oct 2012 09:32:30 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 19 Oct 2012 09:32:29 -0700 (PDT) In-Reply-To: <50817D31.1080700@computer.org> References: <50817D31.1080700@computer.org> Date: Fri, 19 Oct 2012 17:32:29 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=bcaec54a37facda70c04cc6c0c74 Cc: manet Subject: Re: [manet] Reactive protocol specification document status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:32:36 -0000 --bcaec54a37facda70c04cc6c0c74 Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie, I agree that we should complete the AODVv2 is very interesting and had alot of years work, so I will review the new work and send my comments. Please note that I already commented on the last draft and very interested that the WG submits this WG draft to IESG as soon as possible, for WG progress. I ask also whom responsible to update the milestones for AODVv2 as submitted in Dec 2012. Regards Abdussalam On Fri, Oct 19, 2012 at 5:17 PM, Charles E. Perkins wrote: > > Hello folks, > > I am the manet WG's designated editor for the chartered reactive protocol > specification document, currently draft-dymo. An alternative reactive > protocol has been documented in draft-loadng. The authors of both > documents > were tasked to see whether they could work together to produce a combined > reactive protocol specification for the WG. This email represents my > summary of where we are and what next steps I will be taking. > > Working with the authors of draft-loadng, I attempted to merge the LOADng > ideas into the existing IETF MANET reactive protocol draft. However, my > efforts to craft a mutually acceptable merged document, and to establish an > editorial process to manage further changes to the merged document, have > not been successful. During this time, draft-loadng has continued to > evolve, > and the authors expressed their consensus opinion to abandon the current > WG draft and replace it with draft-loadng. I do not believe this is the > best > way forward. > > I will be submitting a new revision of AODVv2/DYMO on Monday. For > transparency, the IETF Issue tracker has been set up to track further > changes > to this Internet Draft. I believe that this draft can serve very well as > the basis for expedient completion of the reactive charter item, and that > it > also satisfies the technical requirements of the LOADng protocol. > > Please review the draft after it is posted, and contribute issues that > can be added to the tracker and then resolved. > > -- > Regards, > Charlie P. > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --bcaec54a37facda70c04cc6c0c74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Charlie,
=A0
I agree that we should complete th= e AODVv2 is very interesting and had alot of years work, so I will review t= he new work and send my comments. Please note that I already commented on t= he last draft and very interested that the WG submits this WG draft to IESG= as soon as possible, for WG progress. I ask also whom responsible to updat= e the milestones for AODVv2 as submitted in Dec 2012.
=A0
Regards
Abdussalam

On Fri, Oct 19, 2012 at 5:17 PM, Charles E. Perkins <cha= rliep@computer.org> wrote:

Hello folks,

I am the manet WG's designated editor for the chartered reactive protoc= ol
specification document, currently draft-dymo. =A0An alternative reactive protocol has been documented in draft-loadng. =A0The authors of both docume= nts
were tasked to see whether they could work together to produce a combined reactive protocol specification for the WG. =A0This email represents my
summary of where we are and what next steps I will be taking.

Working with the authors of draft-loadng, I attempted to merge the LOADng ideas into the existing IETF MANET reactive protocol draft. However, my
efforts to craft a mutually acceptable merged document, and to establish an=
editorial process to manage further changes to the merged document, have not been successful. =A0During this time, draft-loadng has continued to evo= lve,
and the authors expressed their consensus opinion to abandon the current WG draft and replace it with draft-loadng. =A0I do not believe this is the = best
way forward.

I will be submitting a new revision of AODVv2/DYMO on Monday. =A0For
transparency, the IETF Issue tracker has been set up to track further chang= es
to this Internet Draft. =A0 I believe that this draft can serve very well a= s
the basis for expedient completion of the reactive charter item, and that i= t
also satisfies the technical requirements of the LOADng protocol.

Please review the draft after it is posted, and contribute issues that
can be added to the tracker and then resolved.

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec54a37facda70c04cc6c0c74-- From jvasseur@cisco.com Fri Oct 19 09:41:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7540621F875A for ; Fri, 19 Oct 2012 09:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhjpNHD7rfH6 for ; Fri, 19 Oct 2012 09:40:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B1F4E21F874C for ; Fri, 19 Oct 2012 09:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2201; q=dns/txt; s=iport; t=1350664859; x=1351874459; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XftbS3IuUtIhZAwzqAU2e+8wFil20v2ll0Ogf0GAJGg=; b=hDpMEUQdHII4nhMRNbnRkj9iPty1xcxeSfLr86TghFluJM7PSnf45DwW DtRWqSDMgx8O1bvzbleI2Pa5IifmvIoZSBMt53YRIS2oZO9xDMe5zGnVS 46WRWv4xWF1YVbkYiTxu2TsVz4HKg/rmW5Tx1jLgppvCsCrLTV48Ikwo2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMmBgVCtJXG+/2dsb2JhbABFwGqBCIIgAQEBAwEBAQEPASc0CwULAgEIIhQQJwslAgQOBQgSCIdcBgucS6AjBItYhg9gA6Q8gWuCb4FjNA X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="133487566" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 19 Oct 2012 16:40:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9JGexiJ016886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Oct 2012 16:40:59 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 11:40:59 -0500 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] Reactive protocol specification document status Thread-Index: AQHNrhiD0kpxYz72REymZ4X/Cxn/Bg== Date: Fri, 19 Oct 2012 16:40:58 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FFCB9F@xmb-rcd-x02.cisco.com> References: <50817D31.1080700@computer.org> In-Reply-To: <50817D31.1080700@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--40.337100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Reactive protocol specification document status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:41:00 -0000 Hi Charlie, On Oct 19, 2012, at 6:17 PM, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > I am the manet WG's designated editor for the chartered reactive protocol > specification document, currently draft-dymo. An alternative reactive > protocol has been documented in draft-loadng. The authors of both docume= nts > were tasked to see whether they could work together to produce a combined > reactive protocol specification for the WG. This email represents my > summary of where we are and what next steps I will be taking. >=20 > Working with the authors of draft-loadng, I attempted to merge the LOADng > ideas into the existing IETF MANET reactive protocol draft. However, my > efforts to craft a mutually acceptable merged document, and to establish = an > editorial process to manage further changes to the merged document, have > not been successful. During this time, draft-loadng has continued to evo= lve, > and the authors expressed their consensus opinion to abandon the current > WG draft and replace it with draft-loadng. I do not believe this is the = best > way forward. >=20 JP> I cannot agree more with you. > I will be submitting a new revision of AODVv2/DYMO on Monday. For > transparency, the IETF Issue tracker has been set up to track further cha= nges > to this Internet Draft. I believe that this draft can serve very well a= s > the basis for expedient completion of the reactive charter item, and that= it > also satisfies the technical requirements of the LOADng protocol. >=20 JP> Great news Charlie. Looking forward to seeing the new revision of the W= G document, I would personally very much favor naming AODVv2; making it=20 compatible with the other proposal is I think very valuable, as long we we = keep=20 the options of AODVv2 too. > Please review the draft after it is posted, and contribute issues that > can be added to the tracker and then resolved. >=20 JP> Will certainly do. Thanks for this effort. > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Oct 19 09:41:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED97621F876D for ; Fri, 19 Oct 2012 09:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K9Uc+dT8KvI for ; Fri, 19 Oct 2012 09:41:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B481A21F8775 for ; Fri, 19 Oct 2012 09:41:14 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so818292vbb.31 for ; Fri, 19 Oct 2012 09:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TgkMSuWoe6lpWTN9zKkmlnh7NtTDl6c48XLhbPjGwiE=; b=lV6Z2OU+n/gQFXcU6wcJIhNw350qWlWNmMX9GDHgjMA8sUeU8R0YxgviMMxvjynikq 8G/N1kRXkxQ7sArm5HoUQYWtWTL7GSXTtbXYKoS9FvEri3xso75la10YeVr3pD9AsrA6 /yPRyl3W+l7xRMNXoWQTeBmYYzyTvP4NyhXD5OGpbWANfzuCU4rioXJidtmZRgJzR0nQ vIAuTlF0H5QBYPHTu6ff/R7hokEzF2TVJzG/Kym0eUloMggQ3q0JDP4WL/uL+RKneriG sdFo7eUqe1sx332UmtSTciRn3yOGXCkXxb25hbX19ZGQO62gAyEn8qwTDY69JWbeJ2zQ qaeg== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr1936491vdv.20.1350664874149; Fri, 19 Oct 2012 09:41:14 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 19 Oct 2012 09:41:14 -0700 (PDT) In-Reply-To: <50817DA6.1060300@computer.org> References: <50817D31.1080700@computer.org> <50817DA6.1060300@computer.org> Date: Fri, 19 Oct 2012 17:41:14 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=bcaec50162bd08c68604cc6c2c37 Cc: manet Subject: Re: [manet] Reactive protocol specification document status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:41:18 -0000 --bcaec50162bd08c68604cc6c2c37 Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie > Hello again folks, > > PS. If anyone is interested in a more detailed history - just drop an > email. > >From the history I would like to know, why AODVv2 status was not presented in the last f2f meeting 84. I recommend any WG draft should have at least even a small status comment on it, in each f2f meeting, or on the list each 3 months, because I feel lost sometimes. I commented on the draft before 84 meeting and wait to see some status reflection but the meeting did not represent that. I feel like my volunteering efforts is a waste if their was no reflection as status after 3 months. AB > Regards, > Charlie P. > > > > On 10/19/2012 9:17 AM, Charles E. Perkins wrote: > >> Hello folks, >> >> I am the manet WG's designated editor for the chartered reactive protocol >> specification document, currently draft-dymo. An alternative reactive >> protocol has been documented in draft-loadng. The authors of both >> documents >> were tasked to see whether they could work together to produce a combined >> reactive protocol specification for the WG. This email represents my >> summary of where we are and what next steps I will be taking. >> >> Working with the authors of draft-loadng, I attempted to merge the LOADng >> ideas into the existing IETF MANET reactive protocol draft. However, my >> efforts to craft a mutually acceptable merged document, and to establish >> an >> editorial process to manage further changes to the merged document, have >> not been successful. During this time, draft-loadng has continued to >> evolve, >> and the authors expressed their consensus opinion to abandon the current >> WG draft and replace it with draft-loadng. I do not believe this is the >> best >> way forward. >> >> I will be submitting a new revision of AODVv2/DYMO on Monday. For >> transparency, the IETF Issue tracker has been set up to track further >> changes >> to this Internet Draft. I believe that this draft can serve very well as >> the basis for expedient completion of the reactive charter item, and that >> it >> also satisfies the technical requirements of the LOADng protocol. >> >> Please review the draft after it is posted, and contribute issues that >> can be added to the tracker and then resolved. >> >> -- >> Regards, >> Charlie P. >> > > > -- > Regards, > Charlie P. > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --bcaec50162bd08c68604cc6c2c37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Charlie
=A0
Hello again folks,

PS. If anyone is interested in a more detailed history - just drop an email= .
=A0
From the history I would like to know,= why AODVv2 status was not presented in the last f2f meeting 84. I recommen= d any WG draft should have at least even a small status comment on it, in e= ach f2f meeting, or on the list each 3 months, because I feel lost sometime= s.
=A0
=A0I commented on the draft before 84 meeting and wait t= o see some status reflection but the meeting did not represent that. I feel= like my volunteering=A0efforts is a waste if their was no reflection as st= atus after 3 months.
=A0
AB
=A0
Regards,
Charlie P.



On 10/19/2012 9:17 AM, Charles E. Perkins wrote:
Hello folks,

I am the manet WG's designated editor for the chartered reactive protoc= ol
specification document, currently draft-dymo. =A0An alternative reactive protocol has been documented in draft-loadng. =A0The authors of both docume= nts
were tasked to see whether they could work together to produce a combined reactive protocol specification for the WG. =A0This email represents my
summary of where we are and what next steps I will be taking.

Working with the authors of draft-loadng, I attempted to merge the LOADng ideas into the existing IETF MANET reactive protocol draft. However, my
efforts to craft a mutually acceptable merged document, and to establish an=
editorial process to manage further changes to the merged document, have not been successful. =A0During this time, draft-loadng has continued to evo= lve,
and the authors expressed their consensus opinion to abandon the current WG draft and replace it with draft-loadng. =A0I do not believe this is the = best
way forward.

I will be submitting a new revision of AODVv2/DYMO on Monday. =A0For
transparency, the IETF Issue tracker has been set up to track further chang= es
to this Internet Draft. =A0 I believe that this draft can serve very well a= s
the basis for expedient completion of the reactive charter item, and that i= t
also satisfies the technical requirements of the LOADng protocol.

Please review the draft after it is posted, and contribute issues that
can be added to the tracker and then resolved.

--
Regards,
Charlie P.


--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec50162bd08c68604cc6c2c37-- From charliep@computer.org Fri Oct 19 10:27:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6158821F8795 for ; Fri, 19 Oct 2012 10:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGcvgopfvbHc for ; Fri, 19 Oct 2012 10:27:01 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id E891F21F8793 for ; Fri, 19 Oct 2012 10:27:00 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TPGLc-0004Ic-1U; Fri, 19 Oct 2012 13:27:00 -0400 Message-ID: <50818D58.7080102@computer.org> Date: Fri, 19 Oct 2012 10:26:48 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: <50817D31.1080700@computer.org> <50817DA6.1060300@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b8fa13ffb086859de060ffab229b4322350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] Reactive protocol specification document status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:27:01 -0000 Hello Abdussalam, On 10/19/2012 9:41 AM, Abdussalam Baryun wrote: > > From the history I would like to know, why AODVv2 status was not > presented in the last f2f meeting 84. I recommend any WG draft should > have at least even a small status comment on it, in each f2f meeting, > or on the list each 3 months, because I feel lost sometimes. I do indeed regret that I did not make a new AODVv2 revision at the last IETF meeting. At the time, I was worried that doing so would make it even more difficult to forge an effective agreement with the LOADng author team. > I commented on the draft before 84 meeting and wait to see some > status reflection but the meeting did not represent that. I feel like > my volunteering efforts is a waste if their was no reflection as > status after 3 months. Your comments are appreciated and will be taken into account. It's true that I have delayed this path forward, and I intend to avoid any such delays in the future. -- Regards, Charlie P. From boberry@cisco.com Fri Oct 19 12:15:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262CB21F85E7 for ; Fri, 19 Oct 2012 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LOsdZ9i8XDs for ; Fri, 19 Oct 2012 12:15:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 376D221F85FE for ; Fri, 19 Oct 2012 12:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1944; q=dns/txt; s=iport; t=1350674128; x=1351883728; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=j8IMApZl6hUR9QDYIi48H9Cj0TScAd2fntb12RHrbiQ=; b=BBbxe2a7oVL5Ozv6v33ATEc+7QOSsq/NuBZqEl2Fj+2yWUthM2Phk6Tg krNKDcmO08dpFLTSJ1MCmAmeG1wanAYayhDhAe33liKpdWNWIWEaWX/64 bbY7TuO8+Dfwv2B25f38d5p4HSp+HScPHfXsE1+d0Cc19m9og+LYLEVrC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB+mgVCtJXG//2dsb2JhbABFwHSBCIIgAQEBAwEBAQEPASc0CxALRicwBhMih1wGC5t+oB8Ei1qGD2ADlW+FZIhpgWuDC4FH X-IronPort-AV: E=Sophos;i="4.80,615,1344211200"; d="scan'208";a="133546119" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 19 Oct 2012 19:15:27 +0000 Received: from [192.168.1.201] (ggsg-1vpn1-230-38.cisco.com [10.81.230.38]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9JJFRDr016330; Fri, 19 Oct 2012 19:15:27 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <50817D31.1080700@computer.org> Date: Fri, 19 Oct 2012 15:15:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5BE88520-30C2-4B77-953F-50E4E431A840@cisco.com> References: <50817D31.1080700@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1085) Cc: manet Subject: Re: [manet] Reactive protocol specification document status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:15:30 -0000 Charlie Thanks for updating and posting. Fulfilling the WG reactive charter is important.=20 -Bo On Oct 19, 2012, at 12:17 PM, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > I am the manet WG's designated editor for the chartered reactive = protocol > specification document, currently draft-dymo. An alternative reactive > protocol has been documented in draft-loadng. The authors of both = documents > were tasked to see whether they could work together to produce a = combined > reactive protocol specification for the WG. This email represents my > summary of where we are and what next steps I will be taking. >=20 > Working with the authors of draft-loadng, I attempted to merge the = LOADng > ideas into the existing IETF MANET reactive protocol draft. However, = my > efforts to craft a mutually acceptable merged document, and to = establish an > editorial process to manage further changes to the merged document, = have > not been successful. During this time, draft-loadng has continued to = evolve, > and the authors expressed their consensus opinion to abandon the = current > WG draft and replace it with draft-loadng. I do not believe this is = the best > way forward. >=20 > I will be submitting a new revision of AODVv2/DYMO on Monday. For > transparency, the IETF Issue tracker has been set up to track further = changes > to this Internet Draft. I believe that this draft can serve very = well as > the basis for expedient completion of the reactive charter item, and = that it > also satisfies the technical requirements of the LOADng protocol. >=20 > Please review the draft after it is posted, and contribute issues that > can be added to the tracker and then resolved. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Sun Oct 21 21:14:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF46221F8ABC for ; Sun, 21 Oct 2012 21:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[AWL=-3.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_92=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmRqeqMr0AqK for ; Sun, 21 Oct 2012 21:14:55 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E9DC321F8AB3 for ; Sun, 21 Oct 2012 21:14:54 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TQ9Pg-0006uV-Ef; Mon, 22 Oct 2012 00:14:53 -0400 Message-ID: <5084C834.4040206@computer.org> Date: Sun, 21 Oct 2012 21:14:44 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861947dba586c02b8b021c2f3fd5c65026350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "ian.chakeres" , manet Subject: Re: [manet] Comments For AODVv2 (manet-dymo-22) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 04:14:57 -0000 Hello again Abdussalam, Here are some responses to your suggestions from earlier this year. On 5/3/2012 1:15 PM, Abdussalam Baryun wrote: > > AB>Overall> The dymo-22 draft is well organized and represents the > protocol operations, operation location, and messages (when initiating > its process, its conditions, and how processed) in section-by-section > basis. However, it was difficult to read because I think the concept > of version 2 and because the introduction and presentation was not > representing the new issues added to the old version and even not seen > the DSR-idea use in this version as mentioned.The draft lacks > explanations of the relationship between AODV and AODVv2, because both > protocols carry the similar name it is preferable to give more details > to avoid misunderstanding. The similar name may indicate that both > protocols can work together, or that AODVv2 router understands > correctly AODV router, or they may be integrated in some network > solutions. I have added text to explain that AODVv2 is not interoperable with DSR or with AODV. > > AB> Suggesting> that section 3 put before section 2 to clarify the > definition of some items of the protocol introduction presentation. O.K. I have done this, but there may be reasons why the Terminology should precede the Applicability Statement. Right now I am not aware of any such reasons, though. > AB>I read>In the manet discussion Chakeres to Baker (C2B), dated July > 26 2010, sub:dymo-21: > C2B>The nets do not have to be mobile, and DYMO may be applicable in low power > C2B>lossy sensor networks. Without lots of details about a particular network > C2B>deployment and application traffic, it is very hard to make > C2B>generalizations in MANET. > > AB> suggest> Preferable to be mentioned in overview this discussion explanation. > AB> suggest> If this protocol is able to be used in LLN nets as well > as MANET, it is important to clarify it (LLN was only mentioned in > acknowledgement section) and its relation with LLN information > exchange requirements, because the protocol applicable to other nodes > (e.g. LLN node) including MANET nodes. I'm not sure about this. We can make sure that the protocol is suitable for reactive applications. To precisely delineate the applicability to "low power lossy sensor networks" make take the development of the protocol specification too far afield. Perhaps it would be better to wait for additional comments before adding that to the Applicability Statement. > AB>thought and questions>The word “node” was used without indicating > that it is MANET node, which its node may be a router. In addition, > Originating Node (OrigNode) in the terminology is not defined to be a > MANET node (e.g. if we compare with AODV RFC3561). So could it be a > MANET node or it could not? The intention is to allow nodes that are not AODVv2 routers to originate traffic that will be routed by AODVv2 routers towards the destination. > This makes the network architecture used > not clear. Are all nodes in this network architecture, MANET nodes? If > all messages/packets are MANET-units as RFC5444 therefore, all nodes > are MANET. Moreover, the draft has some indirect indications that > there MAY be more than one routing protocol (other than AODVv2) per > net-interface in some nodes which is preferable to be mentioned. Perhaps there is some terminology problem that needs to be resolved. Right now in the draft there is no occurrence of the term "MANET node". The word "node" is used to include network nodes that are not AODVv2 routers. And, as always, there may be other protocols in use. If there are places in the specification where this introduces ambiguity, please let me know. > > AB>thought and questions>Is the protocol a specific purpose or general > purpose or both, this should be specified. All MANET routing protocols > need the purpose statement that specifies clearly its location in > practical situation. AODVv2 is "general purpose", but by no means universal. The best ways to use AODVv2 are intended to be described in the Applicability Statement. I am not sure how to improve the description so that it resolves your comment. > > AB>thought and questions>The draft has not categorized the network’s > devices/nodes (using only the word routing instead of nodes). The > draft does not make explaination of the protocol’s interaction with ad > hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router). I believe the interaction between a general node in the network and the AODVv2 routers which have responsibility for that node is out of scope for AODVv2. As I understand it, the network organization can be almost completely arbitrary as long as the AODVv2 is explicitly able to discharge its responsibility for offering reachability to the nodes for which it is responsible. > > AB> The draft had some paragraph that not followed the RFC2119, but > some amended as (there may be other, that needs to be amended): > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > AB>page-10>required> A RteMsg REQUIRES the following information: Fixed. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-25>required> If no UnreachableNode addresses remain in the > RERR, no other handling is REQUIRED and the RERR is discarded. Fixed by using simpler rewording for clarity. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-27>required> In table title: “REQUIRED Administratively > Configured Parameters” I'm not sure about this. I don't think that all occurrences of "Required" have to be capitalized. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-27>should> Similarly, AODVv2 routers SHOULD subscribe to > LL-MANET-Routers on all their AODVv2 interfaces. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-32>must> Note that if multicast is used, any confidentiality > and integrity algorithms used MUST permit multiple receivers to handle > the message. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Fixed. > > #Abstract .... deleted because I already discussed these in an earlier email... > > #In (Content) > >> 4.2.2. Routing Message (RteMsg) - RREQ and RREP . . . . . . . 10 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> Routing Messages. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The information in this section has been reorganized. > > #In section (1. Overview) > >> Route discovery is performed when an AODVv2 router receives a packet from a >> node under its responsibility to a destination for which it does not have a >> route. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>idea not clear> which kind of node under responsibility of another? > An ad hoc node responsible for another ad hoc node, IMO may mean that > the node gets its routing information from another! (dependent-node). The sentence which you quote is worded incorrectly. Nevertheless, I agree that there may some confusion about what "responsibility" means. I have changed all occurrences of this to instead use language about advertising a network prefix containing the address of a particular node. > > AB>Statements seen after, in section-2, page-5> “other nodes, attached > via participating or non-participating interfaces”. > This was not described well, and not sure if it has relation with the > shared address among routers mentioned later in section-2, page-5. The intention was indeed to describe how AODVv2 routers can use AODVv2 to provide reachability to other neighboring hosts that do not use AODVv2. After reading over the text several times, I determined that the term "participating" does not add anything important to the description. An AODVv2 router may have some neighbors that don't run AODVv2, and it can route packets on behalf of those neighbors. Under some strict conditions, the AODVv2 router can advertise a network prefix which is shorter than the length of a host address. > > AB> does it mean that it only performs discovery when . . . , as if > the router itself cannot be a source of demand. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I added some text to clarify that AODVv2 routers support routing operations for their local processes as well as routing on behalf of their neighboring nodes. > >> During route discovery, the originator’s AODVv2 router initiates >> dissemination of a Route Request (RREQ) throughout the network to >> find a route to a particular destination, via the AODVv2 router >> responsible for this destination. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>not clear> originator; what did this node originate? Do we mean the > router’s responsible for one, and it request for a connection to > destination (as the responsibility is at destination or at source > side. This particular sentence is clearer if the word "originator’s" is simply deleted. But to answer your question, the "originator" is the neighboring node which transmitted a packet to the AODVv2 router, expecting the AODVv2 router to forward the packet along the next hop to the packet's destination. > > AB>suggest adding words> “Route Request message (RREQ)”. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. > >> During this hop-by-hop dissemination process, each intermediate AODVv2 >> router records a route to the originator. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> During the hop-by-hop dissemination process, > each intermediate AODVv2 router receiving the RREQ message records a > route to the originator. > AB> the target also should records a route to the originator.. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. > >> AODVv2 uses sequence numbers to ensure loop freedom [Perkins99]. >> Sequence numbers enable AODVv2 routers to determine the temporal >> order of AODVv2 route discovery messages, thereby avoiding use of >> stale routing information. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> “AODVv2 uses routers’ sequence numbers”. > Or > AB>suggest amendments> “AODVv2 uses routers’ AODVv2 sequence numbers (SeqNum)”. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Isn't that pretty much redundant? It seems to me pretty clear in context. AODVv2 sequence numbers are the only sequence numbers mentioned in the entire document, so there seems to be little chance for confusion. > > #In section (2. Applicability Statement) > >> AODVv2 handles a wide variety of mobility patterns by dynamically >> determining routes on-demand. AODVv2 also handles a wide variety of traffic >> patterns. In networks with a large number of routers, AODVv2 is best suited >> for sparse traffic scenarios where routers forward packets to only a small >> portion of the other AODVv2 routers, due to the on-demand nature of route >> discovery and route maintenance. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>idea not clear> the word “other” confused, one side large and > another side small of MANET network. There was no intention to divide the network into "sides". I have reworded the sentence to eliminate this confusion. > > AB>maybe because> where the large number (portion) of AODVv2 routers > forward packets to other small portion (number) of AODVv2 routers, > > AB>idea not clear> “due to the on-demand nature of route discovery and > route maintenance”, what is the problem with both on-demand(discovery) > or reactive(maintenance) nature? Do both create the different portion > sides of routes? Generally, if each MANET router has to maintain routes that pass through most of the MANET routers in the MANET, then it's better to use proactive. If, on the other hand, a MANET router typically has to maintain routes that only use a smaller percentage of the MANET routers in the network, then reactive is likely to be better. The exact percentage has not to my knowledge been tabulated, but it is known to depend on traffic patterns. If anyone wants to discover the exact numbers and dependences, I would be happy to collaborate. I know how to go about getting the answers. > > AB>discussion> Does the reason of the protocol suitability include > traffic pattern and network density? Even though the paragraph claims > AODVv2 handles them as mentioned. In the paragraph there is no clear > relation between traffic and on-demand nature, even though on-demand > is traffic oriented, so it seems positive to use an on-demand (the > negative is not clear). Also for the route maintenance is related with > route changes, which is positive. See above. As one trivial example, if the network has 1000 nodes, but the entire traffic pattern is that communication is only needed between two of the nodes which happen to be neighbors, then reactive is drastically better than proactive. > > It is preferable to change the paragraph to describe both ideas; what > AODVv2 cannot handle more suitable, with mentioning what it is best > suitable. However, mentioning the reactive nature suitability will > relate/reflect to all MANET Reactive Protocols not just AODVv2. This > can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you can propose some clearer text after reviewing the above comments, that would be appreciated. >> AODVv2 is applicable to memory constrained devices, since little >> routing state is maintained in each AODVv2 router. Only routing >> information related to active sources and destinations is maintained, >> in contrast to most proactive routing protocols that require routing >> information to all routers within the routing region be maintained. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> “information related routes to active sources > and to destinations is maintained”. I used: "routing information related to routes between active sources and destinations" > AB>suggest replace> “proactive routing protocols” with “MANET > Proactive Routing protocols (MPRs)” > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ MPR is an acronym for something much different. I did insert "MANET" into the sentence, but to my understanding "proactive" already requires the indicated behavior. > >> At any time within an AODVv2 routing region, only one AODVv2 router >> SHOULD be responsible for, i.e. "own", any particular address. >> Coordination among multiple AODVv2 routers to distribute routing >> information correctly for a shared address (i.e. an address that is >> advertised and can be reached via multiple AODVv2 routers) is not >> described in this document. The router behavior for shifting >> responsibility for an address from one AODVv2 router to another is >> mentioned in Appendix C. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> At all times within an AODVv2 routing region, > only one AODVv2 router SHOULD be responsible for (i.e. the > routing-address region owner) any particular address. The coordination > among multiple AODVv2 routers to distribute routing information > correctly for a shared address (i.e. an address that is advertised and > can be reached via multiple AODVv2 routers) is not described in this > document. The AODVv2 router operation of shifting > responsibility for an address from one AODVv2 router to another is > mentioned in Appendix C. Done. > > AB>not sure question> Is router behavior responsible for the address > or for the address assignment? Not sure. Address assignment is out of scope for AODVv2. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > AB>RFC2119> “Otherwise, persistent packet loss MAY occur”. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This use of "may" is not one of the RFC 2119 meanings of the word. I changed it to "could". > >> AODVv2 only utilizes bidirectional links. In the case of possible >> unidirectional links, either blacklists (see Section 7.2) or other >> means (e.g. adjacency establishment with only neighboring routers >> that have bidirectional communication as indicated by NHDP >> [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality >> is recommended. Otherwise, persistent packet loss may occur. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>not clear> How does it not utilize unidirectional links, while > mentioned, or who does this blacklisting, is it another protocol? Not > sure why mention in this protocol draft while it is not clear what > operates the blacklisting. This was not clear even in section 7.2. > Usually some routing protocols operate the blacklisting, so does this > mean that any/some AODVv2 router(s) in such situation may use > blacklisting which does not affect the network’s routings. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In AODV, this blacklisting was done using a flag on the RREP and a special RREP_ACK message. When DYMO was started, the working group discussion convinced Ian (at that time, WG document editor) that RREP_ACK was simply not needed. Being in favor of protocol simplification, Ian removed RREP_ACK and created the Message TLV shown in Table 7 to serve the same purpose as the previous RREP flag. I think that this was considered to make DYMO more fully in compliance with RFC 5444. I agree that the blacklisting operation should be described more fully. I may not be able to craft that text before the I-D submission deadline. > >> The routing algorithm in AODVv2 may be operated at layers other than >> the network layer, using layer-appropriate addresses. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> The MANET routing algorithm of AODVv2 MAY be > operated at another layer than the network layer, using the layer’s > appropriate addresses. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I'm not sure what improvement that adds. Can you say a little more about how it is better? Presumably, AODVv2 is specifically a MANET routing protocol, and its algorithms are properly considered as within the jurisdiction of the [manet] WG. > > #In section (3. Terminology) > >> AODVv2 Sequence Number (SeqNum) >> An AODVv2 Sequence Number is maintained by each AODVv2 router >> process. This sequence number is used by other AODVv2 routers to >> identify the temporal order of routing information generated and >> ensure loop-free routes. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> An AODVv2 Sequence Number is maintained by each > AODVv2 router process. The AODVv2 router’s sequence number is used by > other AODVv2 routers to identify the temporal order of routing > information generated and > ensure loop-free routes. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This is related to the above suggestion, and I am still not clear about how the current text might be confusing. > >> Originating Node (OrigNode) >> The originating node is the source, its AODVv2 router creates a >> AODVv2 control message on its behalf in an effort to disseminate >> some routing information. The originating node is also referred >> to as a particular message’s originator. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> The originating node is the data source node. > Its AODVv2 router or responsible AODVv2 router creates a AODVv2 > control message on its behalf in an effort to disseminate some routing > information. The originating node is also referred to as a particular > message’s originator. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I used "the data source node" and reworded the rest of the sentence to be more clear (I hope). > >> This Node (ThisNode) >> ThisNode corresponds to the AODVv2 router process currently >> performing a calculation or attending to a message. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>confused!> the term ThisNode is not indicating to its definition > (which makes the draft reading misunderstanding), maybe > “RouterProcess” is more closer and clear. The word “node” is used in > draft as a router is responsible for, therefore, the node may not > perform route process, so it the term “ThisNode” may confuse while > reading elsewhere. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I think the source of confusion here is that an AODVv2 router may be also called a "node" whenever convenient. So, if part of the specification refers to something about a "node", there is no implication that AODVv2 routers are excluded from that part of the specification (unless that is explicitly stated). If I find a good place to make that clarification, I will put in the appropriate text. >> Type-Length-Value structure (TLV) >> A generic way to represent information, please see [RFC5444] for >> additional information. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>idea not clear> which kind of represent-information, does it only > include routing or discovery information or other? Maybe say “routing > information”. TLVs are used to represent almost any kind of information. There is no restriction that they have to be used only for routing information. > AB> add> the explanation of such types of information as: > A generic way to represent information (add suitable types: routing, > control, monitoring, Adjacency, etc.), I think it would be problematic to attempt any such list, but I will await other peoples' comments. > AB>question> does the AODVv2 use RFC5444 if not, it will confuse. > Refering to 5444 for more information may mean that 5444 is used in > AODVv2 format. Yes, AODVv2 uses RFC 5444. > AB> suggested amendment> A generic way to represent information and as > TLV is defined in RFC5444. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I reworded this and cited RFC 5444 explicitly. > >> Unreachable Node (UnreachableNode) >> An UnreachableNode is a node for which a forwarding route is unknown. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> Unreachable Node (UnreachableNode) > An UnreachableNode is a node for which its forwarding route is unknown. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To me, that doesn't sound right. I'm not sure how to make it better. As it is used elsewhere, the word "its" might even make the definition more ambiguous. > > In addition to using this IP protocol number, AODVv2 may use the UDP > port 269 (manet) [RFC5498] in conjunction with the IP Protocol Number > 17 (UDP). > AB> if it may use the 269 port I think only if it uses 5444. I don’t > see statement that how will AODVv2 use 5444 info-format, and may not. I put in an explicit statement to that effect. > > #In section 4.2.1. Generalized Packet and Message Structure: > >> For interoperability with other AODVv2 routers, all AODVv2 messages >> specified in this document SHOULD sent using the IP protocol number >> (138) reserved for manet protocols [RFC5498]; or the UDP destination >> port (269) reserved for manet protocols [RFC5498] and IP protocol >> number for UDP. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest> delete the “with other”, it seems like they are different > routers, we may replace with “among all”. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The sentence is even better if the entire first clause is deleted. > >> A packet is made up of messages. A message is made up of a >> message header, message TLV block, and zero or more address blocks. >> Each of the address blocks may also have an associated address TLV >> block. > AB> is it an IP packet made up of messages or it is another type of > packets? The packet should be clarified. Maybe it is “5444 packet” or > we have a name for it as MANET-Packet. Are the messages AODV messages > or UDP encapsulating AODV messages? The answer is not clear her > neither in RFC5444 that this document refers to. Messages can be > AODVv2 messages, but what about addresses. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ How about "AODVv2 messages are transmitted in packets that conform" ... to RFC 5444 ? > >> Most AODVv2 messages are sent with the IP destination address set to >> the link-local multicast address LL-MANET-Routers [RFC5498] unless >> otherwise stated. Therefore, all AODVv2 routers SHOULD subscribe to >> LL-MANET-Routers [RFC5498] for receiving control packets. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>not sure> what is control packet, is it routing control? Please amend. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. > > #In section 5.3.3 > >> For each of the additional addresses considered, ThisNode first >> checks the that the address is a multihop-capable unicast address. >> If the address is not a unicast address, the address and all related >information MUST be removed. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>delete and add> delete “the” in “checks the that” > Add “then” before “address and all related”. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. > > # section 6 >> If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only responsible >for its own addresses. > AB> does it have a list of its addresses that are its responsibility, Yes. > and does it have a list of its addresses that are not its > responsibility (i.e. possibility some its addresses is other router > responsibility). No. I'll put in some text to say this explicitly. -- Regards, Charlie P. From jvasseur@cisco.com Sun Oct 21 23:21:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED42321F8B90 for ; Sun, 21 Oct 2012 23:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=-3.916, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_92=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVCjRzOiJjbl for ; Sun, 21 Oct 2012 23:21:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A39B121F8B8F for ; Sun, 21 Oct 2012 23:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88587; q=dns/txt; s=iport; t=1350886881; x=1352096481; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T/Clm6h8tfSv4CeXlB6cNxDZ8cbifywhn/7Ds8e4ASs=; b=AJbcGKDNXJognFdf1oaSD8npeeuJqBareCqBLN9lkvwjEkVG2NrlDdJf jEMwXOM5J+MiJ2nAKdG/hQVbYcZRGwFb8snplgG8YEkqry8IVVnLyMwlG dNBc83+MTEd7QvEcEDAn5EJSLP9h+jBNFyml3sZ4cFZIJ8IWAJJk2mOYC U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHLlhFCtJXG8/2dsb2JhbAA7CsEMgQiCIQEBBAEBAQ8BBwFTBAcQAgEIEhACFAEGBycLFAMOAgQOBQgTB4diC5s8nxUEi18QC4V0YAOSBTqSAIFrgm+BYzU X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208,217";a="130957241" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 22 Oct 2012 06:21:20 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9M6LK9m016858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 06:21:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 01:21:19 -0500 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] Comments For AODVv2 (manet-dymo-22) Thread-Index: AQHNsB1y8lZROWQNakq2a/ZnQdYaQg== Date: Mon, 22 Oct 2012 06:21:18 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772200B48F@xmb-rcd-x02.cisco.com> References: <5084C834.4040206@computer.org> In-Reply-To: <5084C834.4040206@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--48.504900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772200B48Fxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: manet , "ian.chakeres" Subject: Re: [manet] Comments For AODVv2 (manet-dymo-22) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 06:21:26 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772200B48Fxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Charlie, I made a first pass and found the document in GREAT shape, and I do agree w= ith everything you said below. One comment (more later) below: On Oct 22, 2012, at 6:14 AM, Charles E. Perkins wrote: Hello again Abdussalam, Here are some responses to your suggestions from earlier this year. On 5/3/2012 1:15 PM, Abdussalam Baryun wrote: AB>Overall> The dymo-22 draft is well organized and represents the protocol operations, operation location, and messages (when initiating its process, its conditions, and how processed) in section-by-section basis. However, it was difficult to read because I think the concept of version 2 and because the introduction and presentation was not representing the new issues added to the old version and even not seen the DSR-idea use in this version as mentioned.The draft lacks explanations of the relationship between AODV and AODVv2, because both protocols carry the similar name it is preferable to give more details to avoid misunderstanding. The similar name may indicate that both protocols can work together, or that AODVv2 router understands correctly AODV router, or they may be integrated in some network solutions. I have added text to explain that AODVv2 is not interoperable with DSR or with AODV. AB> Suggesting> that section 3 put before section 2 to clarify the definition of some items of the protocol introduction presentation. O.K. I have done this, but there may be reasons why the Terminology should precede the Applicability Statement. Right now I am not aware of any such reasons, though. AB>I read>In the manet discussion Chakeres to Baker (C2B), dated July 26 2010, sub:dymo-21: C2B>The nets do not have to be mobile, and DYMO may be applicable in low po= wer C2B>lossy sensor networks. Without lots of details about a particular netwo= rk C2B>deployment and application traffic, it is very hard to make C2B>generalizations in MANET. AB> suggest> Preferable to be mentioned in overview this discussion explana= tion. AB> suggest> If this protocol is able to be used in LLN nets as well as MANET, it is important to clarify it (LLN was only mentioned in acknowledgement section) and its relation with LLN information exchange requirements, because the protocol applicable to other nodes (e.g. LLN node) including MANET nodes. I'm not sure about this. We can make sure that the protocol is suitable fo= r reactive applications. To precisely delineate the applicability to "low power lossy= sensor networks" make take the development of the protocol specification too far afield. Pe= rhaps it would be better to wait for additional comments before adding that to the Applicability Statement. JP> I cannot agree more; I would really opposed to this; not only there wou= ld be issue with WG charters,and this would re-open the doors to the number of LLNs such protoc= ols do not apply to. AB>thought and questions>The word =93node=94 was used without indicating that it is MANET node, which its node may be a router. In addition, Originating Node (OrigNode) in the terminology is not defined to be a MANET node (e.g. if we compare with AODV RFC3561). So could it be a MANET node or it could not? The intention is to allow nodes that are not AODVv2 routers to originate traffic that will be routed by AODVv2 routers towards the destination. This makes the network architecture used not clear. Are all nodes in this network architecture, MANET nodes? If all messages/packets are MANET-units as RFC5444 therefore, all nodes are MANET. Moreover, the draft has some indirect indications that there MAY be more than one routing protocol (other than AODVv2) per net-interface in some nodes which is preferable to be mentioned. Perhaps there is some terminology problem that needs to be resolved. Right now in the draft there is no occurrence of the term "MANET node". The word "node" is used to include network nodes that are not AODVv2 routers. And, as always, there may be other protocols in use. If there are places in the specification where this introduces ambiguity, please let me know. AB>thought and questions>Is the protocol a specific purpose or general purpose or both, this should be specified. All MANET routing protocols need the purpose statement that specifies clearly its location in practical situation. AODVv2 is "general purpose", but by no means universal. The best ways to use AODVv2 are intended to be described in the Applicability Statement. I = am not sure how to improve the description so that it resolves your comment. AB>thought and questions>The draft has not categorized the network=92s devices/nodes (using only the word routing instead of nodes). The draft does not make explaination of the protocol=92s interaction with ad hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router). I believe the interaction between a general node in the network and the AOD= Vv2 routers which have responsibility for that node is out of scope for AODVv2. As I understand it, the network organization can be almost completely arbit= rary as long as the AODVv2 is explicitly able to discharge its responsibility fo= r offering reachability to the nodes for which it is responsible. AB> The draft had some paragraph that not followed the RFC2119, but some amended as (there may be other, that needs to be amended): +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-10>required> A RteMsg REQUIRES the following information: Fixed. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-25>required> If no UnreachableNode addresses remain in the RERR, no other handling is REQUIRED and the RERR is discarded. Fixed by using simpler rewording for clarity. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-27>required> In table title: =93REQUIRED Administratively Configured Parameters=94 I'm not sure about this. I don't think that all occurrences of "Required" = have to be capitalized. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-27>should> Similarly, AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all their AODVv2 interfaces. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-32>must> Note that if multicast is used, any confidentiality and integrity algorithms used MUST permit multiple receivers to handle the message. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Fixed. #Abstract .... deleted because I already discussed these in an earlier email... #In (Content) 4.2.2. Routing Message (RteMsg) - RREQ and RREP . . . . . . . 10 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> Routing Messages. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The information in this section has been reorganized. #In section (1. Overview) Route discovery is performed when an AODVv2 router receives a packet from a node under its responsibility to a destination for which it does not have a route. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>idea not clear> which kind of node under responsibility of another? An ad hoc node responsible for another ad hoc node, IMO may mean that the node gets its routing information from another! (dependent-node). The sentence which you quote is worded incorrectly. Nevertheless, I agree = that there may some confusion about what "responsibility" means. I have changed all o= ccurrences of this to instead use language about advertising a network prefix containi= ng the address of a particular node. AB>Statements seen after, in section-2, page-5> =93other nodes, attached via participating or non-participating interfaces=94. This was not described well, and not sure if it has relation with the shared address among routers mentioned later in section-2, page-5. The intention was indeed to describe how AODVv2 routers can use AODVv2 to provide reachability to other neighboring hosts that do not use AODVv2. After reading over the text several times, I determined that the term "part= icipating" does not add anything important to the description. An AODVv2 router may have some neighbors that don't run AODVv2, and it can route packets on behalf of those neighbors. Under some strict conditions, the AODVv2 router can advertise a network prefix which is shorter than the length of a host a= ddress. AB> does it mean that it only performs discovery when . . . , as if the router itself cannot be a source of demand. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I added some text to clarify that AODVv2 routers support routing operations= for their local processes as well as routing on behalf of their neighboring nod= es. During route discovery, the originator=92s AODVv2 router initiates dissemination of a Route Request (RREQ) throughout the network to find a route to a particular destination, via the AODVv2 router responsible for this destination. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>not clear> originator; what did this node originate? Do we mean the router=92s responsible for one, and it request for a connection to destination (as the responsibility is at destination or at source side. This particular sentence is clearer if the word "originator=92s" is simply = deleted. But to answer your question, the "originator" is the neighboring node which transmitted a packet to the AODVv2 router, expecting the AODVv2 router to forward the packet along the next hop to the packet's destination. AB>suggest adding words> =93Route Request message (RREQ)=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. During this hop-by-hop dissemination process, each intermediate AODVv2 router records a route to the originator. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> During the hop-by-hop dissemination process, each intermediate AODVv2 router receiving the RREQ message records a route to the originator. AB> the target also should records a route to the originator.. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. AODVv2 uses sequence numbers to ensure loop freedom [Perkins99]. Sequence numbers enable AODVv2 routers to determine the temporal order of AODVv2 route discovery messages, thereby avoiding use of stale routing information. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> =93AODVv2 uses routers=92 sequence numbers=94. Or AB>suggest amendments> =93AODVv2 uses routers=92 AODVv2 sequence numbers (S= eqNum)=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Isn't that pretty much redundant? It seems to me pretty clear in context. AODVv2 sequence numbers are the only sequence numbers mentioned in the entire document, so there seems to be little chance for confusion. #In section (2. Applicability Statement) AODVv2 handles a wide variety of mobility patterns by dynamically determining routes on-demand. AODVv2 also handles a wide variety of traffic patterns. In networks with a large number of routers, AODVv2 is best suited for sparse traffic scenarios where routers forward packets to only a small portion of the other AODVv2 routers, due to the on-demand nature of route discovery and route maintenance. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>idea not clear> the word =93other=94 confused, one side large and another side small of MANET network. There was no intention to divide the network into "sides". I have reworded the sentence to eliminate this confusion. AB>maybe because> where the large number (portion) of AODVv2 routers forward packets to other small portion (number) of AODVv2 routers, AB>idea not clear> =93due to the on-demand nature of route discovery and route maintenance=94, what is the problem with both on-demand(discovery) or reactive(maintenance) nature? Do both create the different portion sides of routes? Generally, if each MANET router has to maintain routes that pass through mo= st of the MANET routers in the MANET, then it's better to use proactive. If, = on the other hand, a MANET router typically has to maintain routes that only use a smaller percentage of the MANET routers in the network, then reactive is li= kely to be better. The exact percentage has not to my knowledge been tabulated, but it is known to depend on traffic patterns. If anyone wants to discover the exact numbers and dependences, I would be happy to collaborate. I know how to go about getting the answers. AB>discussion> Does the reason of the protocol suitability include traffic pattern and network density? Even though the paragraph claims AODVv2 handles them as mentioned. In the paragraph there is no clear relation between traffic and on-demand nature, even though on-demand is traffic oriented, so it seems positive to use an on-demand (the negative is not clear). Also for the route maintenance is related with route changes, which is positive. See above. As one trivial example, if the network has 1000 nodes, but the entire traffic pattern is that communication is only needed between two of the nodes which happen to be neighbors, then reactive is drastically better than proactive. It is preferable to change the paragraph to describe both ideas; what AODVv2 cannot handle more suitable, with mentioning what it is best suitable. However, mentioning the reactive nature suitability will relate/reflect to all MANET Reactive Protocols not just AODVv2. This can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you can propose some clearer text after reviewing the above comments, th= at would be appreciated. AODVv2 is applicable to memory constrained devices, since little routing state is maintained in each AODVv2 router. Only routing information related to active sources and destinations is maintained, in contrast to most proactive routing protocols that require routing information to all routers within the routing region be maintained. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> =93information related routes to active sources and to destinations is maintained=94. I used: "routing information related to routes between active sources and destinations" AB>suggest replace> =93proactive routing protocols=94 with =93MANET Proactive Routing protocols (MPRs)=94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ MPR is an acronym for something much different. I did insert "MANET" into the sentence, but to my understanding "proactive" already requires the indicated behavior. At any time within an AODVv2 routing region, only one AODVv2 router SHOULD be responsible for, i.e. "own", any particular address. Coordination among multiple AODVv2 routers to distribute routing information correctly for a shared address (i.e. an address that is advertised and can be reached via multiple AODVv2 routers) is not described in this document. The router behavior for shifting responsibility for an address from one AODVv2 router to another is mentioned in Appendix C. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> At all times within an AODVv2 routing region, only one AODVv2 router SHOULD be responsible for (i.e. the routing-address region owner) any particular address. The coordination among multiple AODVv2 routers to distribute routing information correctly for a shared address (i.e. an address that is advertised and can be reached via multiple AODVv2 routers) is not described in this document. The AODVv2 router operation of shifting responsibility for an address from one AODVv2 router to another is mentioned in Appendix C. Done. AB>not sure question> Is router behavior responsible for the address or for the address assignment? Not sure. Address assignment is out of scope for AODVv2. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>RFC2119> =93Otherwise, persistent packet loss MAY occur=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This use of "may" is not one of the RFC 2119 meanings of the word. I changed it to "could". AODVv2 only utilizes bidirectional links. In the case of possible unidirectional links, either blacklists (see Section 7.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality is recommended. Otherwise, persistent packet loss may occur. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>not clear> How does it not utilize unidirectional links, while mentioned, or who does this blacklisting, is it another protocol? Not sure why mention in this protocol draft while it is not clear what operates the blacklisting. This was not clear even in section 7.2. Usually some routing protocols operate the blacklisting, so does this mean that any/some AODVv2 router(s) in such situation may use blacklisting which does not affect the network=92s routings. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + In AODV, this blacklisting was done using a flag on the RREP and a special = RREP_ACK message. When DYMO was started, the working group discussion convinced Ian (at that time, WG document editor) that RREP_ACK was simply not needed. Be= ing in favor of protocol simplification, Ian removed RREP_ACK and created the M= essage TLV shown in Table 7 to serve the same purpose as the previous RREP flag. = I think that this was considered to make DYMO more fully in compliance with RFC 544= 4. I agree that the blacklisting operation should be described more fully. I = may not be able to craft that text before the I-D submission deadline. The routing algorithm in AODVv2 may be operated at layers other than the network layer, using layer-appropriate addresses. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + AB>suggest amendments> The MANET routing algorithm of AODVv2 MAY be operated at another layer than the network layer, using the layer=92s appropriate addresses. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + I'm not sure what improvement that adds. Can you say a little more about how it is better? Presumably, AODVv2 is specifically a MANET routing proto= col, and its algorithms are properly considered as within the jurisdiction of th= e [manet] WG. #In section (3. Terminology) AODVv2 Sequence Number (SeqNum) An AODVv2 Sequence Number is maintained by each AODVv2 router process. This sequence number is used by other AODVv2 routers to identify the temporal order of routing information generated and ensure loop-free routes. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> An AODVv2 Sequence Number is maintained by each AODVv2 router process. The AODVv2 router=92s sequence number is used by other AODVv2 routers to identify the temporal order of routing information generated and ensure loop-free routes. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This is related to the above suggestion, and I am still not clear about how the current text might be confusing. Originating Node (OrigNode) The originating node is the source, its AODVv2 router creates a AODVv2 control message on its behalf in an effort to disseminate some routing information. The originating node is also referred to as a particular message=92s originator. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> The originating node is the data source node. Its AODVv2 router or responsible AODVv2 router creates a AODVv2 control message on its behalf in an effort to disseminate some routing information. The originating node is also referred to as a particular message=92s originator. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I used "the data source node" and reworded the rest of the sentence to be more clear (I hope). This Node (ThisNode) ThisNode corresponds to the AODVv2 router process currently performing a calculation or attending to a message. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>confused!> the term ThisNode is not indicating to its definition (which makes the draft reading misunderstanding), maybe =93RouterProcess=94 is more closer and clear. The word =93node=94 is used i= n draft as a router is responsible for, therefore, the node may not perform route process, so it the term =93ThisNode=94 may confuse while reading elsewhere. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I think the source of confusion here is that an AODVv2 router may be also called a "node" whenever convenient. So, if part of the specification refe= rs to something about a "node", there is no implication that AODVv2 routers are excluded from that part of the specification (unless that is explicitly sta= ted). If I find a good place to make that clarification, I will put in the appropriate text. Type-Length-Value structure (TLV) A generic way to represent information, please see [RFC5444] for additional information. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>idea not clear> which kind of represent-information, does it only include routing or discovery information or other? Maybe say =93routing information=94. TLVs are used to represent almost any kind of information. There is no restriction that they have to be used only for routing information. AB> add> the explanation of such types of information as: A generic way to represent information (add suitable types: routing, control, monitoring, Adjacency, etc.), I think it would be problematic to attempt any such list, but I will await other peoples' comments. AB>question> does the AODVv2 use RFC5444 if not, it will confuse. Refering to 5444 for more information may mean that 5444 is used in AODVv2 format. Yes, AODVv2 uses RFC 5444. AB> suggested amendment> A generic way to represent information and as TLV is defined in RFC5444. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I reworded this and cited RFC 5444 explicitly. Unreachable Node (UnreachableNode) An UnreachableNode is a node for which a forwarding route is unknown. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> Unreachable Node (UnreachableNode) An UnreachableNode is a node for which its forwarding route is unknown. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To me, that doesn't sound right. I'm not sure how to make it better. As it is used elsewhere, the word "its" might even make the definition more ambiguous. In addition to using this IP protocol number, AODVv2 may use the UDP port 269 (manet) [RFC5498] in conjunction with the IP Protocol Number 17 (UDP). AB> if it may use the 269 port I think only if it uses 5444. I don=92t see statement that how will AODVv2 use 5444 info-format, and may not. I put in an explicit statement to that effect. #In section 4.2.1. Generalized Packet and Message Structure: For interoperability with other AODVv2 routers, all AODVv2 messages specified in this document SHOULD sent using the IP protocol number (138) reserved for manet protocols [RFC5498]; or the UDP destination port (269) reserved for manet protocols [RFC5498] and IP protocol number for UDP. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest> delete the =93with other=94, it seems like they are different routers, we may replace with =93among all=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The sentence is even better if the entire first clause is deleted. A packet is made up of messages. A message is made up of a message header, message TLV block, and zero or more address blocks. Each of the address blocks may also have an associated address TLV block. AB> is it an IP packet made up of messages or it is another type of packets? The packet should be clarified. Maybe it is =935444 packet=94 or we have a name for it as MANET-Packet. Are the messages AODV messages or UDP encapsulating AODV messages? The answer is not clear her neither in RFC5444 that this document refers to. Messages can be AODVv2 messages, but what about addresses. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ How about "AODVv2 messages are transmitted in packets that conform" ... to RFC 5444 ? Most AODVv2 messages are sent with the IP destination address set to the link-local multicast address LL-MANET-Routers [RFC5498] unless otherwise stated. Therefore, all AODVv2 routers SHOULD subscribe to LL-MANET-Routers [RFC5498] for receiving control packets. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>not sure> what is control packet, is it routing control? Please amend. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. #In section 5.3.3 For each of the additional addresses considered, ThisNode first checks the that the address is a multihop-capable unicast address. If the address is not a unicast address, the address and all related >infor= mation MUST be removed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>delete and add> delete =93the=94 in =93checks the that=94 Add =93then=94 before =93address and all related=94. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. # section 6 If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only responsible >= for its own addresses. AB> does it have a list of its addresses that are its responsibility, Yes. and does it have a list of its addresses that are not its responsibility (i.e. possibility some its addresses is other router responsibility). No. I'll put in some text to say this explicitly. -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772200B48Fxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Charlie,

I made a first pass and found the document in GREAT shape, and I do ag= ree with everything you said
below. One comment (more later) below:

On Oct 22, 2012, at 6:14 AM, Charles E. Perkins wrote:


Hello again Abdussalam,

Here are some responses to your suggestions from earlier this year.

On 5/3/2012 1:15 PM, Abdussalam Baryun wrote:

AB>Overall> The dymo-22 draft is well organ= ized and represents the
protocol operations, operation location, and mess= ages (when initiating
its process, its conditions, and how processed) i= n section-by-section
basis. However, it was difficult to read because = I think the concept
of version 2 and because the introduction and pre= sentation was not
representing the new issues added to the old vers= ion and even not seen
the DSR-idea use in this version as mentioned.The= draft lacks
explanations of the relationship between AODV and= AODVv2, because both
protocols carry the similar name it is preferable= to give more details
to avoid misunderstanding. The similar name may i= ndicate that both
protocols can work together, or that AODVv2 route= r understands
correctly AODV router, or they may be integrated = in some network
solutions.

I have added text to explain that AODVv2 is not interoperable with
DSR or with AODV.


AB> Suggesting>  that section 3 put be= fore section 2 to clarify the
definition of some items of the protocol introduc= tion presentation.

O.K.  I have done this, but there may be reasons why the Terminology s= hould
precede the Applicability Statement.  Right now I am not aware of any = such
reasons, though.

AB>I read>In the manet discussion Chakeres = to Baker (C2B), dated July
26 2010, sub:dymo-21:
C2B>The nets do not have to be mobile, and DYM= O may be applicable in low power
C2B>lossy sensor networks. Without lots of det= ails about a particular network
C2B>deployment and application traffic, it is = very hard to make
C2B>generalizations in MANET.

AB> suggest> Preferable to be mentioned in = overview this discussion explanation.
AB> suggest> If this protocol is able to be= used in LLN nets as well
as MANET, it is important to clarify it (LLN was = only mentioned in
acknowledgement section) and its relation with LL= N information
exchange requirements, because the protocol appli= cable to other nodes
(e.g. LLN node) including MANET nodes.

I'm not sure about this.  We can make sure that the protocol is suitab= le for reactive
applications.  To precisely delineate the applicability to "low p= ower lossy sensor networks"
make take the development of the protocol specification too far afield. &nb= sp;Perhaps it
would be better to wait for additional comments before adding that to the Applicability Statement.

JP> I cannot agree more; I would really opposed to this; not only t= here would be issue with WG 
charters,and this would re-open the doors to the number of LLNs such p= rotocols do not apply to.


AB>thought and questions>The word =93node= =94 was used without indicating
that it is MANET node, which its node may be a ro= uter. In addition,
Originating Node (OrigNode) in the terminology is= not defined to be a
MANET node (e.g. if we compare with AODV RFC3561)= . So could it be a
MANET node or it could not?

The intention is to allow nodes that are not AODVv2 routers to originate traffic that will be routed by AODVv2 routers towards the destination.

This makes the network architecture used
not clear. Are all nodes in this network architec= ture, MANET nodes? If
all messages/packets are MANET-units as RFC5444 t= herefore, all nodes
are MANET. Moreover, the draft has some indirect = indications that
there MAY be more than one routing protocol (othe= r than AODVv2) per
net-interface in some nodes which is preferable t= o be mentioned.

Perhaps there is some terminology problem that needs to be resolved.  = Right
now in the draft there is no occurrence of the term "MANET node".= The word
"node" is used to include network nodes that are not AODVv2 route= rs.  And,
as always, there may be other protocols in use.  If there are places i= n the
specification where this introduces ambiguity, please let me know.


AB>thought and questions>Is the protocol a = specific purpose or general
purpose or both, this should be specified. All MA= NET routing protocols
need the purpose statement that specifies clearly= its location in
practical situation.

AODVv2 is "general purpose", but by no means universal.  The= best ways to
use AODVv2 are intended to be described in the Applicability Statement. &nb= sp;I am
not sure how to improve the description so that it resolves your comment.

AB>thought and questions>The draft has not = categorized the network=92s
devices/nodes (using only the word routing instea= d of nodes). The
draft does not make explaination of the protocol= =92s interaction with ad
hoc hosts (i.e. only ad hoc routers are mentioned= as AODVv2 router).

I believe the interaction between a general node in the network and the AOD= Vv2
routers which have responsibility for that node is out of scope for AODVv2.=
As I understand it, the network organization can be almost completely arbit= rary
as long as the AODVv2 is explicitly able to discharge its responsibility fo= r offering
reachability to the nodes for which it is responsible.

AB> The draft had some paragraph that not foll= owed the RFC2119, but
some amended as (there may be other, that needs t= o be amended):
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++++++++++

AB>page-10>required> A RteMsg REQUIRES t= he following information:

Fixed.

++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++++++++++
AB>page-25>required> If no UnreachableNo= de addresses remain in the
RERR, no other handling is REQUIRED and the RERR = is discarded.

Fixed by using simpler rewording for clarity.

++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++++++++++
AB>page-27>required> In table title: =93= REQUIRED Administratively
Configured Parameters=94

I'm not sure about this.  I don't think that all occurrences of "= Required" have
to be capitalized.

++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++++++++++
AB>page-27>should> Similarly, AODVv2 rou= ters SHOULD subscribe to
LL-MANET-Routers on all their AODVv2 interfaces.<= br>
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++++++++++
AB>page-32>must> Note that if multicast = is used, any confidentiality
and integrity algorithms used MUST permit multipl= e receivers to handle
the message.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++++++++++

Fixed.


#Abstract

....  deleted because I already discussed these in an earlier email...=


#In (Content)

4.2.2. Routing Message (RteMsg) - RREQ and RREP .= . . . . . . 10
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> Routing Messages.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

The information in this section has been reorganized.


#In section (1. Overview)

Route discovery is performed when an AODVv2 route= r receives a packet from a
node under its responsibility to a destination fo= r which it does not have a
route.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>idea not clear> which kind of node under= responsibility of another?
An ad hoc node responsible for another ad hoc nod= e, IMO may mean that
the node gets its routing information from anothe= r! (dependent-node).

The sentence which you quote is worded incorrectly.  Nevertheless, I a= gree that there
may some confusion about what "responsibility" means.  I hav= e changed all occurrences
of this to instead use language about advertising a network prefix containi= ng the
address of a particular node.


AB>Statements seen after, in section-2, page-5= > =93other nodes, attached
via participating or non-participating interfaces= =94.
This was not described well, and not sure if it h= as relation with the
shared address among routers mentioned later in s= ection-2, page-5.

The intention was indeed to describe how AODVv2 routers can use AODVv2 to provide reachability to other neighboring hosts that do not use AODVv2.
After reading over the text several times, I determined that the term "= ;participating"
does not add anything important to the description.  An AODVv2 router = may
have some neighbors that don't run AODVv2, and it can route packets on
behalf of those neighbors.  Under some strict conditions, the AODVv2 r= outer
can advertise a network prefix which is shorter than the length of a host a= ddress.


AB> does it mean that it only performs discove= ry when . . . , as if
the router itself cannot be a source of demand.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

I added some text to clarify that AODVv2 routers support routing operations= for
their local processes as well as routing on behalf of their neighboring nod= es.

During route discovery, the originator=92s AODVv2= router initiates
dissemination of a Route Request (RREQ) throughou= t the network to
find a route to a particular destination, via the= AODVv2 router
responsible for this destination.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>not clear> originator; what did this nod= e originate? Do we mean the
router=92s responsible for one, and it request fo= r a connection to
destination (as the responsibility is at destinat= ion or at source
side.

This particular sentence is clearer if the word "originator=92s" = is simply deleted.
But to answer your question, the "originator" is the neighboring = node which
transmitted a packet to the AODVv2 router, expecting the AODVv2 router to forward the packet along the next hop to the packet's destination.


AB>suggest adding words> =93Route Request m= essage (RREQ)=94.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

Done.


During this hop-by-hop dissemination process, eac= h intermediate AODVv2
router records a route to the originator.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> During the hop-by-ho= p dissemination process,
each intermediate AODVv2 router receiving the RRE= Q message records a
route to the originator.
AB> the target also should records a route to = the originator..
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

Done.


AODVv2 uses sequence numbers to ensure loop freed= om [Perkins99].
Sequence numbers enable AODVv2 routers to determi= ne the temporal
order of AODVv2 route discovery messages, thereby= avoiding use of
stale routing information.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> =93AODVv2 uses route= rs=92 sequence numbers=94.
Or
AB>suggest amendments> =93AODVv2 uses route= rs=92 AODVv2 sequence numbers (SeqNum)=94.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

Isn't that pretty much redundant?  It seems to me pretty clear in cont= ext.
AODVv2 sequence numbers are the only sequence numbers mentioned in
the entire document, so there seems to be little chance for confusion.


#In section (2. Applicability Statement)

AODVv2 handles a wide variety of mobility pattern= s by dynamically
determining routes on-demand. AODVv2 also handles= a wide variety of traffic
patterns. In networks with a large number of rout= ers, AODVv2 is best suited
for sparse traffic scenarios where routers forwar= d packets to only a small
portion of the other AODVv2 routers, due to the o= n-demand nature of route
discovery and route maintenance.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>idea not clear> the word =93other=94 con= fused, one side large and
another side small of MANET network.

There was no intention to divide the network into "sides".  = I have reworded
the sentence to eliminate this confusion.


AB>maybe because> where the large number (p= ortion) of AODVv2 routers
forward packets to other small portion (number) o= f AODVv2 routers,

AB>idea not clear> =93due to the on-demand = nature of route discovery and
route maintenance=94, what is the problem with bo= th on-demand(discovery)
or reactive(maintenance) nature? Do both create t= he different portion
sides of routes?

Generally, if each MANET router has to maintain routes that pass through mo= st
of the MANET routers in the MANET, then it's better to use proactive.  = ;If, on the
other hand, a MANET router typically has to maintain routes that only use a=
smaller percentage of the MANET routers in the network, then reactive is li= kely
to be better.  The exact percentage has not to my knowledge been tabul= ated,
but it is known to depend on traffic patterns.

If anyone wants to discover the exact numbers and dependences,
I would be happy to collaborate.  I know how to go about getting the answers.



AB>discussion> Does the reason of the proto= col suitability include
traffic pattern and network density? Even though = the paragraph claims
AODVv2 handles them as mentioned. In the paragrap= h there is no clear
relation between traffic and on-demand nature, ev= en though on-demand
is traffic oriented, so it seems positive to use = an on-demand (the
negative is not clear). Also for the route mainte= nance is related with
route changes, which is positive.

See above.  As one trivial example, if the network has 1000 nodes, but= the
entire traffic pattern is that communication is only needed between two of<= br> the nodes which happen to be neighbors, then reactive is drastically better=
than proactive.


It is preferable to change the paragraph to descr= ibe both ideas; what
AODVv2 cannot handle more suitable, with mentioni= ng what it is best
suitable. However, mentioning the reactive nature= suitability will
relate/reflect to all MANET Reactive Protocols no= t just AODVv2. This
can be clear if using words like RECOMMENDED and/= or NOT RECOMMENDED.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

If you can propose some clearer text after reviewing the above comments, th= at
would be appreciated.

AODVv2 is applicable to memory constrained device= s, since little
routing state is maintained in each AODVv2 router= . Only routing
information related to active sources and destina= tions is maintained,
in contrast to most proactive routing protocols t= hat require routing
information to all routers within the routing reg= ion be maintained.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> =93information relat= ed routes to active sources
and to destinations is maintained=94.

I used: "routing information related to routes between active sources = and
     destinations"

AB>suggest replace> =93proactive routing pr= otocols=94 with =93MANET
Proactive Routing protocols (MPRs)=94
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

MPR is an acronym for something much different.  I did insert "MA= NET"
into the sentence, but to my understanding "proactive" already re= quires
the indicated behavior.


At any time within an AODVv2 routing region, only= one AODVv2 router
SHOULD be responsible for, i.e. "own", = any particular address.
Coordination among multiple AODVv2 routers to dis= tribute routing
information correctly for a shared address (i.e. = an address that is
advertised and can be reached via multiple AODVv2= routers) is not
described in this document. The router behavior f= or shifting
responsibility for an address from one AODVv2 rou= ter to another is
mentioned in Appendix C.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> At all times within = an AODVv2 routing region,
only one AODVv2 router SHOULD be responsible for = (i.e. the
routing-address region owner) any particular addr= ess. The coordination
among multiple AODVv2 routers to distribute routi= ng information
correctly for a shared address (i.e. an address t= hat is advertised and
can be reached via multiple AODVv2 routers) is no= t described in this
document. The AODVv2 router operation of shifting=
responsibility for an address from one AODVv2 rou= ter to another is
mentioned in Appendix C.

Done.


AB>not sure question> Is router behavior re= sponsible for the address
or for the address assignment? Not sure.

Address assignment is out of scope for AODVv2.

++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

AB>RFC2119> =93Otherwise, persistent packet= loss MAY occur=94.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

This use of "may" is not one of the RFC 2119 meanings of the word= .
I changed it to "could".


AODVv2 only utilizes bidirectional links. In the = case of possible
unidirectional links, either blacklists (see Sect= ion 7.2) or other
means (e.g. adjacency establishment with only nei= ghboring routers
that have bidirectional communication as indicate= d by NHDP
[I-D.ietf-manet-nhdp]) of ensuring and monitoring= bi-directionality
is recommended. Otherwise, persistent packet loss= may occur.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>not clear> How does it not utilize unidi= rectional links, while
mentioned, or who does this blacklisting, is it a= nother protocol? Not
sure why mention in this protocol draft while it = is not clear what
operates the blacklisting. This was not clear eve= n in section 7.2.
Usually some routing protocols operate the blackl= isting, so does this
mean that any/some AODVv2 router(s) in such situa= tion may use
blacklisting which does not affect the network=92= s routings.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++

In AODV, this blacklisting was done using a flag on the RREP and a special = RREP_ACK
message.  When DYMO was started, the working group discussion convince= d Ian
(at that time, WG document editor) that RREP_ACK was simply not needed. &nb= sp;Being
in favor of protocol simplification, Ian removed RREP_ACK and created the M= essage
TLV shown in Table 7 to serve the same purpose as the previous RREP flag. &= nbsp;I think
that this was considered to make DYMO more fully in compliance with RFC 544= 4.

I agree that the blacklisting operation should be described more fully. &nb= sp;I may not
be able to craft that text before the I-D submission deadline.



The routing algorithm in AODVv2 may be operated a= t layers other than
the network layer, using layer-appropriate addres= ses.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++
AB>suggest amendments> The MANET routing al= gorithm of AODVv2 MAY be
operated at another layer than the network layer,= using the layer=92s
appropriate addresses.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++

I'm not sure what improvement that adds.  Can you say a little more ab= out
how it is better?  Presumably, AODVv2 is specifically a MANET routing = protocol,
and its algorithms are properly considered as within the jurisdiction of th= e
[manet] WG.



#In section (3. Terminology)

AODVv2 Sequence Number (SeqNum)
An AODVv2 Sequence Number is maintained by each A= ODVv2 router
process. This sequence number is used by other AO= DVv2 routers to
identify the temporal order of routing informatio= n generated and
ensure loop-free routes.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> An AODVv2 Sequence N= umber is maintained by each
AODVv2 router process. The AODVv2 router=92s sequ= ence number is used by
other AODVv2 routers to identify the temporal ord= er of routing
information generated and
ensure loop-free routes.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

This is related to the above suggestion, and I am still not clear about how=
the current text might be confusing.


Originating Node (OrigNode)
The originating node is the source, its AODVv2 ro= uter creates a
AODVv2 control message on its behalf in an effort= to disseminate
some routing information. The originating node is= also referred
to as a particular message=92s originator.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> The originating node= is the data source node.
Its AODVv2 router or responsible AODVv2 router cr= eates a AODVv2
control message on its behalf in an effort to dis= seminate some routing
information. The originating node is also referre= d to as a particular
message=92s originator.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

I used "the data source node" and reworded the rest of the senten= ce to
be more clear (I hope).


This Node (ThisNode)
ThisNode corresponds to the AODVv2 router process= currently
performing a calculation or attending to a messag= e.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>confused!> the term ThisNode is not indi= cating to its definition
(which makes the draft reading misunderstanding),= maybe
=93RouterProcess=94 is more closer and clear. The= word =93node=94 is used in
draft as a router is responsible for, therefore, = the node may not
perform route process, so it the term =93ThisNode= =94 may confuse while
reading elsewhere.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

I think the source of confusion here is that an AODVv2 router may be also called a "node" whenever convenient.  So, if part of the spe= cification refers to
something about a "node", there is no implication that AODVv2 rou= ters are
excluded from that part of the specification (unless that is explicitly sta= ted).

If I find a good place to make that clarification, I will put in the
appropriate text.

Type-Length-Value structure (TLV)
A generic way to represent information, please se= e [RFC5444] for
additional information.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>idea not clear> which kind of represent-= information, does it only
include routing or discovery information or other= ? Maybe say =93routing
information=94.

TLVs are used to represent almost any kind of information.  There is n= o
restriction that they have to be used only for routing information.

AB> add> the explanation of such types of i= nformation as:
A generic way to represent information (add suita= ble types: routing,
control, monitoring, Adjacency, etc.),

I think it would be problematic to attempt any such list, but I will await<= br> other peoples' comments.

AB>question> does the AODVv2 use RFC5444 if= not, it will confuse.
Refering to 5444 for more information may mean th= at 5444 is used in
AODVv2 format.

Yes, AODVv2 uses RFC 5444.

AB> suggested amendment> A generic way to r= epresent information and as
TLV is defined in RFC5444.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

I reworded this and cited RFC 5444 explicitly.


Unreachable Node (UnreachableNode)
An UnreachableNode is a node for which a forwardi= ng route is unknown.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest amendments> Unreachable Node (Un= reachableNode)
An UnreachableNode is a node for which its forwar= ding route is unknown.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

To me, that doesn't sound right.  I'm not sure how to make it better.<= br> As it is used elsewhere, the word "its" might even make the defin= ition
more ambiguous.


In addition to using this IP protocol number, AOD= Vv2 may use the UDP
port 269 (manet) [RFC5498] in conjunction with th= e IP Protocol Number
17 (UDP).
AB> if it may use the 269 port I think only if= it uses 5444. I don=92t
see statement that how will AODVv2 use 5444 info-= format, and may not.

I put in an explicit statement to that effect.


#In section 4.2.1. Generalized Packet and Message= Structure:

For interoperability with other AODVv2 routers, a= ll AODVv2 messages
specified in this document SHOULD sent using the = IP protocol number
(138) reserved for manet protocols [RFC5498]; or = the UDP destination
port (269) reserved for manet protocols [RFC5498]= and IP protocol
number for UDP.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>suggest> delete the =93with other=94, it= seems like they are different
routers, we may replace with =93among all=94.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++

The sentence is even better if the entire first clause is deleted.


A packet is made up of messages. A message is mad= e up of a
message header, message TLV block, and zero or mo= re address blocks.
Each of the address blocks may also have an assoc= iated address TLV
block.
AB> is it an IP packet made up of messages or = it is another type of
packets? The packet should be clarified. Maybe it= is =935444 packet=94 or
we have a name for it as MANET-Packet. Are the me= ssages AODV messages
or UDP encapsulating AODV messages? The answer is= not clear her
neither in RFC5444 that this document refers to. = Messages can be
AODVv2 messages, but what about addresses.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++

How about "AODVv2 messages are transmitted in packets that conform&quo= t; ...
to RFC 5444  ?


Most AODVv2 messages are sent with the IP destina= tion address set to
the link-local multicast address LL-MANET-Routers= [RFC5498] unless
otherwise stated. Therefore, all AODVv2 routers S= HOULD subscribe to
LL-MANET-Routers [RFC5498] for receiving control = packets.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++
AB>not sure> what is control packet, is it = routing control? Please amend.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++

Done.


#In section 5.3.3

For each of the additional addresses considered, = ThisNode first
checks the that the address is a multihop-capable= unicast address.
If the address is not a unicast address, the addr= ess and all related >information MUST be removed.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++
AB>delete and add> delete =93the=94 in =93c= hecks the that=94
Add =93then=94 before =93address and all related= =94.
++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++

Done.


# section 6
If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 ro= uter is only responsible >for its own addresses.
AB> does it have a list of its addresses that = are its responsibility,

Yes.

and does it have a list of its addresses that are= not its
responsibility (i.e. possibility some its address= es is other router
responsibility).

No.

I'll put in some text to say this explicitly.

--
Regards,
Charlie P.

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

--_000_03B78081B371D44390ED6E7BADBB4A772200B48Fxmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Mon Oct 22 04:38:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53B21F8BBA for ; Mon, 22 Oct 2012 04:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-3.246, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_92=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49V0bGR3jzm3 for ; Mon, 22 Oct 2012 04:38:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7803721F8BA9 for ; Mon, 22 Oct 2012 04:38:21 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3107843vcb.31 for ; Mon, 22 Oct 2012 04:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0OpHqVbKsoqHopBEnmvEukSTO6sMZx+CUBB42A/YRZU=; b=CvOkwVjZUUqs1Jzkws1c9jd4a8oyzBerQYHGjiBiyGOguVMWdGESmx06HzB9DgyY1C tOcDDD5hsV6lMEsGYoJCzeeNKE4t7mjV2xGMld3ycqnzObKyFE/CssL+EtkgyeaWY5tA /vpc3n6SljVD4wsFpxBakY3412zudn9bFk5u37iJsQlnBvUfyBWL+8BCzouwAhbCQ4yS CHutneqp3dueWP7wD23rqzDsayeTXuY5NOsvSP0NapHku3TMaRnRHyqesYr670dtA2JQ qp/S8HC1snn+YpYrr5vjj0qT6E1gJEhJxVDmwDWHeAAmhpPTgs6hFALEGkzRCJU+7ui3 5tug== MIME-Version: 1.0 Received: by 10.220.154.68 with SMTP id n4mr14526872vcw.22.1350905900903; Mon, 22 Oct 2012 04:38:20 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 22 Oct 2012 04:38:20 -0700 (PDT) In-Reply-To: <5084C834.4040206@computer.org> References: <5084C834.4040206@computer.org> Date: Mon, 22 Oct 2012 13:38:20 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ian.chakeres" , manet Subject: Re: [manet] Comments For AODVv2 (manet-dymo-22) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:38:23 -0000 Thanks Charlie, I look forward to review the new WG draft, All the best, Abdussalam Baryun University of Glamorgan, UK On 10/22/12, Charles E. Perkins wrote: > > Hello again Abdussalam, > > Here are some responses to your suggestions from earlier this year. > > On 5/3/2012 1:15 PM, Abdussalam Baryun wrote: >> >> AB>Overall> The dymo-22 draft is well organized and represents the >> protocol operations, operation location, and messages (when initiating >> its process, its conditions, and how processed) in section-by-section >> basis. However, it was difficult to read because I think the concept >> of version 2 and because the introduction and presentation was not >> representing the new issues added to the old version and even not seen >> the DSR-idea use in this version as mentioned.The draft lacks >> explanations of the relationship between AODV and AODVv2, because both >> protocols carry the similar name it is preferable to give more details >> to avoid misunderstanding. The similar name may indicate that both >> protocols can work together, or that AODVv2 router understands >> correctly AODV router, or they may be integrated in some network >> solutions. > > I have added text to explain that AODVv2 is not interoperable with > DSR or with AODV. > >> >> AB> Suggesting> that section 3 put before section 2 to clarify the >> definition of some items of the protocol introduction presentation. > > O.K. I have done this, but there may be reasons why the Terminology shou= ld > precede the Applicability Statement. Right now I am not aware of any suc= h > reasons, though. > >> AB>I read>In the manet discussion Chakeres to Baker (C2B), dated July >> 26 2010, sub:dymo-21: >> C2B>The nets do not have to be mobile, and DYMO may be applicable in low >> power >> C2B>lossy sensor networks. Without lots of details about a particular >> network >> C2B>deployment and application traffic, it is very hard to make >> C2B>generalizations in MANET. >> >> AB> suggest> Preferable to be mentioned in overview this discussion >> explanation. >> AB> suggest> If this protocol is able to be used in LLN nets as well >> as MANET, it is important to clarify it (LLN was only mentioned in >> acknowledgement section) and its relation with LLN information >> exchange requirements, because the protocol applicable to other nodes >> (e.g. LLN node) including MANET nodes. > > I'm not sure about this. We can make sure that the protocol is suitable > for reactive > applications. To precisely delineate the applicability to "low power > lossy sensor networks" > make take the development of the protocol specification too far afield. > Perhaps it > would be better to wait for additional comments before adding that to the > Applicability Statement. > >> AB>thought and questions>The word =93node=94 was used without indicating >> that it is MANET node, which its node may be a router. In addition, >> Originating Node (OrigNode) in the terminology is not defined to be a >> MANET node (e.g. if we compare with AODV RFC3561). So could it be a >> MANET node or it could not? > > The intention is to allow nodes that are not AODVv2 routers to originate > traffic that will be routed by AODVv2 routers towards the destination. > >> This makes the network architecture used >> not clear. Are all nodes in this network architecture, MANET nodes? If >> all messages/packets are MANET-units as RFC5444 therefore, all nodes >> are MANET. Moreover, the draft has some indirect indications that >> there MAY be more than one routing protocol (other than AODVv2) per >> net-interface in some nodes which is preferable to be mentioned. > > Perhaps there is some terminology problem that needs to be resolved. Rig= ht > now in the draft there is no occurrence of the term "MANET node". The wor= d > "node" is used to include network nodes that are not AODVv2 routers. And= , > as always, there may be other protocols in use. If there are places in t= he > specification where this introduces ambiguity, please let me know. > >> >> AB>thought and questions>Is the protocol a specific purpose or general >> purpose or both, this should be specified. All MANET routing protocols >> need the purpose statement that specifies clearly its location in >> practical situation. > > AODVv2 is "general purpose", but by no means universal. The best ways to > use AODVv2 are intended to be described in the Applicability Statement. > I am > not sure how to improve the description so that it resolves your comment. > >> >> AB>thought and questions>The draft has not categorized the network=92s >> devices/nodes (using only the word routing instead of nodes). The >> draft does not make explaination of the protocol=92s interaction with ad >> hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router). > > I believe the interaction between a general node in the network and the > AODVv2 > routers which have responsibility for that node is out of scope for AODVv= 2. > As I understand it, the network organization can be almost completely > arbitrary > as long as the AODVv2 is explicitly able to discharge its responsibility > for offering > reachability to the nodes for which it is responsible. >> >> AB> The draft had some paragraph that not followed the RFC2119, but >> some amended as (there may be other, that needs to be amended): >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> AB>page-10>required> A RteMsg REQUIRES the following information: > > Fixed. > >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>page-25>required> If no UnreachableNode addresses remain in the >> RERR, no other handling is REQUIRED and the RERR is discarded. > > Fixed by using simpler rewording for clarity. > >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>page-27>required> In table title: =93REQUIRED Administratively >> Configured Parameters=94 > > I'm not sure about this. I don't think that all occurrences of > "Required" have > to be capitalized. > >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>page-27>should> Similarly, AODVv2 routers SHOULD subscribe to >> LL-MANET-Routers on all their AODVv2 interfaces. >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>page-32>must> Note that if multicast is used, any confidentiality >> and integrity algorithms used MUST permit multiple receivers to handle >> the message. >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Fixed. > >> >> #Abstract > > .... deleted because I already discussed these in an earlier email... > >> >> #In (Content) >> >>> 4.2.2. Routing Message (RteMsg) - RREQ and RREP . . . . . . . 10 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> Routing Messages. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > The information in this section has been reorganized. > >> >> #In section (1. Overview) >> >>> Route discovery is performed when an AODVv2 router receives a packet fr= om >>> a >>> node under its responsibility to a destination for which it does not ha= ve >>> a >>> route. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>idea not clear> which kind of node under responsibility of another? >> An ad hoc node responsible for another ad hoc node, IMO may mean that >> the node gets its routing information from another! (dependent-node). > > The sentence which you quote is worded incorrectly. Nevertheless, I > agree that there > may some confusion about what "responsibility" means. I have changed > all occurrences > of this to instead use language about advertising a network prefix > containing the > address of a particular node. > >> >> AB>Statements seen after, in section-2, page-5> =93other nodes, attached >> via participating or non-participating interfaces=94. >> This was not described well, and not sure if it has relation with the >> shared address among routers mentioned later in section-2, page-5. > > The intention was indeed to describe how AODVv2 routers can use AODVv2 to > provide reachability to other neighboring hosts that do not use AODVv2. > After reading over the text several times, I determined that the term > "participating" > does not add anything important to the description. An AODVv2 router may > have some neighbors that don't run AODVv2, and it can route packets on > behalf of those neighbors. Under some strict conditions, the AODVv2 rout= er > can advertise a network prefix which is shorter than the length of a > host address. > >> >> AB> does it mean that it only performs discovery when . . . , as if >> the router itself cannot be a source of demand. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > I added some text to clarify that AODVv2 routers support routing > operations for > their local processes as well as routing on behalf of their neighboring > nodes. >> >>> During route discovery, the originator=92s AODVv2 router initiates >>> dissemination of a Route Request (RREQ) throughout the network to >>> find a route to a particular destination, via the AODVv2 router >>> responsible for this destination. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>not clear> originator; what did this node originate? Do we mean the >> router=92s responsible for one, and it request for a connection to >> destination (as the responsibility is at destination or at source >> side. > > This particular sentence is clearer if the word "originator=92s" is simpl= y > deleted. > But to answer your question, the "originator" is the neighboring node whi= ch > transmitted a packet to the AODVv2 router, expecting the AODVv2 router to > forward the packet along the next hop to the packet's destination. > >> >> AB>suggest adding words> =93Route Request message (RREQ)=94. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Done. > >> >>> During this hop-by-hop dissemination process, each intermediate AODVv2 >>> router records a route to the originator. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> During the hop-by-hop dissemination process, >> each intermediate AODVv2 router receiving the RREQ message records a >> route to the originator. >> AB> the target also should records a route to the originator.. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Done. > >> >>> AODVv2 uses sequence numbers to ensure loop freedom [Perkins99]. >>> Sequence numbers enable AODVv2 routers to determine the temporal >>> order of AODVv2 route discovery messages, thereby avoiding use of >>> stale routing information. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> =93AODVv2 uses routers=92 sequence numbers=94. >> Or >> AB>suggest amendments> =93AODVv2 uses routers=92 AODVv2 sequence numbers >> (SeqNum)=94. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Isn't that pretty much redundant? It seems to me pretty clear in context= . > AODVv2 sequence numbers are the only sequence numbers mentioned in > the entire document, so there seems to be little chance for confusion. > >> >> #In section (2. Applicability Statement) >> >>> AODVv2 handles a wide variety of mobility patterns by dynamically >>> determining routes on-demand. AODVv2 also handles a wide variety of >>> traffic >>> patterns. In networks with a large number of routers, AODVv2 is best >>> suited >>> for sparse traffic scenarios where routers forward packets to only a >>> small >>> portion of the other AODVv2 routers, due to the on-demand nature of >>> route >>> discovery and route maintenance. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>idea not clear> the word =93other=94 confused, one side large and >> another side small of MANET network. > > There was no intention to divide the network into "sides". I have reword= ed > the sentence to eliminate this confusion. > >> >> AB>maybe because> where the large number (portion) of AODVv2 routers >> forward packets to other small portion (number) of AODVv2 routers, >> >> AB>idea not clear> =93due to the on-demand nature of route discovery and >> route maintenance=94, what is the problem with both on-demand(discovery) >> or reactive(maintenance) nature? Do both create the different portion >> sides of routes? > > Generally, if each MANET router has to maintain routes that pass through > most > of the MANET routers in the MANET, then it's better to use proactive. > If, on the > other hand, a MANET router typically has to maintain routes that only use= a > smaller percentage of the MANET routers in the network, then reactive is > likely > to be better. The exact percentage has not to my knowledge been tabulate= d, > but it is known to depend on traffic patterns. > > If anyone wants to discover the exact numbers and dependences, > I would be happy to collaborate. I know how to go about getting the > answers. > > >> >> AB>discussion> Does the reason of the protocol suitability include >> traffic pattern and network density? Even though the paragraph claims >> AODVv2 handles them as mentioned. In the paragraph there is no clear >> relation between traffic and on-demand nature, even though on-demand >> is traffic oriented, so it seems positive to use an on-demand (the >> negative is not clear). Also for the route maintenance is related with >> route changes, which is positive. > > See above. As one trivial example, if the network has 1000 nodes, but th= e > entire traffic pattern is that communication is only needed between two o= f > the nodes which happen to be neighbors, then reactive is drastically bett= er > than proactive. > >> >> It is preferable to change the paragraph to describe both ideas; what >> AODVv2 cannot handle more suitable, with mentioning what it is best >> suitable. However, mentioning the reactive nature suitability will >> relate/reflect to all MANET Reactive Protocols not just AODVv2. This >> can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > If you can propose some clearer text after reviewing the above comments, > that > would be appreciated. > >>> AODVv2 is applicable to memory constrained devices, since little >>> routing state is maintained in each AODVv2 router. Only routing >>> information related to active sources and destinations is maintained, >>> in contrast to most proactive routing protocols that require routing >>> information to all routers within the routing region be maintained. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> =93information related routes to active sources >> and to destinations is maintained=94. > > I used: "routing information related to routes between active sources and > destinations" > >> AB>suggest replace> =93proactive routing protocols=94 with =93MANET >> Proactive Routing protocols (MPRs)=94 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > MPR is an acronym for something much different. I did insert "MANET" > into the sentence, but to my understanding "proactive" already requires > the indicated behavior. > >> >>> At any time within an AODVv2 routing region, only one AODVv2 router >>> SHOULD be responsible for, i.e. "own", any particular address. >>> Coordination among multiple AODVv2 routers to distribute routing >>> information correctly for a shared address (i.e. an address that is >>> advertised and can be reached via multiple AODVv2 routers) is not >>> described in this document. The router behavior for shifting >>> responsibility for an address from one AODVv2 router to another is >>> mentioned in Appendix C. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> At all times within an AODVv2 routing region, >> only one AODVv2 router SHOULD be responsible for (i.e. the >> routing-address region owner) any particular address. The coordination >> among multiple AODVv2 routers to distribute routing information >> correctly for a shared address (i.e. an address that is advertised and >> can be reached via multiple AODVv2 routers) is not described in this >> document. The AODVv2 router operation of shifting >> responsibility for an address from one AODVv2 router to another is >> mentioned in Appendix C. > > Done. > >> >> AB>not sure question> Is router behavior responsible for the address >> or for the address assignment? Not sure. > > Address assignment is out of scope for AODVv2. > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> AB>RFC2119> =93Otherwise, persistent packet loss MAY occur=94. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > This use of "may" is not one of the RFC 2119 meanings of the word. > I changed it to "could". > >> >>> AODVv2 only utilizes bidirectional links. In the case of possible >>> unidirectional links, either blacklists (see Section 7.2) or other >>> means (e.g. adjacency establishment with only neighboring routers >>> that have bidirectional communication as indicated by NHDP >>> [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality >>> is recommended. Otherwise, persistent packet loss may occur. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>not clear> How does it not utilize unidirectional links, while >> mentioned, or who does this blacklisting, is it another protocol? Not >> sure why mention in this protocol draft while it is not clear what >> operates the blacklisting. This was not clear even in section 7.2. >> Usually some routing protocols operate the blacklisting, so does this >> mean that any/some AODVv2 router(s) in such situation may use >> blacklisting which does not affect the network=92s routings. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++ > > In AODV, this blacklisting was done using a flag on the RREP and a > special RREP_ACK > message. When DYMO was started, the working group discussion convinced I= an > (at that time, WG document editor) that RREP_ACK was simply not needed. > Being > in favor of protocol simplification, Ian removed RREP_ACK and created > the Message > TLV shown in Table 7 to serve the same purpose as the previous RREP > flag. I think > that this was considered to make DYMO more fully in compliance with RFC > 5444. > > I agree that the blacklisting operation should be described more fully. > I may not > be able to craft that text before the I-D submission deadline. > > >> >>> The routing algorithm in AODVv2 may be operated at layers other than >>> the network layer, using layer-appropriate addresses. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++ >> AB>suggest amendments> The MANET routing algorithm of AODVv2 MAY be >> operated at another layer than the network layer, using the layer=92s >> appropriate addresses. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++ > > I'm not sure what improvement that adds. Can you say a little more about > how it is better? Presumably, AODVv2 is specifically a MANET routing > protocol, > and its algorithms are properly considered as within the jurisdiction of > the > [manet] WG. > > >> >> #In section (3. Terminology) >> >>> AODVv2 Sequence Number (SeqNum) >>> An AODVv2 Sequence Number is maintained by each AODVv2 router >>> process. This sequence number is used by other AODVv2 routers to >>> identify the temporal order of routing information generated and >>> ensure loop-free routes. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> An AODVv2 Sequence Number is maintained by each >> AODVv2 router process. The AODVv2 router=92s sequence number is used by >> other AODVv2 routers to identify the temporal order of routing >> information generated and >> ensure loop-free routes. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > This is related to the above suggestion, and I am still not clear about h= ow > the current text might be confusing. > >> >>> Originating Node (OrigNode) >>> The originating node is the source, its AODVv2 router creates a >>> AODVv2 control message on its behalf in an effort to disseminate >>> some routing information. The originating node is also referred >>> to as a particular message=92s originator. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> The originating node is the data source node. >> Its AODVv2 router or responsible AODVv2 router creates a AODVv2 >> control message on its behalf in an effort to disseminate some routing >> information. The originating node is also referred to as a particular >> message=92s originator. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > I used "the data source node" and reworded the rest of the sentence to > be more clear (I hope). > >> >>> This Node (ThisNode) >>> ThisNode corresponds to the AODVv2 router process currently >>> performing a calculation or attending to a message. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>confused!> the term ThisNode is not indicating to its definition >> (which makes the draft reading misunderstanding), maybe >> =93RouterProcess=94 is more closer and clear. The word =93node=94 is use= d in >> draft as a router is responsible for, therefore, the node may not >> perform route process, so it the term =93ThisNode=94 may confuse while >> reading elsewhere. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > I think the source of confusion here is that an AODVv2 router may be also > called a "node" whenever convenient. So, if part of the specification > refers to > something about a "node", there is no implication that AODVv2 routers are > excluded from that part of the specification (unless that is explicitly > stated). > > If I find a good place to make that clarification, I will put in the > appropriate text. > >>> Type-Length-Value structure (TLV) >>> A generic way to represent information, please see [RFC5444] for >>> additional information. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>idea not clear> which kind of represent-information, does it only >> include routing or discovery information or other? Maybe say =93routing >> information=94. > > TLVs are used to represent almost any kind of information. There is no > restriction that they have to be used only for routing information. > >> AB> add> the explanation of such types of information as: >> A generic way to represent information (add suitable types: routing, >> control, monitoring, Adjacency, etc.), > > I think it would be problematic to attempt any such list, but I will awai= t > other peoples' comments. > >> AB>question> does the AODVv2 use RFC5444 if not, it will confuse. >> Refering to 5444 for more information may mean that 5444 is used in >> AODVv2 format. > > Yes, AODVv2 uses RFC 5444. > >> AB> suggested amendment> A generic way to represent information and as >> TLV is defined in RFC5444. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > I reworded this and cited RFC 5444 explicitly. > >> >>> Unreachable Node (UnreachableNode) >>> An UnreachableNode is a node for which a forwarding route is unknown. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> Unreachable Node (UnreachableNode) >> An UnreachableNode is a node for which its forwarding route is unknown. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > To me, that doesn't sound right. I'm not sure how to make it better. > As it is used elsewhere, the word "its" might even make the definition > more ambiguous. > >> >> In addition to using this IP protocol number, AODVv2 may use the UDP >> port 269 (manet) [RFC5498] in conjunction with the IP Protocol Number >> 17 (UDP). >> AB> if it may use the 269 port I think only if it uses 5444. I don=92t >> see statement that how will AODVv2 use 5444 info-format, and may not. > > I put in an explicit statement to that effect. > >> >> #In section 4.2.1. Generalized Packet and Message Structure: >> >>> For interoperability with other AODVv2 routers, all AODVv2 messages >>> specified in this document SHOULD sent using the IP protocol number >>> (138) reserved for manet protocols [RFC5498]; or the UDP destination >>> port (269) reserved for manet protocols [RFC5498] and IP protocol >>> number for UDP. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest> delete the =93with other=94, it seems like they are differen= t >> routers, we may replace with =93among all=94. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > The sentence is even better if the entire first clause is deleted. > >> >>> A packet is made up of messages. A message is made up of a >>> message header, message TLV block, and zero or more address blocks. >>> Each of the address blocks may also have an associated address TLV >>> block. >> AB> is it an IP packet made up of messages or it is another type of >> packets? The packet should be clarified. Maybe it is =935444 packet=94 o= r >> we have a name for it as MANET-Packet. Are the messages AODV messages >> or UDP encapsulating AODV messages? The answer is not clear her >> neither in RFC5444 that this document refers to. Messages can be >> AODVv2 messages, but what about addresses. >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > How about "AODVv2 messages are transmitted in packets that conform" ... > to RFC 5444 ? > >> >>> Most AODVv2 messages are sent with the IP destination address set to >>> the link-local multicast address LL-MANET-Routers [RFC5498] unless >>> otherwise stated. Therefore, all AODVv2 routers SHOULD subscribe to >>> LL-MANET-Routers [RFC5498] for receiving control packets. >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>not sure> what is control packet, is it routing control? Please amend= . >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Done. > >> >> #In section 5.3.3 >> >>> For each of the additional addresses considered, ThisNode first >>> checks the that the address is a multihop-capable unicast address. >>> If the address is not a unicast address, the address and all related >>> >information MUST be removed. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>delete and add> delete =93the=94 in =93checks the that=94 >> Add =93then=94 before =93address and all related=94. >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Done. > >> >> # section 6 >>> If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only responsib= le >>> >for its own addresses. >> AB> does it have a list of its addresses that are its responsibility, > > Yes. > >> and does it have a list of its addresses that are not its >> responsibility (i.e. possibility some its addresses is other router >> responsibility). > > No. > > I'll put in some text to say this explicitly. > > -- > Regards, > Charlie P. > > From charliep@computer.org Mon Oct 22 08:18:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB9521F8C11 for ; Mon, 22 Oct 2012 08:18:01 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVZQXtnrMxXC for ; Mon, 22 Oct 2012 08:17:58 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4F21F8A10 for ; Mon, 22 Oct 2012 08:17:57 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TQJlN-0005Q1-69; Mon, 22 Oct 2012 11:17:57 -0400 Message-ID: <508563A2.7090006@computer.org> Date: Mon, 22 Oct 2012 08:17:54 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ulrich Herberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86baf721db5ce6c228bf321c064224ac18350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet@ietf.org Subject: [manet] Re: DYMO review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:18:01 -0000 Hello Ulrich, Your comments are really in depth and much appreciated. If I don't get to all of them before the submission deadline, I will do so very soon afterwards. On 7/28/2010 2:28 PM, Ulrich Herberg wrote: > Hi, > > First, I'd like to apologize that until now I never had the time to > review DYMO in detail. Here is my review of the -21 draft. > > Overall comments: > - The draft is very hard/complicated to read; I would have a hard time > implementing it. I hope that the new organization for the draft will help. I have also tried to simplify some of the terminology. > - The protocol seems to be difficult to secure for end-to-end messages. I will look for more specifics, but I don't think it's any more difficult than AODV was. > - I have doubts about the correct usage of RFC5444 in the draft This needs to be fixed ASAP. > > > > Detailed comments: (starting with "UH> ", always immediately following > the concerned sentence or paragraph) > ============ > > > > 2. Applicability Statement > > The DYMO routing protocol is designed for stub or disconnected mobile > > UH> ================ > UH> What is a "disconnected MANET"? Disconnected from what? Are these > UH> terms (stub / disconnected) defined anywhere? > UH> ================ How about: "stub (i.e., non-transit) or disconnected (i.e., from the Internet)" > > ... > routing state is maintained in each DYMO router. Only routing > information related to active sources and destinations is maintained, > in contrast to most proactive routing protocols that require routing > information to all routers within the routing region be maintained. > > UH> ================ > UH> Is "routing region" for the context of a MANET defined somewhere? > UH> ================ No, and it is tricky to define. But I know one when I see it. More seriously, if you have a good definition, or replacement term, I'd be happy to clarify this. > > DYMO supports routers with multiple interfaces participating in the > MANET. DYMO routers can also perform routing on behalf of other > nodes, attached via participating or non-participating interfaces. > > UH> ================ > UH> 1) The document mixes up node / router. Is there a difference? I > UH> would prefer to talk about routers only. Non-routing nodes are allowed to communicate with the assistance of AODVv2 routers. I will try to make this clearer and avoid mix-ups. > UH> 2) What is a participating vs. non-participating interface? Is > UH> that defined somewhere? > UH> ================ I have changed this, since I don't think the terminology helps at all. > > DYMO routers perform route discovery to find a route to a particular > destination. Therefore, DYMO routers MUST be configured to initiate > and respond to route discovery on behalf of certain nodes, identified > by address. > > UH> ================ > UH> A router may have several interfaces, each of which may have > UH> several IP(v6) addresses. Which is the address that identifies a > UH> router? (that applies at many places within the draft) > UH> ================ If I see anyplace in the draft where this causes a problem in the protocol, I'll try to fix it. Right now I don't know of any problem, though... > > When DYMO is the only protocol interacting with the > forwarding table, DYMO MAY be configured to perform route discovery > for all unknown unicast destinations. > > At any time within a DYMO routing region only one DYMO router SHOULD > be responsible for, i.e. "own", a particular address. > > UH> ================ > UH> Which address is that? Of the interface? Or is it a prefix that > UH> this router may delegate to attached hosts? What does it mean, to > UH> "own" an address? (any citation to an RFC?) > UH> ================ The meaning is that, for any particular node that neighbors an AODVv2 router such that the router is responsible for routing packets to/from that node, only one such router is configured for that purpose. > > Coordination > among multiple DYMO routers to distribute routing information > correctly for a shared address (i.e. an address that is advertised > and can be reached via multiple DYMO routers) is not described in > this document. The router behavior for shifting responsibility for > an address from one DYMO router to another are described in > Appendix A. > > UH> ================ > UH> This whole previous section is unclear. Not sure it belongs in the spec > UH> ================ Actually, I am agreeable to delete this paragraph, and Appendix A. However, it is a valuable feature to enable non-AODVv2 nodes to rely on particular AODVv2 routers for their connectivity in a MANET. > > DYMO MUST only utilizes bidirectional links. In the case of possible > unidirectional links, either blacklists ( see Section 7.2) or other > means (e.g. adjacency establishment with only neighboring routers > that have bidirectional communication as indicated by NHDP > [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality > SHOULD be used. Otherwise, persistent packet loss may occur. > > UH> ================ > UH> Not clear how NHDP interoperates with DYMO (in particular using > UH> several DYMO processes on the same router) > UH> ================ If NHDP establishes neighborhood information, then AODVv2 could presumably make use of that information as needed. I don't remember why one would need several AODVv2 processes on the same router, but if that happens, then presumably they would be configured to operate over separate network interfaces. Does that cause any conflict with the way NHDP operates over several interfaces? > > > The routing algorithm in DYMO may be operated at layers other than > the network layer, using layer-appropriate addresses. For operation > at other layers DYMO's routing algorithm likely will not need to > change. Although, modification of the packet/message format may be > required. > > UH> ================ > UH> I did not understand this previous section. It seems that > UH> the whole draft is based on IP/UDP only. > UH> ================ Well, if you change to a new layer and packet header, then you presumably aren't using the same IP protocol or UDP port. To my understanding, AODVv2 is really just specified for IP and UDP. > 3. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > Chakeres & Perkins Expires January 27, 2011 [Page 5] > > Internet-Draft DYMO July 2010 > > > Additionally, this document uses some terminology from [RFC5444]. > > UH> ================ > UH> Which terminology of RFC5444 is used? "some" is imprecise. > UH> ================ At some point after tomorrow I can try to make this more precise. > > This document defines the following terminology: > > Adjacency > A relationship between selected bi-directional neighboring routers > for the purpose of exchanging routing information. Not every pair > of neighboring routers become adjacent. Neighboring routers may > form an adjacency based several different pieces of information or > protocols; for example, exchange of DYMO routing messages, other > protocols (e.g. NDP [RFC4861] or NHDP [I-D.ietf-manet-nhdp]), or > manual configuration. Similarly, loss of a routing adjacency may > also be based upon several pieces of information, and monitoring > of adjacencies where packets are being forwarded is required (see > Section 5.5.1). > > UH> ================ > UH> This is only used in section 5.5.1. Seems to be unnecessary to > UH> define it for the whole document. > UH> ================ Point noted. > > Distance (Dist) > A metric of the distance a message or piece of information has > traversed. The minimum value of distance is the number of IP hops > traversed. The maximum value is 65,535. > > UH> ================ > UH> What metrics is the distance based on? Only Hop count? Can that > UH> be more than 255 (in IP networks)? > UH> ================ No, the hop count shouldn't be more than 255. > > DYMO Identifier (DID) > A DID is maintained for each DYMO routing process (ThisNode.DID), > and the default value is zero (0). Each routing message is tagged > with its associated DID (MsgTLV.DID), unless zero (0). Upon > receipt of DYMO protocol message a DYMO routing protocol process > SHOULD only attend to messages with a matching DID value. > > UH> ================ > UH> Using DID is unclear to me. How does a router process know which > UH> DID it runs? Often, in the spec. it is unclear whether the "DYMO > UH> router" or the "DYMO routing process" does something (see later in my > UH> comments for examples). How do the different routing processes > UH> interact? If NHDP is used, is there a single NHDP instance per process > UH> or per router? > UH> ================ I think this matter of DID was an attempt to get a unique identifier for an AODVv2 router even if the router had several network interfaces and IP addresses. I am hoping that it is O.K. for me to have deleted the DID parts of the specification. I will put them back if needed. > > DYMO Sequence Number (SeqNum) > A DYMO Sequence Number is maintained by each DYMO router process. > This sequence number is used by other DYMO routers to identify the > temporal order of routing information generated and ensure loop- > free routes. > > UH> ================ > UH> Sometimes confusing whether the seqnum is used per router or per > UH> router process. That's not consistent in the spec. > UH> ================ Maybe it would be better to just have one AODVv2 process per AODVv2 router. If, in the future, it is required to support virtual routers we could go back and re-think the matter of which data can be shared between virtual router processes. > > Forwarding Route > A route that is used to forward data packets. Forwarding routes > are generally maintained in a forwarding information base (FIB) or > the kernel forwarding/routing table. > > Multihop-capable Unicast IP Address > A multihop-capable unicast IP address is a unicast IP address that > when put into the IP.SourceAddress or IP.DestinationAddress field > is scoped sufficiently to be forwarded by a router. For example, > site-scoped or globally-scoped unicast IP addresses. > > UH> ================ > UH> Site-scoped is deprecated. Unclear previous section. Is that term > UH> defined in some other RFC? IP.SourceAddress and > UH> IP.DestinationAddress have not been defined until this > UH> point in the spec (comes only later) > UH> ================ Circular definitions are nasty, agreed. I am in favor of eliminating the "multihop-capable" terminology anyway, since I'm not sure why it would be different in meaning than a "routable address", at least within the context of AODVv2. > Originating Node (OrigNode) > The originating node is the source, its DYMO router creates a DYMO > control message on its behalf in an effort to disseminate some > routing information. The originating node is also referred to as > a particular message's originator. > > UH> ================ > UH> What is the difference to ThisNode? > UH> ================ ThisNode is the node handling a message, perhaps soon to retransmit the message. OrigNode is the node which "originated" the message. > > Route Error (RERR) > A RERR message is used to indicate that a DYMO router does not > have a forwarding route to one or more particular addresses. > > Route Reply (RREP) > A RREP message is used to disseminate routing information about > the RREP OrigNode to the RREP TargetNode and the DYMO routers > between them. > > UH> ================ > UH> TargetNode not yet defined > UH> ================ I changed the order, but now it's not alphabetical ( :-( ). > > Route Request (RREQ) > A RREQ message is issued to discover a valid route to a particular > destination address, called the RREQ TargetNode. When a DYMO > router processes a RREQ, it learns routing information on how to > reach the RREQ OrigNode. > > Target Node (TargetNode) > The TargetNode is the ultimate destination of a message. > > This Node (ThisNode) > ThisNode corresponds to the DYMO router process currently > performing a calculation or attending to a message. > > Type-Length-Value structure (TLV) > A generic way to represent information, please see [RFC5444] for > additional information. > > Unreachable Node (UnreachableNode) > An UnreachableNode is a node for which a forwarding route does not > exist. > > > 4. Data Structures > > 4.1. Route Table Entry > > The route table entry is a conceptual data structure. > Implementations may use any internal representation that conforms to > the semantics of a route as specified in this document. > > Conceptually, a route table entry has the following fields: > > > > > > Chakeres & Perkins Expires January 27, 2011 [Page 7] > > Internet-Draft DYMO July 2010 > > > Route.Address > The (host or network) destination address of the node(s) > associated with the routing table entry. > > UH> ================ > UH> Interface address? Originator address? Including prefix notation > UH> or just the address(es)? > UH> ================ This is supposed to be like a generic route table entry. So it is an IP address of the destination. That's often not the next hop, or the outgoing interface. > > > Route.Prefix > Indicates that the associated address is a network address, rather > than a host address. The value is the length of the netmask/ > prefix. > > UH> ================ > UH> So what is the value for a host entry? (32 or 128)? > UH> ================ Yes. > > Route.SeqNum > The DYMO SeqNum associated with this routing information. > > Route.NextHopAddress > The IP address of the adjacent DYMO router on the path toward the > Route.Address. > > Route.NextHopInterface > The interface used to send packets toward the Route.Address. > > Route.Forwarding > A flag indicating whether this Route can be used for forwarding > data packets. This flag MAY be provided for management and > monitoring. > > UH> ================ > UH> Purpose of the Forwarding flag is unclear > UH> ================ I eliminated it, because it's practically the opposite of Route.Broken except in case some administrative agent intervened to temporarily disable a forwarding entry. In an ad hoc network that seems very unlikely, and I don't remember any discussion in the working group to motivate such an administrative feature. > > Route.Broken > A flag indicating whether this Route is broken. This flag is set > to true if the next-hop becomes unreachable or in response to > attending to a RERR (see Section 5.5.4). > > The following field is optional: > > Route.Dist > A dimensionless metric indicating the distance traversed before > reaching the Route.Address node. > > Not including optional information may cause performance degradation, > but it will not cause the protocol to operate incorrectly. > > UH> ================ > UH> Having optional fields sounds dangerous in a database. > UH> ================ I need to study this matter much more closely. I think it will be better to have all mandatory fields but with default values. Plus, AODVv2 needs to be enabled to use other route metrics, now that the specification exists for that. > > > In addition to a route table data structure, each route table entry > may have several timers associated with the information. These > timers/timeouts are discussed in Section 5.2.3. > > 4.2. DYMO Messages > > When describing DYMO protocol messages, it is necessary to refer to > fields in several distinct parts of the overall packet. These > locations include the IP header, the UDP header, and fields from > [RFC5444]. > > UH> ================ > UH> Until now, no mentioning whether the protocol runs on UDP/IP > UH> (which version of IP? The spec never says that it both supports IPv4 > UH> and IPv6 (or I haven't seen it)). Is DYMO limited to run on IP? > UH> ================ AODVv2 as specified in the current document is limited to run on IP (or UDP). There is text in the current draft specifying that both address families are supported. > > This document uses the following notation conventions. > > > > Chakeres & Perkins Expires January 27, 2011 [Page 8] > > Internet-Draft DYMO July 2010 > > > Information found in the table. > > +---------------------------+-------------------+ > | Information Location | Notational Prefix | > +---------------------------+-------------------+ > | IP header | IP. | > | UDP header | UDP. | > | RFC5444 message header | MsgHdr. | > | RFC5444 message TLV | MsgTLV. | > | RFC5444 address blocks | AddBlk. | > | RFC5444 address block TLV | AddTLV. | > +---------------------------+-------------------+ > > Table 1 > > UH> ================ > UH> This table and the hierarchical notation which is used in the > UH> following section is unclear > UH> ================ I'll look for more guidance about how to make it clearer, and also see if I can think of a way to improve the presentation. Right now I do not have a good idea about it, but I am really open to suggestion. > > 4.2.1. Generalized Packet and Message Structure > > DYMO messages conform to the generalized packet and message format as > described in [RFC5444]. Here is a brief description of the format. > A packet is made up of messages. > UH> ================ > UH> Imprecise (and no a scientific language style, "made up of > UH> messages"). Rather something like "A packet formatted according to > UH> RFC5444 contains zero or more messages" > UH> ================ Thanks, I used that text. > > A message is made up of a message > header, message TLV block, and zero or more address blocks. > UH> ================ > UH> Same comment as the previous one > UH> ================ Also fixed. > > Each of > the address blocks may also have an associated address TLV block. > > For interoperability with other DYMO routers, all DYMO messages > specified in this document SHOULD sent using the IP protocol number > (138) reserved for manet protocols [RFC5498]; or the UDP destination > port (269) reserved for manet protocols [RFC5498] and IP protocol > number for UDP. > > UH> ================ > UH> I would not include the protocol/port numbers here. Citation is enough. > UH> ================ I left the numbers there for now. Isn't there some value in having the numbers handy? I don't think there is much downside to doing so. > > Most DYMO messages are sent with the IP destination address set to > the link-local multicast address LL-MANET-Routers [RFC5498] unless > otherwise stated. Therefore, all DYMO routers SHOULD subscribe to > LL-MANET-Routers [RFC5498] for receiving control packets. Note that > multicast packets MAY be sent via unicast. For example, this may > occur for certain link-types (non broadcast mediums), improved > robustness, or manually configured router adjacencies. > > Unicast DYMO messages (e.g. RREP) unless otherwise specified in this > document are sent with the IP destination set to the > Route.NextHopAddress of the route to the TargetNode. > > UH> ================ > UH> How would a router send a unicast RREQ? It would need to know at > UH> least one IP address per adjacent neighbor. This assumption is never > UH> specified. > UH> ================ I think the intention is to use multicast in the typical case, but still to allow the use of unicast for cases when an AODVv2 router does happen to have additional information enabling that use case. I reckon you are aware of some use cases for this; there were some papers published out of UC Santa Cruz about it years back. > > The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO > messages is set to 255. If a packet is received with a value other > than 255, it is discarded. This mechanism helps to ensures that > packets have not passed through any intermediate routers > > UH> ================ > UH> 1) That sounds wrong (mixing RFC5444 packet and IP datagram in the > UH> first sentence). The (RFC5444) packet does not contain an IPv4 > UH> TTL/IPv6 Hop Limit. > UH> 2) You cannot discard a (RFC5444) packet (maybe "ignore it"). It > UH> may contain messages intended for other processes (like NHDP/OLSRv2). > UH> ================ I changed the specification so that any such message is ignored by AODVv2. Thanks for catching this! > ... > The aggregation of multiple messages into a packet is not specified > in this document, but if aggregation does occur the IP.SourceAddress > and IP.DestinationAddress of all contained messages MUST be the same. > > UH> ================ > UH> I don't understand. The contained messages do not have any IP > UH> header fields. Also, isn't the IP.SourceAddress always the originator > UH> address of the router or one IP address of the interface the packet is > UH> sent from? (unclear from the spec) > UH> ================ IP.SourceAddress should always be the address in the IP header. > > Implementations MAY choose to temporarily delay transmission of > messages for the purpose of aggregation (into a single packet) or to > improve performance by using jitter [RFC5148]. > > UH> ================ > UH> Unclear how jitter is applied in the whole spec. > UH> ================ Doesn't RFC 5148 specify that? > > DYMO control packets SHOULD be given priority queuing and channel > access. > > UH> ================ > UH> Does that apply to "packet" as in RFC5444 or in IP datagram? > UH> ================ Here, it means IP datagram. I tried to make this clearer. > > 4.2.2. Routing Messages (RM) - RREQ & RREP > > Routing Messages (RMs) are used to disseminate routing information. > There are two DYMO message types that are considered to be routing > messages (RMs): RREQ and RREP. They contain very similar information > and function, but have slightly different handling rules. The main > difference between the two messages is that RREQ messages generally > solicit a RREP, whereas a RREP is the response to RREQ. > > RM creation and handling are described in Section 5.3. > > A RM requires the following information: > > IP.SourceAddress > The IP address of the node currently sending this packet. > UH> ================ > UH> Which IP address? > UH> ================ Are you asking about what happens if an AODVv2 router has several IP addresses? > > This > field is generally filled automatically by the operating system > and should not require special handling. > > IP.DestinationAddress > The IP address of the packet destination. For multicast RREQ the > IP.DestinationAddress is set to LL-MANET-Routers [RFC5498]. For > unicast RREP the IP.DestinationAddress is set to the > NextHopAddress toward the RREP TargetNode. > > IP.ProtocolNumber and UDP.DestinationPort > The IP Protocol Number 138 (manet) has been reserved for MANET > protocols [RFC5498]. In addition to using this IP protocol > number, DYMO may use the UDP port 269 (manet) [RFC5498] in > conjunction with the IP Protocol Number 17 (UDP). > > > UH> ================ > UH> Mentioning IP fields here seems to be mixing up RFC5444-layer and IP-layer > UH> ================ The hope is that even when using RFC 5444, the IP address fields will retain their usefulness. Are you suggesting that the IP header field information should be replicated as RFC 5444 fields? > > MsgHdr.HopLimit > The remaining number of hops this message is allowed to traverse. > > UH> ================ > UH> What about the other msg headers? MUST/SHOULD/MAY they be contained? > UH> ================ If an AODVv2 message has exhausted its hop limit, then it should be removed from the packet. > > > > Chakeres & Perkins Expires January 27, 2011 [Page 10] > > Internet-Draft DYMO July 2010 > > > AddBlk.TargetNode.Address > UH> ================ > UH> This hierarchical notation has never been defined. > UH> ================ It was supposed to be somewhat intuitive. I'll formulate a way to fix this problem. > > The IP address of the message TargetNode. In a RREQ the > TargetNode is the destination address for which route discovery is > being performed. In a RREP the TargetNode is the RREQ OrigNode > address. The TargetNode address is the first address in a routing > message. > > UH> ================ > UH> The first address? So my (imaginary) routing protocol extension > UH> cannot add addresses at will (at any position), as it is possible in > UH> RFC5444? I would associate a TLV with it to guarantee extensibility of > UH> the protocol. > UH> What if there are several address blocks? First address if the > UH> first address block? > UH> ================ This is the way DYMO did initially make the design. In order to realize the full functionality you suggest, I believe a new type of address block will have to be allocated, that otherwise has the same features as the existing address block. > > AddBlk.OrigNode.Address > The IP address of the originator and its associated prefix length. > In a RREQ the OrigNode is the source's address and prefix. > UH> ================ > UH> Unclear.. prefix or address seems to be mixed here and throughout the spec > UH> ================ Will try to make that clear. > > > In a > RREP the OrigNode is the RREQ TargetNode's address and prefix for > which a RREP is being generated. This address is the second > address in the message for RREQ. > > OrigNode.AddTLV.SeqNum > The DYMO sequence number of the originator's DYMO router. > UH> ================ > UH> DYMO router or router process? > UH> ================ This is the same confusion as you have noted previously. > > A RM may optionally include the following information: > > TargetNode.AddTLV.SeqNum > The last known DYMO sequence number of the TargetNode. > > TargetNode.AddTLV.Dist > The last known Distance to the TargetNode. > > AddBlk.AdditionalNode.Address > The IP address of an additional node that can be reached via the > DYMO router adding this information. Each AdditionalNode.Address > MUST include its prefix. Each AdditionalNode.Address MUST also > have an associated Node.SeqNum in the address TLV block. > UH> ================ > UH> Never defined before what an AdditionalNode is. Which address is that? > UH> ================ An AdditionalNode is a node other than the first node address as you discussed earlier. Functionality for AdditionalNode insertion has been moved into the section for Optional Features of AODVv2. > > AdditionalNode.AddTLV.SeqNum > The DYMO sequence number associated with this routing information. > > OrigNode.AddTLV.Dist > A metric of the distance to reach the associated OrigNode.Address. > This field is incremented by at least one at each intermediate > DYMO router. > > AdditionalNode.AddTLV.Dist > A metric of the distance to reach the associated > AdditionalNode.Address. This field is incremented by at least one > at each intermediate DYMO router. > > Example IPv4 RREQ > UH> ================ > UH> I don't know which fields are mandatory, which are optional. The > UH> example could be moved into the appendix. > UH> ================ When I inherited the document, these examples were commented out. I need to proofread them according to whatever has been changed in the meantime. Anyway, the optional fields and the mandatory fields must be clearly specified. ... > 4.2.3. Route Error (RERR) > > A RERR message is used to disseminate the information that a route is > not available for one or more particular addresses. > UH> ================ > UH> Unclear sentence. For which addresses? > UH> ================ I have added text for this. > > RERR creation and handling are described in Section 5.5. > > A RERR requires the following information: > > IP.SourceAddress > The IP address of the DYMO router that sent this packet. > UH> ================ > UH> Which address? Interface address (if so, which address if several > UH> iface addresses are used?) > UH> ================ Unless I am missing something, this would be the IP address of the sender. > > This > field is generally filled automatically by the operating system > and should not require special handling. > > IP.DestinationAddress > For multicast RERR messages, The IP address is set to LL-MANET- > Routers [RFC5498]. For unicast RERR messages, the IP address is > set to the NextHopAddress. > > IP.ProtocolNumber and UDP.DestinationPort > The IP Protocol Number 138 (manet) has been reserved for MANET > protocols [RFC5498]. In addition to using this IP protocol > number, DYMO may use the UDP port 269 (manet) [RFC5498] in > conjunction with the IP Protocol Number 17 (UDP). > > MsgHdr.HopLimit > The remaining number of hops this message is allowed to traverse. > > AddBlk.UnreachableNode.Address > The address of an UnreachableNode and its associated prefix > length. > UH> ================ > UH> Which address? Originator? > UH> ================ This is supposed to be the IP address of the destination that's no longer reachable. I have clarified that in several places. > ... > 5. Detailed Operation > > 5.1. DYMO Sequence Numbers > UH> ================ > UH> This whole section is unclear. Why start with the sequence > numbers? There is no motivation why sequence numbers are important in > the beginning of the section. > UH> ================ > > DYMO sequence numbers allow DYMO routers to judge the freshness of > routing information and ensure loop freedom. Well, one has to start somewhere, and sequence number operation was really the main innovation of AODV compared to previous distance-vector routing approaches (well, that plus on-demand operation). I'd be very happy to get suggestions for improvement though. Where would be a better place to put this? > > 5.1.1. Maintaining A Node's Own Sequence Number > > DYMO requires that each DYMO router in the network maintain its own > DYMO sequence number (OwnSeqNum) on behalf of the addresses for which > it is responsible. > > UH> ================ > UH> Sequence number per router or router process? The "on behalf of > UH> the addresses" part is unclear. > UH> ================ It seems pointless to discuss the "other addresses" here, so I deleted that phrase. > > OwnSeqNum a 16-bit unsigned integer. The > circumstances for ThisNode to increment its OwnSeqNum are described > in Section 5.3. > > 5.1.2. Numerical Operations on OwnSeqNum > > When ThisNode increments its OwnSeqNum it MUST do so by treating the > sequence number value as an unsigned number. > UH> ================ > UH> This sentence is redundant with the second sentence of section 5.1.1 > UH> ================ Good point. I have deleted the redundant sentence. Part of my purpose is to get rid of redundancy, since it really does make the specification more difficult to read, and way more tedious. > > 5.1.3. OwnSeqNum Rollover > > Incrementing an OwnSeqNum whose value is the largest largest possible > number representable as a 16-bit unsigned integer (i.e., 65,535), > SHOULD be set to one (1). In other words, the sequence number after > 65,535 is 1. > > 5.1.4. Actions After OwnSeqNum Loss > > A DYMO router SHOULD maintain its sequence number in persistent > storage. > > If a DYMO router's OwnSeqNum is lost > UH> ================ > UH> How can a sequence number be lost? > UH> ================ Power fail, basically. > > > , it MUST take certain actions to > avoid creating routing loops. To prevent this possibility after > OwnSeqNum loss a DYMO router MUST wait for at least > ROUTE_DELETE_TIMEOUT before fully participating > UH> ================ > UH> What does that mean, "fully participate"? What is the opposite then? > UH> ================ I got rid of that terminology also. > > in the DYMO routing > protocol. If a DYMO control message is received during this waiting > period, the DYMO router SHOULD handle it normally > UH> ================ > UH> What does "handle it normally" mean? > UH> ================ It means to update relevant route table entries. > 5.2. DYMO Routing Table Operations > > 5.2.1. Judging Routing Information's Usefulness > > Given a route table entry (Route.SeqNum, Route.Dist, and > Route.Broken) and new incoming routing information for a particular > node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/ > RREP), the quality of the new routing information is evaluated to > determine its usefulness. Incoming routing information is classified > as follows: > > 1. Stale > If Node.SeqNum - Route.SeqNum < 0 (using signed 16-bit arithmetic) > the incoming information is stale. Using stale routing > information is not allowed, since doing so might result in routing > loops. > > (Node.SeqNum - Route.SeqNum < 0) > using signed 16-bit arithmetic > > UH> ================ > UH> "using signed 16-bit arithmetic" is unclear. Better cite RFC or > UH> explain wrap-around of sequence numbers. > UH> ================ I have reformulated this. But do you really think it's unclear? Most computer programming courses teach about signed arithmetic, don't they? > > 2. Loop-possible > If Node.SeqNum == Route.SeqNum the incoming information may cause > loops if used; in this case additional information MUST be > examined. If Route.Dist or Node.Dist is unknown or zero (0), then > the routing information is loop-possible. If Node.Dist > > Route.Dist + 1, then the routing information is loop-possible. > Using loop-possible routing information is not allowed, otherwise > routing loops may be formed. > > (Node.SeqNum == Route.SeqNum) AND > ((Node.Dist is unknown) OR > (Route.Dist is unknown) OR > (Node.Dist > Route.Dist + 1)) > UH> ================ > UH> What is this pseudocode for? Unclear when and where to use it. > UH> ================ > > 3. Inferior or equivalent > In case of known equal SeqNum, the information is inferior in > multiple cases: > UH> ================ > UH> That sentence sounds strange: "inferior/superior information". How > UH> can information (=data with semantics) be inferior? > UH> ================ I agree that the language used sounds unnatural. I have made many changes to this section that I hope will resolve this problem. > 4. Superior > Incoming routing information that does not match any of the above > criteria is loop-free and better than the information existing in > the routing table. Information is always superior if Node.SeqNum > - Route.SeqNum > 0 (using signed 16-bit arithmetic). In the case > of equal sequence numbers, the information is superior in multiple > cases: (case i) if Node.Dist < Route.Dist; (case ii) if Node.Dist > == Route.Dist + 1 AND Route.Broken == true (a broken route is > being repaired); (case iii) if Node.Dist == Route.Dist AND it is a > RREP (RREP with equal distance are forwarded) OR Route.Broken == > true (a broken route is being repaired). For completeness, we > provide the following (optimized) pseudo-code. > UH> ================ > UH> Why "optimized" pseudo-code? What is optimized? > UH> ================ I eliminated that. It certainly was not clear. > If a previous value of the TargetNode.SeqNum is known (from a routing > table entry using longest-prefix matching), it SHOULD be placed in > TargetNode.AddTLV.SeqNum in all but the last RREQ attempt. If a > TargetNode.SeqNum is not included, it is assumed to be unknown by > handling nodes. This operation ensures that no intermediate DYMO > routers reply, and ensures that the TargetNode's DYMO router > increments its sequence number. > > Next, the node adds > UH> ================ > UH> Which node? "the"... > UH> ================ > > AddBlk.OrigNode.Address, its prefix, and the > OrigNode.AddTLV.SeqNum (OwnSeqNum) to the RM. > > The OrigNode.Address is the address of the source for which this DYMO > router is initiating this route discovery. The OrigNode.Address MUST > be a unicast address. This information will be used by nodes to > create a route toward the OrigNode, enabling delivery of a RREP, and > eventually used for proper forwarding of data packets. > > If OrigNode.Dist is included it is set to a number greater than zero > (0). > > UH> ================ > UH> Which exact value does the router put into that field? > UH> ================ This might be used when OrigNode is more than one hop away from the AODVv2 router (ThisNode) creating the RREQ. It might be considered an optional feature. > > The IP.DestinationAddress for multicast RREQ is set to LL-MANET- > Routers. For links that do not support multicast or situations in > which unicast messaging is preferred, the IP.DestinationAddress for > unicast RREQ is set to the NextHopAddress. > UH> ================ > UH> Where does the router (or router process?) get the NextHopAddress > UH> from in an initial RREQ? From NHDP? > UH> ================ Here, the idea for unicast RREQ is that ThisNode has some information available to it that would enable unicast to be used beneficially. > 5.3.2. RREP Creation > > First, the AddBlk.TargetNode.Address is added to the RREP. The > TargetNode is the ultimate destination of this RREP; the RREQ > OrigNode.Address. > > Next, AddBlk.OrigNode.Address and prefix are added to the RREP. The > AddBlk.OrigNode.Address is the RREQ TargetNode.Address. The > AddBlk.OrigNode.Address MUST be a unicast IP address. ThisNode > SHOULD advertise the largest known prefix containing > AddBlk.OrigNode.Address. > UH> ================ > UH> "advertise" where? > UH> ================ I think "advertise" simply means "include". ... > > 5.3.3. Intermediate DYMO Router RREP Creation > > Sometimes a DYMO router other than the TargetNode's DYMO router (call > it an "intermediate DYMO router") has routing information that can > satisfy an incoming RREQ. An intermediate DYMO router can issue a > intermediate DYMO router RREP on behalf of the TargetNode's DYMO > router. > UH> ================ > UH> That makes any end-to-end security of control messages tricky. > UH> ================ This feature was pulled out of AODVv2 previous to IETF 83. However, your point is well taken. It would appropriate to specify that when end-to-end security is required, an intermediate node is not allowed respond unless it can satisfy the security requirement. > 5.3.4. RM Handling > UH> ================ > UH> This whole section 5.3.4. is extremely long and complicate to > UH> read. I suggest to better structure in a pseudo-code manner: > UH> e.g. 1) If BLA then > UH> doFoo > UH> 2) otherwise.... > UH> ================ Thanks for this suggestion. If I don't get to work on this before the draft submission deadline tomorrow, I will do it soon afterwards. > For each address (except the TargetNode) in the RM that includes > AddTLV.Dist information, the AddTLV.Dist information MAY be > incremented. If the resulting Distance value for the OrigNode is > greater than 65,535, the message is discarded. If the resulting > Distance value for another node is greater than 65,535, the > associated address and its information are removed from the RM. The > updated Distance value will influence judgment of the routing > information (Section 5.2.1). > UH> ================ > UH> Can the distance be > 255? > UH> ================ As far as I know, the distance cannot be more than 255. In fact, in practice I doubt it could be more than 100. > > > After handling the OrigNode's routing information, then each address > that is not the TargetNode MAY be considered for creating and > updating routes. Creating and updating routes to other nodes can > > > > Chakeres & Perkins Expires January 27, 2011 [Page 22] > > Internet-Draft DYMO July 2010 > > > eliminate RREQ for those IP destinations, in the event that data > needs to be forwarded to the IP destination(s) now or in the near > future. > > For each of the additional addresses considered, ThisNode first > checks the that the address is a multihop-capable unicast address. > If the address is not a unicast address, the address and all related > information MUST be removed. > UH> ================ > UH> Makes end-to-end security impossible > UH> ================ Well, not necessarily, but it does make the design a little more challenging. > For added addresses (and their prefixes) not controlled by this DYMO > router, Route.Dist can be included if known. If Route.Dist is not > known, it MUST NOT be included. > > The VALIDITY_TIME of routing information for appended address(es) > MUST be included, to inform routers about when to delete this > information. The VALIDITY_TIME TLV is defined in Section 7.3. > UH> ================ > UH> What is the default value of VALIDITY_TIME? > UH> ================ It is listed as 1, but I think that is way too short. > To reduce congestion in a network, repeated attempts at route > discovery for a particular TargetNode SHOULD utilize an exponential > backoff. > UH> ================ > UH> Is there any jitter involved? The exp. backoff is not exactly > UH> specified, just explained with an example. > UH> ================ I specified binary exponential backoff, which is pretty well understood so that additional specification isn't needed. I removed the example since as far as I can tell it does not really add to one's understanding. > If a route discovery attempt has failed (i.e. an attempt or multiple > attempts have been made without receiving a RREP) to find a route to > the TargetNode, any data packets buffered for the corresponding > TargetNode are dropped and a Destination Unreachable ICMP message > SHOULD be delivered to the source. > UH> ================ > UH> What parameters are set in the ICMP message (e.g. which code?) On > UH> which interface(s) is the ICMP sent? > UH> ================ The code is 1 (Host unreachable error). The ICMP is sent over the interface from which the source sent the packet to the AODVv2 router. Thanks for catching this! > > 5.5. Route Maintenance > > A RERR SHOULD be issued if a data packet is to be forwarded and it > cannot be delivered to the next-hop because no forwarding route for > the IP.DestinationAddress exists; RERR generation is described in > Section 5.5.3. > UH> ================ > UH> Which assumptions are made of the underlying L2? (ACKs, timeout, NUD, etc.) > UH> ================ Do you mean to ask how it is that the forwarding AODVv2 router can determine whether or not the packet was forwarded to the next hop? > > Upon this condition, an ICMP Destination Unreachable message SHOULD > NOT be generated unless this router is responsible for the > IP.DestinationAddress and that IP.DestinationAddress is known to be > unreachable. > UH> ================ > UH> Is that known terminology "a router is responsible for an address?" > UH> ================ Well, the terminology is supposed to be well defined somewhere in the draft. > 5.7. Unknown Message & TLV Types > > If a message with an unknown type is received, the message is > discarded. > UH> ================ > UH> I think it should be ignored, not discarded. It may be an > UH> NHDP/OLSRv2 messages for example. > UH> ================ I have made this change -- thanks. > > For handling of messages that contain unknown TLV types, the default > behavior is to leave the information in control messages unmodified. > Although, this behavior (UNKNOWN_TYPES) MAY be administratively > controlled. > > 5.8. Advertising Network Addresses > UH> ================ > UH> I don't understand this section. Of course, any hosts attached to > UH> the router (on it's non-MANET interface) are unaware of the routing > UH> protocol. That's true for any routing protocol, it does not run on the > UH> hosts. > UH> ================ > > DYMO routers specify the prefix length for each advertised address. > Any nodes (other than the advertising DYMO router) within the > advertised prefix MUST NOT participate in the DYMO protocol directly. > For example, advertising 192.0.2.1 with a prefix length of 24 > indicates that all nodes with the matching 192.0.2.X are reachable > through this DYMO router. I'm not sure what exactly to do about this right now. The section is short and mostly O.K. I think. > > 5.9. Simple Internet Attachment > UH> ================ > UH> Unclear why this section is needed. Is this an example deployment? > UH> ================ > > Simple Internet attachment consists of a stub network of DYMO routers > connected to the Internet via a single Internet DYMO router (IDR). > UH> ================ > UH> What does "connected to the Internet" mean? How the routers know? > UH> Why introducing another acronym (IDR), just for an example? > UH> ================ I think it is mostly an example, except that the attachment point can't possibly have specific routes to every host in the Internet. > > DYMO routers, and hosts behind these routers, wishing to be reachable > from hosts on the Internet MUST have IP addresses within the IDR's > routable and topologically correct prefix (e.g. 192.0.2.0/24). > UH> ================ > UH> That's true for routing in general, not just for DYMO > UH> ================ True. I have added a clause to indicate this is not specific to AODVv2. > /--------------------------\ > / Internet \ > \ / > \------------+-------------/ > | > Routable & | > Topologically | > Correct | > Prefix | > +-----+------+ > | Internet | > /------| DYMO |-------\ > / | Router | \ > / |192.0.2.1/32| \ > | |Responsible | | > | | for | | > | |DYMO Region | | > | |192.0.2.0/24| | > | +------------+ | > | +--------------+ | > | | DYMO Router | | > | | 192.0.2.2/32 | | > | +--------------+ | > | +--------------+ | > | | DYMO Router | | > | | 192.0.2.3/32 | | > \ +--------------+ / > \ / > \---------------------------/ > > Figure 3: Simple Internet Attachment Example > > When a DYMO router within the DYMO Region wants to discover a route > to a node on the Internet, it uses the normal DYMO route discovery > for that IP Destination Address. The IDR is responsible for properly > responding to RREQ on behalf of the Internet destination. > > When a packet from a node on the Internet destine for a node in the > DYMO region reaches the IDR, if the IDR does not have a route to that > destination it will perform normal DYMO route discovery for that > destination. > > UH> ================ > UH> How would that work for multi-homing? > UH> ================ This part, as you mentioned before, does not work differently than for other Internet-attached networks. > 5.10. Multiple Interfaces > > DYMO may be used with multiple interfaces; therefore, the particular > interface over which packets arrive MUST be known whenever a packet > is received. Whenever a new route is created, the interface through > which the Route.Address can be reached is also recorded in the route > table entry. > > When multiple interfaces are available, a node transmitting a > multicast packet with IP.DestinationAddress set to LL-MANET-Routers > SHOULD send the packet on all interfaces that have been configured > for DYMO operation. > > Similarly, DYMO routers should subscribe to LL-MANET-Routers on all > their DYMO interfaces. > > UH> ================ > UH> It seems to be more complicated than just a small section like > UH> this. A large part of the complexity of, e.g., NHDP is due to multiple > UH> interfaces. It's been a long time since I looked at NHDP. My bit of participation wasn't very productive; I thought the protocol was too verbose as you probably remember. But I will take another look. It could be that something more needs to be said here, but up until now I didn't find any fault with the more simple formulation. > UH> Just some thoughts: On which interfaces are RM sent to? Which > UH> addresses are used as originator of a message? Is loop-detection more > UH> difficult with several interfaces? > UH> ================ The multicast RM is sent over all interfaces whose IP addresses belong to the multicast group. The message originator, e.g. OrigNode, depends on the message. Loop detection should work the same way with multiple interfaces, and as best I remember from all the cases handled by AODV this was never a problem. > > 5.11. DYMO Control Packet/Message Generation Limits > > To ensure predictable control overhead, DYMO router's rate of packet/ > message generation SHOULD be limited. The rate and algorithm for > limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the implementor > and should be administratively configurable or intelligently > controlled. DYMO control messages SHOULD be discarded in the > following order of preferences RREQ, RREP, and finally RERR. > UH> ================ > UH> I think that this is too vague. I would prefer to have a basic > UH> mechanism explained how to do that (e.g. having MIN_INTERVAL > UH> parameters) > UH> ================ Work to do... contributions greatly appreciated. ... > In situations where routing information or router identity are > suspect, integrity and authentication techniques SHOULD be applied to > DYMO messages. In these situations, routing information that is > distributed over multiple hops SHOULD also verify the integrity and > identity of information based on originator of the routing > information. > > UH> ================ > UH> That seems impossible in DYMO, since intermediate routers can (i) > UH> cache target destinations and (ii) modify forwarded messages. > UH> ================ This was discussed earlier in this email. > > > > Appendix A. Shifting Responsibility for an Address Between DYMO Routers > UH> ================ > UH> Section is unclear to me. > UH> ================ > > Only one DYMO router within a routing region SHOULD be responsible > for a particular address at any time. If two DYMO routers > dynamically pass responsibility of an address correct DYMO routing > behavior must be observed. The DYMO router adding the new address > must wait for any exiting routing information about this address to > be purged from the network. Therefore, it must wait at least > ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the previous DYMO router for this > address stopped participating and advertising routing information on > its behalf. > > I agree that this needs to be made much clearer. Thanks again for the detailed review. I have made revisions according to the comments above. I agree that more work needs to be done especially to improve clarity and proper handling of RFC 5444 messages when bundled with non-AODVv2 messages. Regards, Charlie P. -- Regards, Charlie P. From charliep@computer.org Mon Oct 22 09:00:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED0321F8C12 for ; Mon, 22 Oct 2012 09:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT5qqwOVDoPI for ; Mon, 22 Oct 2012 09:00:42 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id AEE8B21F89A8 for ; Mon, 22 Oct 2012 09:00:42 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TQKQk-0000kU-2U; Mon, 22 Oct 2012 12:00:42 -0400 Message-ID: <50856DA8.1090707@computer.org> Date: Mon, 22 Oct 2012 09:00:40 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8691262f4b7173bdd33d3fae80f5643fe6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] AODVv2, or DYMO, Is WG I-D X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:00:43 -0000 Hello Abdussalam, There has been a lot of discussion about how to proceed with the [manet] WG reactive protocol document. The discussion hasn't resulted in a resolution, but the uncertainty about it did inhibit me from responding. I hope that the draft which I will submit this afternoon will represent a very positive step forward, to be continued without further interruption until all the comments are resolved and the specification completed. Regards, Charlie P. On 10/17/2012 2:04 AM, Abdussalam Baryun wrote: >> Or use >> draft-ietf-manet-dymo-23 placeholder. >> > I did not understand why we still not seen our I-D reactive protocol > renewed. I don't agree to replace it with any other, please note no > one allowed to replace including the dymo-authors only after the WG > permission, > > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From charliep@computer.org Mon Oct 22 09:45:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D811B21F84D6 for ; Mon, 22 Oct 2012 09:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVZFgqDuNKIY for ; Mon, 22 Oct 2012 09:45:16 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id A8F2221F8549 for ; Mon, 22 Oct 2012 09:45:16 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TQL7r-0000Vq-H0; Mon, 22 Oct 2012 12:45:16 -0400 Message-ID: <50857817.1010602@computer.org> Date: Mon, 22 Oct 2012 09:45:11 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Georg Wittenburg References: <201101121219.58614.georg.wittenburg@gmail.com> In-Reply-To: <201101121219.58614.georg.wittenburg@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad860d9b9bd37acc231f06dacd2edcbbb382350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet@ietf.org Subject: Re: [manet] Review of DYMO Draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:45:18 -0000 Hello Georg, Please excuse the long delay in responding to your comments. On 1/12/2011 3:19 AM, Georg Wittenburg wrote: > - 3. Terminology > > The reserved numeric values for unknown Distance (Dist) and Sequence Number > (SeqNum) should be stated somewhere, preferably in this section. One could > probably use zero (0), but it would be helpful to have some explicit statement > about this. For both Distance and SeqNum, I included a sentence in the definition. However, since the current distance is always a hop count, 65,535 does not make sense as a maximum value, whereas 0 *is* a valid distance value. I changed the spec as follows: The minimum value of distance is the number of IP hops traversed, 0 for local information. The maximum value is 254. The value 255 is reserved to indicate that the distance is unknown. and The value zero (0) is reserved to indicate that the SeqNum for a destination address is unknown. > - 4.2.2. Routing Messages (RM) - RREQ & RREP > > TargetNode.AddTLV.Dist is listed as an optional field, but not used anywhere in > the document I have removed this from the base specification. > > > - 5.3.1. RREQ Creation > > There should be an explanation why OrigNode.Dist is to be set to a number > greater than zero and some advice on which value to use. Done. > > In fact, I'm somewhat doubtful about the Dist field in general. Sec. 5.2.2 > states that when creating or updating a routing table entry "if known, the > Route.Dist is set to the Node.Dist". Node.Dist, in this context, is set by the > sender of the routing message. However, for any non-trivial metric, the > distance (i.e., the path metric) should differ depending on the link quality > between sender and each of the potentially multiple receivers of a routing > message. Hence, it should be up to each receiver to calculate Dist depending > on the link quality (rather than using the sender-specified Node.Dist from the > routing message which would be the same for all receivers). I agree with this, and after the revision to be submitted today, I will work on using nontrivial metrics with AODVv2. I will also post the issue on the Issue Tracker. > - 5.3.1. RREQ Creation > > The statement "For links that do not support multicast or situations in > which unicast messaging is preferred, the IP.DestinationAddress for unicast > RREQ is set to the NextHopAddress." could be more clear about what > NextHopAddress (= IP address of the respective unicast destination) means in > this context. The same applies to Sec. 5.5.3. "RERR Generation". Yes. I have made some clarification about this. > - 5.3.4. RM Handling > > I found it slightly confusing that the processing of RREQs and RREPs is > presented in the same section. Personally, I would have preferred two separate > sections for each of them, which the commonalities (i.e., shared code in the > implementation) in specific sub-section. I hope that the new draft is much clearer about this. > - 5.5.2. Updating Route Lifetimes During Packet Forwarding > > If the processing of a data packet causes the routing timers to be reset (as > specified in the draft), then the respective Route.Broken flag should also be > cleared and the Route.Forwarding flag should set. This covers the case in which > data packets arrive from a next-hop neighbor for which a route has been flagged > as broken, but has not yet been removed from the routing table. Thanks for catching this. I have added the following for both cases: "The Route.Broken flag is unset." The Route.Forwarding flag was removed from the draft. > Further, the timers for a routing table entry should be reset when processing > both data AND signaling packets (i.e., RREQs and RREPs). Otherwise, existing > routes along which these packets are forwarded may get deleted before seeing > any data traffic. Note that for RREPs this includes the timers for the routing > table entries to both the originator and target node. Yes, this is also true. I have changed the draft to refer to AODVv2 messages as well as data packets. > > Similarly, when sending an intermediate RREP (Sec. 5.3.3), the timers for the > routing table entry of the TargetNode should also be reset. > > > - 6. Administratively Configured Parameters and Timer Values > > The default value of ROUTE_SEQNUM_AGE_MAX_TIMEOUT (60 seconds) may cause > low-bandwidth routes to be discarded prematurely. As the tradeoffs are non- > obvious, it would be nice to have multiple recommendations for different > scenarios. I realize that this may require more real-world experience with the > protocol, but don't really consider this to be a counterargument. I definitely agree with this. I don't think there are any realistic use cases where this TIMEOUT needs to be less than 600 seconds, and probably the TIMEOUT should be even much longer than that. In the meantime, I will change 60 to 600. > Similarly, the value for ROUTE_RREQ_WAIT_TIME (2 seconds) should be more > expressive. For instance, AODV (RFC 3561) uses NET_TRAVERSAL_TIME = 2 * > NODE_TRAVERSAL_TIME * NET_DIAMETER = 2 * 0.04s * 35 = 2.8s. A similarly > detailed definition should be used in this draft. Furthermore, the value should > be large enough to give retries of RREQs a chance to succeed (possibly taking > lower TTLs into account, if expanded ring search is employed). > > Finally, the statement "The above timing parameter values work well for small > and medium well-connected networks with moderate topology changes." is a too > general to be useful. Once again, exact values for the number of nodes and the > node degree that led to this recommendation would be more helpful. I hope that we can get some more recommendations for these. My belief is that the timeout parameters are all too small. Also, there have been experiments networks with greater than 10 hops running AODV, so I changed the MSG_HOPLIMIT to be 20. In AODV, NET_DIAMETER was 35, and NET_DIAMETER should be less than MSG_HOPLIMIT. What if I change the AODVv2 parameters to match the AODV parameters more closely? -- Regards, Charlie P. From hrogge@googlemail.com Mon Oct 22 09:54:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9921F8923 for ; Mon, 22 Oct 2012 09:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N-qIXk4BMa1 for ; Mon, 22 Oct 2012 09:54:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC521F8437 for ; Mon, 22 Oct 2012 09:54:13 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2140898pbb.31 for ; Mon, 22 Oct 2012 09:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=T9iik8Rt30u3WO30/VlCFujv7iFqamFsro91+1//dXg=; b=dvfWnOSQi/6I+v3kwq3AP8mazaBYSjeSUFC6vIMQeB8bfAzmdqe6acVhD8JG7yRlWS ulhmsuTPk3ygNLaJsnD4gTatWK6f08yXo+G7C4xuZZwfIVCeMoaXIuq+yRFp6/F0rrlF QUXs6s5/fTJ0rzH8jtcsWK7L0MJvTuwfGN0V4Ys/Fb29iQpSRaZwm+x76g8snjaT12Sd YrWeFRoU/CJ0t7Uv32tDzOjU8mlf+po+L1PZbKtkp3ZlnyzTut8QVfI60zBDGXc0sw1e A1Ye1AP/hjHwJBqiwhcb9UnKH1F1Umo6HPucoV65qvd44XS82vw2TOzJ9xs4drlA5KlG llfw== Received: by 10.66.84.131 with SMTP id z3mr27519809pay.34.1350924841876; Mon, 22 Oct 2012 09:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Mon, 22 Oct 2012 09:53:41 -0700 (PDT) In-Reply-To: <50857817.1010602@computer.org> References: <201101121219.58614.georg.wittenburg@gmail.com> <50857817.1010602@computer.org> From: Henning Rogge Date: Mon, 22 Oct 2012 18:53:41 +0200 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, Georg Wittenburg Subject: Re: [manet] Review of DYMO Draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:54:20 -0000 On Mon, Oct 22, 2012 at 6:45 PM, Charles E. Perkins wrote: > The minimum value of distance is the number of IP hops > traversed, 0 for local information. The maximum value > is 254. The value 255 is reserved to indicate that the > distance is unknown. Do you have a proper use for this "unknown" distance? Why not just leave out the distance TLV? > The value zero (0) is reserved to indicate that the SeqNum > for a destination address is unknown. I think its a REALLY bad habit to define some crazy rules for sequence numbers. All generated DYMO message will have sequence numbers, so if a node remembers another node and its addresses, it also remembers the sequence number. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From charliep@computer.org Mon Oct 22 10:05:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86C21F88F5 for ; Mon, 22 Oct 2012 10:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FkeHHqNEtB7 for ; Mon, 22 Oct 2012 10:05:09 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 345E621F88DC for ; Mon, 22 Oct 2012 10:05:09 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TQLR6-0001WX-IB; Mon, 22 Oct 2012 13:05:08 -0400 Message-ID: <50857CC2.9080502@computer.org> Date: Mon, 22 Oct 2012 10:05:06 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Henning Rogge References: <201101121219.58614.georg.wittenburg@gmail.com> <50857817.1010602@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86a4efb6eab9b1e7b8d5fe7a807aa3c495350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet@ietf.org Subject: Re: [manet] Review of DYMO Draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:05:10 -0000 Hello Henning, On 10/22/2012 9:53 AM, Henning Rogge wrote: > On Mon, Oct 22, 2012 at 6:45 PM, Charles E. Perkins > wrote: >> The minimum value of distance is the number of IP hops >> traversed, 0 for local information. The maximum value >> is 254. The value 255 is reserved to indicate that the >> distance is unknown. > Do you have a proper use for this "unknown" distance? Why not just > leave out the distance TLV? I don't have a ready answer for this just now. I need to take a close look at how it affects the draft. But, thanks for the suggestion. I'll try to respond properly within the next few days. > >> The value zero (0) is reserved to indicate that the SeqNum >> for a destination address is unknown. > I think its a REALLY bad habit to define some crazy rules for sequence > numbers. All generated DYMO message will have sequence numbers, so if > a node remembers another node and its addresses, it also remembers the > sequence number. Currently, there has to be some value for unknown sequence number, and it is possible for information about sequence numbers to get lost if nodes crash and reboot. This was one of the important lessons from AODV. Whatever value is chosen has to be "reserved", and then rollover has to be specified to avoid the "reserved" value. There is another way to do it, which I can propose later, but it might be seen to add complexity and storage. And anyway I couldn't do it by the submission deadline today. Should this be put in as an issue on the Issue Tracker? -- Regards, Charlie P. From hrogge@googlemail.com Mon Oct 22 10:18:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9595011E80EC for ; Mon, 22 Oct 2012 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e4gv8TXNd6r for ; Mon, 22 Oct 2012 10:18:51 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4FC11E80A4 for ; Mon, 22 Oct 2012 10:18:51 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1471942dan.31 for ; Mon, 22 Oct 2012 10:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UBreC7g3r9ImiOVSzRwB+mMGLnoAxABIdfkWLR4Zhj4=; b=wfDRjCNWVV9Ye7BOo++v/0D0v2gEgZnq/wfzWsnGECz2qzsAPgKUxYdwtovj4WHojA ua0OYZJNjhEtJjKVPvLUKJtGJ5FRb4GteF7n7U2Xf+dPZZsR/jgxbm4rrAAm5WMwcnXH IN3qvfFoeNhu4DGqnRQ4ZyeablhPweu2HHwokEXPc+coXuGo8I7FFXzPm9e7m3Jknba8 tZaPdgpcn/JBVodD9oz69/7Fuij+QJbSY/hJmfU+m0dC/qDMi8+TDsqBr8DoYearAM+1 6ZtiA8bCgB23CoSqkAk3G7aYobwhVyW2OKuMQrMk81RRa+b2w9Kl3r6S+zsP+vKLCHec mCKQ== Received: by 10.68.203.227 with SMTP id kt3mr9868312pbc.13.1350926331288; Mon, 22 Oct 2012 10:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Mon, 22 Oct 2012 10:18:31 -0700 (PDT) In-Reply-To: <50857CC2.9080502@computer.org> References: <201101121219.58614.georg.wittenburg@gmail.com> <50857817.1010602@computer.org> <50857CC2.9080502@computer.org> From: Henning Rogge Date: Mon, 22 Oct 2012 19:18:31 +0200 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Review of DYMO Draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:18:52 -0000 On Mon, Oct 22, 2012 at 7:05 PM, Charles E. Perkins wrote: > Hello Henning, >> I think its a REALLY bad habit to define some crazy rules for sequence >> numbers. All generated DYMO message will have sequence numbers, so if >> a node remembers another node and its addresses, it also remembers the >> sequence number. > > Currently, there has to be some value for unknown sequence number, and > it is possible for information about sequence numbers to get lost if nodes > crash and reboot. Wouldn't this make the information related to the sequence number also be lost? Is this really different than a non-existing database entry? > This was one of the important lessons from AODV. > Whatever value is chosen has to be "reserved", and then rollover has to > be specified to avoid the "reserved" value. If DYMO needs to transmit a "don't know the sequence number" information attached to an address in an address block, just do not attach the sequence number TLV. Even the message sequence number is optional, no need to have a special symbol there either I think. > There is another way to do it, which I can propose later, but it might be > seen to add complexity and storage. And anyway I couldn't do it by the > submission deadline today. Do you expect not be able to afford a single additional bit for "sequence number known/unknown" in the internal database? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From rdroms@cisco.com Mon Oct 22 10:52:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30BA21F8A25 for ; Mon, 22 Oct 2012 10:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJzk4VTJQl39 for ; Mon, 22 Oct 2012 10:52:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2621F89B3 for ; Mon, 22 Oct 2012 10:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=631; q=dns/txt; s=iport; t=1350928370; x=1352137970; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=COAxhQwNS5BqS54g51oex4q7/RMWDxu7nCIhy53DRNY=; b=D23DDZibvu9ktzjFKIIiqI485HyaJ/TW3HTJ3j33r1z1X8+FIymRtkSb qh4Ys0ceK+WDsLPiWj6Vs6ySDEEWx/YoHyXszRbGK1nc92VvBdacglDT6 loNQ9zRVlzaMdQ60gBij6JHQchNO8I79ldfsE0qDzefOwawFb3dnkqrzB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE6GhVCtJV2Y/2dsb2JhbABFwRmBCIIiAQQSASc0HQEqFEInBBsah2KacIErn3iRbmADpD+Ba4Jvghg X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="134175149" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 22 Oct 2012 17:52:50 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MHqnF5024631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 17:52:49 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 12:52:49 -0500 From: "Ralph Droms (rdroms)" To: manet Thread-Topic: AD review of draft-kelsey-intarea-mesh-link-establishment Thread-Index: AQHNsH4Mcc+BCVRJaEODfuq8NgAuAA== Date: Mon, 22 Oct 2012 17:52:49 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA32660B5@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.243] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--32.043200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <89691C71F8C2314297F482A6D3FE30BA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] AD review of draft-kelsey-intarea-mesh-link-establishment X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:52:51 -0000 I've been asked to sponsor draft-kelsey-intarea-mesh-link-establishment as = an AD-sponsored individual submission. As part of my AD review of the docu= ment, I'm soliciting input from a variety of relevant communities, includin= g the manet WG. I expect to complete my review next week and then send the document out for= IETF last call. Please respond with comments by next Monday, Oct 29, eith= er to the mailing list or directly to me. I'm aware that the last call wi= ll overlap the IETF meeting in Atlanta but it will be a four week last call= , which should be enough for reviewing this document. - Ralph From sratliff@cisco.com Mon Oct 22 11:00:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020E611E80A4 for ; Mon, 22 Oct 2012 11:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x4k--2PC2Hj for ; Mon, 22 Oct 2012 11:00:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5844011E80A2 for ; Mon, 22 Oct 2012 11:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=941; q=dns/txt; s=iport; t=1350928845; x=1352138445; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rv9YBotMvZf1ygHEfiBYGHoJQi0iGN56OJ/fZEySmDU=; b=dLv+L6ifv183jJH33EYy8+XPTHiFZyBtSnnrT3JcbWWfurjUUJOHmByq zcJ1YBd3tyF3jLhrRbj6J1X76kJVdPZpBhlmKAh/uvvLYlrfPHJm9GYjs kTUpriP9G72Tdyfl19e3lqnJK0wVDSoHI2og2dx9kmDyf+CzU/DmyCOIt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAJeIhVCtJXG+/2dsb2JhbABFhU27TIEIgiABAQEDAQEBAQ8BJzQLBQsCAQgiFBAnCyUCBA4FCBqHXAYLnAyfdASLX4YPYAOkP4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="134220263" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2012 18:00:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9MI0iad028187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 18:00:44 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 13:00:44 -0500 From: "Stan Ratliff (sratliff)" To: "Ralph Droms (rdroms)" Thread-Topic: [manet] AD review of draft-kelsey-intarea-mesh-link-establishment Thread-Index: AQHNsH4Mcc+BCVRJaEODfuq8NgAuAJfF8SSA Date: Mon, 22 Oct 2012 18:00:43 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41ED86@xmb-aln-x03.cisco.com> References: <4518F39EB578034D8C99A9B7776CDBA32660B5@xmb-aln-x04.cisco.com> In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA32660B5@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--40.063700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5222417D7C4788498443C1E679118347@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] AD review of draft-kelsey-intarea-mesh-link-establishment X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:00:46 -0000 Ralph,=20 Thanks for the notice.=20 WG - please review and comment.=20 Regards, Stan On Oct 22, 2012, at 1:52 PM, Ralph Droms (rdroms) wrote: > I've been asked to sponsor draft-kelsey-intarea-mesh-link-establishment a= s an AD-sponsored individual submission. As part of my AD review of the do= cument, I'm soliciting input from a variety of relevant communities, includ= ing the manet WG. >=20 > I expect to complete my review next week and then send the document out f= or IETF last call. Please respond with comments by next Monday, Oct 29, ei= ther to the mailing list or directly to me. I'm aware that the last call = will overlap the IETF meeting in Atlanta but it will be a four week last ca= ll, which should be enough for reviewing this document. >=20 > - Ralph > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Mon Oct 22 11:16:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E01F0C44 for ; Mon, 22 Oct 2012 11:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUa3KDQqqMuw for ; Mon, 22 Oct 2012 11:16:09 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 43E471F0C42 for ; Mon, 22 Oct 2012 11:16:09 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id D7DBA5586FC for ; Mon, 22 Oct 2012 11:16:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D08136071D; Mon, 22 Oct 2012 11:16:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E271C60722; Mon, 22 Oct 2012 11:15:54 -0700 (PDT) From: Thomas Heide Clausen Content-Type: multipart/mixed; boundary=Apple-Mail-2F3798D4-F1BC-4B8C-BC6A-5A52D0E98076 X-Mailer: iPad Mail (10A403) Message-Id: <359F37C1-31EB-4A90-A897-255617529662@thomasclausen.org> Date: Mon, 22 Oct 2012 20:15:53 +0200 To: " List" , Ralph Droms , Stan Ratliff Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: [manet] Review of draft-kelsey-intarea-mesh-link-establishment-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:16:09 -0000 --Apple-Mail-2F3798D4-F1BC-4B8C-BC6A-5A52D0E98076 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear all, Kindly find my review of the I-D in below. Note that I have reviewed a= n earlier version of this document (I believe it was -02) as well, and the a= uthors were quite reactive to my comments (thanks, Richard!). Ralph, this review is identical to the one you received in unicast a few day= s ago. As you ask on the [manet] mailing list, I re-send my review to that l= ist to be "publicly on the record". My main worry is, that MLE seems to overlap substantially with the scope of R= FC6130, and that is something which I would want to see clarified before mov= ing forward. As usual, textual comments below, an annotated PDF attached. Respectfully yours, Thomas See file attached to this message File: 121018 - THC Review - draft-kelsey-intarea-mesh-link-establishment-04-= 1 - flattened.pdf Annotation summary: --- Page 1 --- Highlight (yellow), 18 oct. 2012 13:30, TClausen: ad hoc mesh network Note (yellow), 18 oct. 2012 13:30, TClausen: I'm being a nitpicker here, but: ad hoc mesh network? Is that the same as a m= obile ad hoc network? Or is it something else? Or, is it - like LLNs - a sub= set of a mobile ad hoc network? I guess that this ties in with trying to understand where this fits into the= IETF picture. I am repeating myself here from my last review, but so far th= is sounds like something that belongs in [MANET]. This comment, probably, is= to the sponsoring AD more than to anything else, but this document does see= m like something that would belong in a working group, and it does seem like= there should be at least one working group, in which this would be "in scop= e". I understand that the [MANET] and [ROLL] wg chairs have refused to accept th= is document, even discuss it in meetings. I would assume that they have good= reasons? If not, then I would recommend that they be "encouraged".=20 Highlight (yellow), 18 oct. 2012 13:30, TClausen: Internet Area WG Note (yellow), 18 oct. 2012 13:30, TClausen: 1) Is that true? 2) Isn't tradition that all I-Ds are published in the "Networking Working Gr= oup"? Note (yellow), 18 oct. 2012 13:30, TClausen: I am making the same comment as I did in my previous review: from reading th= e abstract, this looks very very much like RFC6130 except for the configurat= ion parameters -- which, as I think I have indicated, is something that coul= d simply be additional TLVs for RFC6130. I think that, at the very very least, why a different (from RFC6130) approac= h is taken should be clear even from the abstract. Note (yellow), 18 oct. 2012 14:37, TClausen: I have a couple of overall comments: o This document sorely needs an applicability statement. There are bits and pieces scattered through the document,=20 that can constitute parts of an applicability statement, but even that is not=20 sufficient o The document seems to claim to be supporting multiple L2s, but in many places looks as if designed for one specific L2 (PAN ID, Security, ...). This is not at all appropriate. o I am also missing some sort of overview- and-functioning section. There seems to be a number of different signaling=20 components (request network parameters/=20 reply ; periodic beaconing of ETX=20 parameters, security negotiation....) each=20 of which having different signaling=20 semantics. --- Page 3 --- Highlight (yellow), 18 oct. 2012 13:30, TClausen: recommend (NHDP) that their messages be sent over secured links Note (yellow), 18 oct. 2012 13:30, TClausen: As one of the authors of RFC6130, this is quite simply not true. If you have secured links, then sure, RFC6130 can use that.=20 Absent secured links, RFC6130 suggests adding TLVs containing authentication= (using RFC6622 - the actual spec for using RFC6622+RFC6130 is being develop= ed by [manet] currently]). So, this is not a distinguishing feature for MLE-vs-6130, and thus not a val= id motivation for MLE. Highlight (yellow), 18 oct. 2012 13:30, TClausen: already-configured links Note (yellow), 18 oct. 2012 13:30, TClausen: I am actually not sure what this means. NHDP makes few assumptions as to what the underlying link layer does, other t= han support broadcast transmissions. The L2 may do "stuff" (negotiate inter= face speeds, or some such thing). Allow me also to ask: when you say "link", what exactly is meant? In NHDP, i= t is simply "any two interfaces, able to communicate with each other". ND h= as a very different understanding of link. Highlight (yellow), 18 oct. 2012 13:30, TClausen: IP properties Note (yellow), 18 oct. 2012 13:30, TClausen: ND, yes - NHDP, not so much.=20 Note (yellow), 22 oct. 2012 20:06, TClausen: So this sounds like a channel-estimation protocol of sorts. Is that related t= o the ETx estimations?=20 I remember on manet@ietf that there has been some contention as to what the p= roper information exchange is for evaluating such, has this been reflected? Highlight (yellow), 18 oct. 2012 13:30, TClausen: multicast Note (yellow), 18 oct. 2012 13:30, TClausen: Observing also, that different L2's Note (yellow), 18 oct. 2012 13:30, TClausen: Observing also, that different L2's treat unicast and broadcast differently:= transmission rates, retransmissions, .... --- Page 5 --- Note (yellow), 18 oct. 2012 13:30, TClausen: So, at this point, you are with MLE at the same point as NHDP: if a device h= as an IP address, it can participate in NHDP. For MLE to use UDP, this would= be the same. The message exchange in NHDP serves to establish, for a router and over each= interface, the "links" to neighbors. The minimum property that is establish= ed by NHDP is bidirectional connectivity, but this is by design - and for fu= rther properties (such as ETX, if needed) can be done by TLVs. Again, my point is not saying "thou shalt use" another protocol, but I would= very much like for it to be clearly spelled out in which way this is not "o= ld wine in smaller bottles". This very much links in with the lack of an applicability statement in this d= ocument, which is an absolute must given what appears to be a strong overlap= with what other protocols do. --- Page 6 --- Note (yellow), 18 oct. 2012 13:30, TClausen: Is this not something that should be parametrized and set up IANA registries= ? I see that you agree, there is a registry. In that case, I would recommend= to not specify these security suites in the main part of the document, but s= imply hive those specifics off to the IANA registry, and define the interfac= e between MLE and these suites? In other words, I would avoid "this document describes two security suites" Note (yellow), 18 oct. 2012 13:30, TClausen: So is this specific to 802.15.4, or is it general? Again, this is one bit that would benefit from having a proper applicability= statement. So far in this I-D, one could get away with the impression that i= t was for "general L2s", but this seems to indicate otherwise? Note (yellow), 18 oct. 2012 13:30, TClausen: Is the length of that constant? For all security suites? When not running ov= er 802.15.4? Highlight (yellow), 18 oct. 2012 13:30, TClausen: MUST NOT Note (yellow), 18 oct. 2012 13:30, TClausen: Why is that? A bit of education here, please... --- Page 7 --- Note (yellow), 18 oct. 2012 14:37, TClausen: This reads like a "mini-IANA section", embedded into the middle of the docum= ent. I vividly recommend, in the IANA section, to define values, mnemonics, and d= escriptions, and use the mnemonics in the document.=20 That way, when IANA assign numbers, there is less space for confusion in edi= ting. --- Page 8 --- Note (yellow), 22 oct. 2012 20:06, TClausen: This is incoherent. The section is entitled "values", yet the content is the= TLV format. Suggest changing to "TLV Format" Note (yellow), 18 oct. 2012 14:37, TClausen: Reference to IANA registry, wherein these TLVs are defined. Note (yellow), 18 oct. 2012 14:37, TClausen: A question: is multiple TLVs with the same type permitted or not? Or, must t= hat be specified for each TLV type? I would suggest that the general rule be given here, if it is "must be speci= fied for each TLV type", then this should be called out -- and, the document= MUST in that case say that "each TLV type defined MUSt specify if it is per= mitted to have more TLVs of that type in a given message" - or something. For all of the below, references to IANA section, by way of mnemonics, not n= umber-values, are required. Note (yellow), 18 oct. 2012 14:37, TClausen: Is this represented in the same TLV (and how), or by way of including multip= le TLVs of that type? Note (yellow), 18 oct. 2012 14:37, TClausen: 1) presumably, only one TLV of that type may exist in a message? 2) how are all those different kinds of information encoded in this TLV? Highlight (yellow), 18 oct. 2012 14:37, TClausen: specific to the link layer in use Note (yellow), 18 oct. 2012 14:37, TClausen: This is a no-go. While it may be specific to the link-layer, you need this specified somewher= e; as it is, I couldn't implement it. Also, you previously - with respect to security - seemed to link the protoco= l very tightly to 802.15.4, so this seems to be an internal contradiction? Finally, you presumably will only want one of these per message? Note (yellow), 18 oct. 2012 14:37, TClausen: You presumably will only want one of these per message? --- Page 9 --- Note (yellow), 18 oct. 2012 14:37, TClausen: I cannot figure out if you want only one, or more, of these TLVs in a given m= essage....I would imagine that you would need more than one in some circumst= ances? Highlight (yellow), 18 oct. 2012 14:37, TClausen: each Note (yellow), 18 oct. 2012 14:37, TClausen: Each TLV in the same, or in different, messages? Note (yellow), 18 oct. 2012 14:37, TClausen: Presumably, you should want this in the security considerations section? Note (yellow), 18 oct. 2012 14:37, TClausen: In that case, same comment as above regarding how many TLVs, as well as disc= ussion in the security considerations section apply here as well. Note (yellow), 18 oct. 2012 14:37, TClausen: Presumably, you want only one of these in a message? Note (yellow), 18 oct. 2012 14:37, TClausen: Presumably, you want only one of these in a message? --- Page 10 --- Note (yellow), 18 oct. 2012 14:37, TClausen: How should this be set when transmitting, or interpreted when received? Usually "Reserved, and MUST be set to 000 on transmission and SHOULD be igno= red on receipt to be in compliance with this version of the specification" i= s the used phrase. Note (yellow), 18 oct. 2012 14:37, TClausen: 1 to 16 what? Octets? Gigabytes? ;) Note (yellow), 18 oct. 2012 14:37, TClausen: OK, so here you give guidance as to what is the expected behavior, and that i= s good. On the other hand, why "SHOULD NOT" and not "MUST NOT"?=20 I am of the mind that unless there are really compelling reasons (in which c= ase, these reasons should be spelled out, as well as their consequences), it= should be MUST/MUST NOT. As it is, I have not managed to come up with a com= pelling reason as to why one would want to not write MUST NOT here. UNLESS, that is, that these are broad/multicast, in which case I would imagi= ne that one would need one such TLV per neighbor (and it should be specified= to be exactly one per neighbor)? --- Page 11 --- Note (yellow), 18 oct. 2012 14:37, TClausen: This bit appears underspecified, to say the least. Either you describe how t= o do that precisely later, or it has to be described here. Also, I infer that there can be multiple of this TLV type in a given message= ? Note (yellow), 18 oct. 2012 14:37, TClausen: Again, why not must? Highlight (yellow), 18 oct. 2012 14:37, TClausen: SHOULD be multicast to the entire MLE domain. They MAY also be=20 Note (yellow), 18 oct. 2012 14:37, TClausen: Suggest: "SHOULD be multicast to the entire MLE domain, except for when a node that h= as just joined the network, in which case a Network Parameter TLV MAY be uni= cast to that node". --- Page 12 --- Note (yellow), 18 oct. 2012 14:37, TClausen: Another IANA registry to set up, as well as mnemonics, reference, ... Highlight (yellow), 18 oct. 2012 14:37, TClausen: PAN Note (yellow), 18 oct. 2012 14:37, TClausen: This reads as if linked to a specific L2? Note (yellow), 18 oct. 2012 14:37, TClausen: Again, presumably just one permitted per message? --- Page 13 --- Note (yellow), 18 oct. 2012 14:37, TClausen: Under which conditions is is acceptable to not do thus? Note (yellow), 18 oct. 2012 14:37, TClausen: No, this is a MUST - otherwise, interoperability can't be ensured. Note (yellow), 18 oct. 2012 14:37, TClausen: Suggest "sent using the MLE-port, and then define MLE port in IANA and reque= st the assignment there? Note (yellow), 18 oct. 2012 14:37, TClausen: Suggest sticking a reference into the document, to the RFC defining those. Highlight (yellow), 18 oct. 2012 14:37, TClausen: MAY Note (yellow), 18 oct. 2012 14:37, TClausen: How many times? Minimum and maximum intervals? This MUST be defined. I do no= t think that the reference stuck in suffices. --- Page 15 --- Note (yellow), 18 oct. 2012 14:37, TClausen: So, a couple of different things... What is the appropriate behavior if one receives two identical TLVs? With co= nflicting values? Can such be discarded? This section does not specify what one does with an incoming message other t= han security (and, even that is very weakly defined). I would, at the very l= east, expect a protocol set / information set defined, that represents the v= alues received, and which is updated according to the message exchange. I understand that this may be something that a "smart implementer can think o= ut herself", alas, while that may well be true, I do not find it sufficient.= In part, an information set defined would give the interface to the rest of= the system (in which I believe that this integrates?). As it is, it's insuf= ficient. --- Page 16 --- Highlight (yellow), 18 oct. 2012 14:37, TClausen: This section is not normative Note (yellow), 18 oct. 2012 14:37, TClausen: In that case, I would suggest that it be stuck into an appendix..... --- Page 19 --- Note (yellow), 18 oct. 2012 13:30, TClausen: Recommended reading: RFC58 Note (yellow), 18 oct. 2012 13:30, TClausen: Recommended reading: RFC5226. Also, ther Note (yellow), 18 oct. 2012 13:30, TClausen: Recommended reading: RFC5226. Also, Are you sure that IETF review is what you want, it seems fairly restri= ctive to me -- would allocating a few code-points as "experimental" and a go= od lot for "expert review" (with proper guidelines) not be a good idea? Generally, a couple of code-points for experimental use is a good thing.=20 I am not a security wonk, so I do not know - but are all security related su= ites translated into RFCs (which are a necessary precondition for IETF Revie= w)? Note (yellow), 18 oct. 2012 14:37, TClausen: Recommended reading: RFC5226. Also, Are you sure that IETF review is what you want, it seems fairly restri= ctive to me -- would allocating a few code-points as "experimental" and a go= od lot for "expert review" (with proper guidelines) not be a good idea? Generally, a couple of code-points for experimental use is a good thing.=20 I am not a security wonk, so I do not know - but are all security related su= ites translated into RFCs (which are a necessary precondition for IETF Revie= w)? Finally, I have given comments through the I-D that it is greatly preferred t= o define mnemonics for each code-point, and use those through the document -= leaving actual numbers for IANA to manage. Note (yellow), 18 oct. 2012 14:37, TClausen: Subregistry of what? There are, as I see it, two distinct options: A registry under MLE A registry under each command code. It is not clear to me what it is, how you define your namespace here, so thi= s should be clarified. (report generated by GoodReader) --Apple-Mail-2F3798D4-F1BC-4B8C-BC6A-5A52D0E98076 Content-Type: application/pdf; name*0="121018 - THC Review - draft-kelsey-intarea-mesh-link-establishme"; name*1="nt-04-1 - flattened.pdf" Content-Disposition: attachment; filename*0="121018 - THC Review - draft-kelsey-intarea-mesh-link-establishme"; filename*1="nt-04-1 - flattened.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nLVXS2/bOBC++1cMeukWiGVL8rO3tnGL7qZFNzWwh8UeaGkksZFEhaSc+tj+ 8p2hKD/bRYtm48B2RPKbj/P4ZnIP4yCEMb/8Z1INRrdzyM0gBH7pfDAdL4J4uYB42n1OlpM4iGA+ W/KHxkE2cAhw+8Z/oUP3g7D77j+SCl6uCXpJD4LpeBnDOht0JkOY0+88CuLFEtbV4Le3tUVdo4UX GgX89QZ+7uc2gD+wNLh7tv40CKNgFo4J9+aAO7zWIrM/jLeqNqjhldKN0sJKVT972mHVKaZgrLCt eQ4frahToVMDay2Su//A+72tEaLFFUTjMGKs1edGaiSMa0zQGYvH+9V4HiziOHIX+B7iOzQF3Mj6 DlZEZ1NKU1RYWzp9fP3jEyl7YHjn3DSUtRXk6WFFMMOSYIZ4DDMcTwgpmgZRFMUO6cXGWLokG2DU dSENpCppeTekmMkaDdgCgRGBEeEEEb68u1l9hUYrqxJVQqb0Jdf9CVnnQL6FRNWZzFvNfxtMWo0O 2oCsaR1ECoVKOpNapFJ5dhTwB6XvAgpklmFi5dbz8gsM1xp+d6c8psb7loPiQWRKtGW2o21Xx0Su HDPHpsMhyj0tq8iEzIuN4jUPlOJWJmiIzdsL1p4QCL/rqdkDGKjEjgxXyAY9Vq5AdH72J+lA5RKI nNY4Zk2xMzIRJWC9lVrVzvtJIeocA4/yHh/K3SnzGimxif4G+4tLenAcA+w5iNaqiqqCbJS7K3go kMLS73LVAltRtpQPCd1W1knZpp2ZYSl2qHuYNCVnGzRXQJlVm0paZ09TRbiAqZTXOkfbHTRCiwqp nI2PQB9tSiVbkHcpwXprnYtU48io7BAtfnxC1WNQMIzIu3OVwXLLpsnTB9YHIpT5dtd014da9SUh tkKWzqONlkqzM08sBWcV9dGpCLOzXEzvsFLHxXWmXPTEtBvykaWwUPZnbVk6fKUrUScID9IWzP6y qqjmttIQA2eM1lfrwZ+DToa9foc/rd/hfBGEyylM4jBYLCMn4i9ffYD5giV4b+EXOkQUzoJxtDix 4AJ/YuAXrhBN5sF0+o0rLB/tCoup63DHFgIGH0bhxK0M9xmRulidRt0AiTT0itXLrc8Z3G+GVZ2T /qLTnL4BhnEf/7Uwd/BaaUqSL29X69dfqVbeK4uEISwoQtKQa9U2neKI0ihIJcm93LQWfU5ekhDn OcoKty640o1lilQumrVnv8tD+atRRpP5R0tH8jD5M54tqHfOnKcLa5vno1EqqNC4P6MOJNosUDof uWZoRp7i6LECPqExiXP2mEYX8JiGHV75kYA7ckeeJjWVKcsctYlKfJZVWzlRk59JJGtbmPOph9WI CoWjSXreNuQCTK9IWZtSJPyNoNTGqBJZTTY7nwRHsWUp3vl4WVkhNy8nQrIWDQkKSZzgDFLURfDy EtxMM2oLJEy9wNJ2OlOCV0bp8g8rb5pSseZjT1w3JH0jGzm3h+DJmWx+Rx8fJOkhuqkKSPMvxirX +l6pZqepu1rOf7nndnj8JfnqdgPXCU11rel6EldbQ52HNfS4PZpvK+5+MKJWWVAnJ++9IHrOBrvG oN5iet4QLsaqTvM/0QDDLnukSolms2AyjyBcRkG0CP8H4Y7HpG3j6YmFvRcPjqXJ5QZzUXZ6GMfu zHDvya48Phx61y2W1Ee5h6sO5bpPV0aYjoPJZDJ1juz+FfjGVN8N3ZfJcbbv7w80CkD4z8HjOb3/ C374t25lbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMTMwNQplbmRvYmoKMTcgMCBvYmoKPDwvTGVu Z3RoIDE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczZtLc9s2EMfv+hR7SzMT wwT47s1pkk5bJ3VsTS6dHhgKktjwoYCkHR3bT94FKVOrxDOxnMXYUsZyJPGPP/eHx+Lhz+AJCZ59 7l7zanZ6GcOqnUmwT7OahV4i/DQBPxxfgzTwhYI4Su2L0bPlzF4p4fLX3S940eeZHGRh95JX8HKO 0im+IUIv9WG+nI1FSojxX6yEn6Qwr2Y/wfP5P7PX89n72XjtTtd7kG6YijhOBt3f6k6bWncnr0y2 7GD/eKvbNZwX9Sd43XbZx7Jo15Wu6Tfs4/e+1qA8qaw9PxaJ7yuYn6NfgH+fP9s7/oFIpJFQSvkQ KynSIBxsr7tu8/PpaWf6ttNaFLpbisasTssi13WrT4p62XBFzFe+NXBQ/n9Q1KCXS5130NTQrTUs sk5Ds7SlnqhQDZecSCUi6SHCxRCSTY+BzLOuwGuaJV5WtLBo8t5GVgBclDprNVaf60LfWFH8z+3H rRWe5MYI55nRy74sty8ga+33t7DQbW6Kjxq2TW/AFKt110JWL1C07UyR26JbuCm6tX1ng/6RktXq mm/s/NIsNP6oNk1tDYD+0pks7/QClqapDr8OFZLYSRV1XvZ46VVRbcpiWeAFL69eYWUa2ECHOtbv rdWFjSVTXQkk1kEvgiiW+JkcWF3p4a4h4KoQQRyIMDwsREzsA88fPv2ava0jc1tf4VyvshIuTHNd tAMOywdRwsa+tcCAWD5N38FNZkxWd1sM1x34DwJo5e8OuMDY0qY5x9Zs3SJabPy2Zj2bqXBsYztl JhpJKlIZJRAmtgUFQ6AkF4XbboGKY6XFDs00i35ELo5+HvazP3DvoUxElIYH9nzGTjyMPawM/jg4 2AeXcekpEarkoAAp2LBJ7EUD7EWpPIb9Un/uC6OHng7Os3rVZysNj4SMWGNFhsmC56lbZFy2p1ZG 5BV7KyPiGPK5NlVRN2Wz2t4PkmtkxB5bP2+RBSHmd9IZMiLPVtMmZEQcQ/7ntTZDXnE8LjfIiL2Q E5mvxC65dUFsr85WzyZge22MN6YtvSlw7H/TmCrDXvGxee3dRZy4FE6zotQZLyLPVssmYER8yJer yqZyI7An0MKIvZgTmRdjhuuuiRF5tpo2ISPiGPIPWdnrY5uWS2TEXsKILEgDnLvG7rJFWkDEny1S eds34uQ213C2WOAk9jh87MioNVZkiRK+HzlERgrA1sGOjMhj2N/axYQn0sqoNVZkUSpiFTpERgqI BFvGOCEj8jbJLyptVyGeBDJijRVZGAspA4fISAGRYMsZJ2RE3qYg66wsdX3fqbNbZMRayoksCPBt l8hIAZFgyxonZER+WPloN41dF30KrYxYY0XmS5GkDheraAGRYMsaJ2REHsNut0VOymyrDbwxWWUX yXu7j/IoyIg1VmQyFSpRDpGRAiLBNj+ZkBF5m36cv/6K1SO2MmKNFZmHVT+WDpGRAiLBNgxPyIj8 rpXB+z4r7SLIY3eMxBonMh8nD57DHJ/oR4LN+C0woo4xf6e7m8Z8govMtrOjmhgfrnHHnBiTbHNR iyuxN5465EUKwGm0x0csFnF4IC/uAGZ3YXR7j4yfHRgxJtmmopZYlIjEd7ZWReXZhrDbtSoqLoYT Ga3dFOtMVrdV0bbH7XCyIyPuJOc2mR/a+4+dISPybEPYhIyI2wMdpsmRWlGv7H57UedNZX+vRpLt 99oZOzLiTnLuufiBLyIZOUNG5NkGsQkZEUdkZ5vNdESnayDBjlmGIrjvWMaOjLiTnPsuPs4bPC90 hozIMw5jt8MkURdwln+qm5tSL1a78wPHJYvsyOitc65V+dIeNgycISPyfFnThIyoC/jt7N2ZPX/U FgttsvFQ2mMio7fOmt97oYgThwsftADJekxnTBiJvNhvSV/1Rff94cspMXrfnMRU6gsZO1z3oAUg McZ9l4EYlRfTlvR8uzmOFz+xg/tmJZbg25HDZQ9aABJj3HYZiRF5AfPzDw+h5YQYvW9WYlEsUofb ZEQfeTHuuYy89up3zKHvn32w49r7UmwZl6UVhsL3nZ3QofJ8U/+pKhB1MoA9LPVgJ0bMKc51KhUo ESt3yIg839R/QkbUBVzqpTa6zh94SocdGTGnOBeqlO8JKROHnSIpQPrsmSKVx25xOAJXXOvj+bET I8Z4ickY33Z4pooWgMTYM0UijzOyevlQZuzEiDFeYl4gknRapjrru3VjnrUPOkfm6NaJQ8W5qBon OF0Kxlbwhy5bvYVvHq+/bAqMA7zSua4+aoOTrBfDH/d99b2/LuwytPqb2Fvhz/8BLlmYKGVuZHN0 cmVhbQplbmRvYmoKMTggMCBvYmoKMTcyMgplbmRvYmoKODYgMCBvYmoKPDwvTGVuZ3RoIDg3IDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVdNc9s2EL3rV+zkknZGYkTqk72ltdq6 9VccZTqdTg4QCUmoSUIBSDk8tr+8bwGS+rB7aWV7TIoCHnb37b5dfqFhENKQf5trkvfePc5oY3sh 8a/Z9CbDeTCK5zSa+Os4Ho+CiGbTmC9G9tY93hnS40/NDTZ96YUOlppLktP3S0DHeBBMhvGIluue PzKkGf5mUTCax7TMe9/Qt8s/e4tl70PP721wh/8JdxIHs9nc4V4XpTSFLAdXRqxLOvzcSrulG1U8 0cKWYpUpu81lcbyCf36pCknRMIxOzPufbkdhEI8nzrzwYm7PgtFwMjkBD4jgvtFplZRKF3zUYMrL xjMaRJMgiiJgpAg+0XIrKdHFWm0qI3g16TWpIlV7lVYiowyRsnhAAn8pbXVCOUcQoX3W5okS4fDD KJiGQ1B641DXIsuwqdQkaCN2tMJqKQtCxItUmNTCRMdBJmppDo+prHcqweb627cOKJWw4VmV25c2 YUtrhSo2RxjC2iqXVG5FiX+yQWo2GUnVzu01VVFgowvWv3knYMBeJfKtbVAKqTbblTaWclEjcDiH sTZw1PJh7c63WCDzlTR2q/xxu21t2bUGSBZ7ZXThUi/ZimIj+yivL5Uy7IyzvZDPjdWrA0cybQBE VeocjLloBZ5IDyDTM0ZVsdYm9/fgC5+TrEqPA9PwINLUSGthQZ9KIwqbq9LHSiZS7SXlOpW2T8/i Sb6zmZQ7Suokw6PWKKy1mnQR4EGXaT4nPsqkMqqsz42ztBMGflSZMFlNKt9pAy7LfhvSg4EAPUs0 ZqHQJUcItQzSNVk+RwI0eZKlpaooVUbQAPjXoanSymxNW9HyuuLsPMQY8Vx8VbZkLq4Xyx873ilV NtF7aWraGV3qRGeIh62SLXVY1w/7Kd1d0R/4fAnpCMfTYDqd0WQUBY26Pf74w3g+vZiIhPEwmA+n xyd8dlze/Xz1AD8upIHRdBqMZ6MzR6bhaHgpR0Z4Ng2jU0ck5APkN8VBfzX8/E3aOGmMRrHbNOhy y0sjkl7nKNCU/uI4/N0pijKsElZspCtNyzXMOdGkXuqrNnhFF3/bKk5SmCOdFFkWEKtyhdxXpXJ4 XimxxspDjjk2bm8WbaHh69ohiKSsWAFYi3aZZD0Rpv6O13Jp4SN8dl8XCTfE1KspWzhoBcDV/klV 9huNcMLa1C3K3lnfpneXH5VtpURkRoq0HhwKqREwlGVbONjPbu2kcf6i27iInuvrKwLCLrF8IeQ4 MmXQ7qDX24M/tjRqVZXypXicCtFeZJW0nmTHzVawAyIx2gKuVXZIw4M0Az6ksfkUBqbBq0IOtnp3 SJND0DMNxW6VVjo/GeTOow+eVXrekB1iXmWs9ba0jSC7ZLY+g1jeEckGyi31x7ebeMUzmiP3u5eB vces43mAwGNxJ8FnRAkyIlXa+dFHs3yGGZmC7tYvY8tg8OioYTJ1XFBVAZNKtDsNTXYNqRHwVEKj c1V0LQ4rM6w0Lr9XdVvIBZoQWLgVRX1kkO/twtYoWTCecLqizNqYtESgre1hNPIaHKGR1S3BXW9g mKbfpYgHPkH20eNaeW995kwpXgNWrnpJ73baqhJ+gSg3iPkuzcnaYgn0foU+VThS5WbDEUcfy4nX 8WhSchULGGpLR5Jcg8ryJPc7LGe+y99UwyIO6xZGoT2t1ypRLFOgZMBOeydUxv0YWKsWBLm2rrI+ oWBaCl+sf40xl+C6Ktvp5qubaTgaXYBc8bdRDnw5I4N1tndVBzdBMajWz7xNtIIAstlCpKHSqZ92 jvIaDEi0aQw3XQp/gQawmTzHlvZ4+nPx53DyIa6kG/DOD1K8iecCfFtZN1IcUqzVXu3UoBkIGsdp rQzsaUnphjjn7IUGgRl36iiI5mP/DhFcbACYx0EcTucn8IjWo1cZbiqWbkBoBSZdzwznfsNrrxNP aE3QMkzib24/fVy+6fsr3d27+8fFh0/Xj4srvv/48/ubm+7Gr3ilbeLr+083zQ6+O2D9cH97u7i7 8nB4SmePbt//jguqqyHvzf3D8vr+7v3NG1+nSIdUJ5Wbw7nyXTHwq4s0O4O0SHkKxdCboInggyoa nEsNd/HUxy+MYtzE7VAUhWF8seluPAxG0/DkiM+BfyuM+ZsRDSbDYDzm10fQ+KvMLCh88bP4unMt 5wriyK82NBr23Tvy2bo/HpAlNPp8ZP8G//8BKxbGuGVuZHN0cmVhbQplbmRvYmoKODcgMCBvYmoK MTY1MwplbmRvYmoKOTcgMCBvYmoKPDwvTGVuZ3RoIDk4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicrZVdb5swFIbv+RXnbqvUeHyGoF11bTp1H9IWMWlS1QvHHMArmNQ26fLvdwys 342qrSaKCTo8fs/rF3IFPgvAd8c0i9Z7t0qhMl4A7tCVl/gLFmULiJJxjrM4YiGk88xNGr3Sc3cG sPo4ndBNV14wYGGaRAsfckJndIElfhZBXnrjkgGk9ElDFi0yyFvvLRzkv7xl7n33xnsnrv9P3CRj aboYuGfKolZoZyealxZux1c0NXyR6hKWxvJ1I03dorpb4canXiGEfhDek/efbYcBy+JkkBe+Wtsp i/wkuQdnADnqVqqu6aqdW2k2d1VxCrMwYWEYEqIg7wGW+U94OJa/NygsFpBrrkwrjZGdguOuJ5fO X8sPChdbUAbm2ZylTg/pXp0ez5MkeC1rYoquHy7uLXHxHmyNoPp2jXpwJqIwuqpZELJ54Gd/nXlq dCXYu55wa7HdWEMPxlUvNVlmOzCoCuCOfUP88ixxw8UlWui2qIHTL22l6BuuoaGE0j6eYCnVyF2j k37w5nmW7ope2EEl9Xh2soItb3o0UHYa1p2toSCRwpJ0Q+yjfSzUJVUOMqDmBrgaskLs4BAaNIbW oGtT3R6SIxhCbBFqWdXUp+OMwhjddxPI0aRTzVsE4cJGpeM4GsvdihakAamERvfQkjHXktpCLmpQ eE3ei562gbAv8L6lLniF1FoBvRlNLtC6tjVuGr6jS1PNU0qdvw/HmaKNNEjb1kg628GKk9t3M0cO vkzd00Er5FYWpGu9e8R8DmR6IaiLsm/uMZ2NFLmKdKrbXOzhTBmdgvnDGUYE0bWb3kpVDXputtZF bg9rwlBFHAfjfwE58Rkbg7vH1fRCIn2GXBU49Bv5h8PL+UHd+Te3nfEFYaf3R0XffwDBJrCeZW5k c3RyZWFtCmVuZG9iago5OCAwIG9iago2NzEKZW5kb2JqCjEwNSAwIG9iago8PC9MZW5ndGggMTA2 IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVbLcuM2ELzzK+a22SqL0dOyNidv 2ZXaxFvZeLWVQyoHCByK2JCADICSldv6yzMDgtQzKlcS+SE/gEZPT0+DT9BPB9Dnj/guq+T7xyks XTIA/rDLZNK/SUezGxhNmvfxbDxKhzC9nvGbxSRPeOcAHn+MP9Cmp2QQYCG+yQrezwl6Rn9IJ/3Z COZ50hw5gCl9Tofp6GYG8yr5Dt7Ovyb38+TXpNkbcfv/CncyS6fTm4D7QXu0Gn3vzorcw+71EV0B D0r/CffOi0WpXFGh3l/Br59qjTDsD4YH9P5j2cNBOhtPAr3R/1b2NB31J5MD8BTglzXatcINH9O7 5iXjKfSGk3Q4HNL+jIQnKR7uYWXNWmXoQECFQjswOXhLP1TKe6WXULJU0uhcLWsrvDIa1qKs0dEp t5rxB8P0etCndj50qBU6J5YIivBISJO/e/sm6U5v1j2cAsMtL+8VZgW1VlI4D457IxyshPXMDdum MTdBqEenn3uFEjbKF4EMIylZl8KCRrUsFsamDRtC+yeIQ56xPBLNIiABoyX9LD6RLB58IfwFKFrd MFpgB4vZFRjC0CCkxJUXWpJq9gKKxa8oAxkSxdWy2BFIT7W+zcgPXjncs/pO66oufaM2UwfRLiZI bTJ84wLf12n9VItS+S33SVXCk0begPKu09qdofdlldHSQ6CPrcaBUx1WsEtdQaJnhw15HbVgW2r1 vECqrRJb7sCudtI/mu4Mww85yZIpPkyUVMvSeNV4gSzOuqvQQzyIFOqMaFpNh51yjNu46/gsC6GX GKZvY5hLZehf7RS0hmvYU+PKbfRG4L8qsdeOXAeldDvg3khT8hDRnEurFiQf/dMXykWQzMg6MF6h zY2tuOFr1IRIWyhHK6WbYr/lVlRs25rjNe5WmnShrv8V1rycUW8vEpqZCVNdO57hL3ef0gh0G+xG Yint6csFKRbGlBRMMXSA6AEKsnvrp3dx8yNKJNLw2QcrzW1NEuRh2gLqRpVlnC5iLE3Fh2uje/vk Lhkpt6ZqzNjFxmml8xidLY1bKI0kx0ii3HSX+cT9NFgHrC+dLo216FZGZ8ybZorbFyo7w+K9oayL gmWYC/IIb8lF6eIAHMlFUA7DGs+6bQo8M1OdlI2Kjo3bKRls3iZglGpX6RWtzfiI2KyWTDhpl4iH Kas0e7Gbskw5KWxG5s1DVLYTYFE4tmZAyIUqKU55gCh/0NT+qrHMs6hoSl5i9Udt6gbhWIR2fqNv 9q412+iXndbauvm3sF/v4jRM2Ksg+JeIcsK043jBSDzrFlfGegqlCBSvKUUyKKl8uYUgS/vbVRMJ omN4ztwhOJ1vkpiTK1srZ+w2BNIP8boIyUoDnoVHiqZa4nvmru7KtbikzpacN3FEjsoOfz2aPEb4 rCpFFznT3zucUrOkXVaUVGWbhv5Yo29kyTb/Gmuxqc4Zka4e8RIeIMhPkCvrfDRnmMWuV109RJfP oxijlhNCdN0umA+ZhGhaYOfnvKSrvQ1p7vKzP3JRyM/FthtJ1mPST8djfgIkcX9GGq7t6RV4/7yi G8fBHZ1fLcgOo/5VeMw9Wvf7J+7a5A+CjQ+pS/r+N8B6nwhlbmRzdHJlYW0KZW5kb2JqCjEwNiAw IG9iagoxMTk4CmVuZG9iagoxMTIgMCBvYmoKPDwvTGVuZ3RoIDExMyAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nLVXS3PbNhC+61fs+NJ2EqEk+BLbk6OorVsraWP1lPEBIiEJDR8O AdpWx5fkl3cXoGRSTqfTlqY8JE1yv33g2wc+gsd88OjXXbNy8u27BLZ64gP9mu0k8mYsSGcQRO4a pmHAOCRxSpdGTjYTkvTh3Y/dDQp9nPgWFrpLVsKrFUKn+IBFXhrAajNxKn1I8C/hLJilsConX8M3 qz8mi9Xkt4mT7XC9/4QbpSxJZhb3ojKyqaSZvm7ExsDjsZR6B5eq+gALbcS6UHpXyqr/BR0/t5UE 7vl8YN7/dJv7LA0ja144mtsJC7woGoAzgCuZtY0ye/ihbkphNKmbxvRpmMCUR4xzjjg5LgDAW/S1 3oDZSSiFqmDTVplRdaXp6fJyAUqDqUFVyihRqD8lFBi/aSH2siFgn7PY93A9Ly2c7nSjGasdipZS IJTZCePAjJbFBjJRVbVBShV7qKs+4ldPUGoQt7XKrYVZrQ2IKseb8qaQ9+QkminyXFVbECRXV/kJ COhWGfnS6m9kq2VnT+c1KQer/GBzXmct0aLDyaXOGrUmsbv6BFW/RPsl3Cmzg6r3kmwk8BpPB6da TUae57eiymQOiypr9jcUargy+L1ocvD5DN7j52OQLgg584MU4iBgcewS43xxNRb3gthnXhQP4K+R JjCvW0o/F5P5q/l0eT63DOSpZyWmR8o4Bi7rXKLXI+WazxOWRBBzMi+xZs3ny7G89sMYvU0G8Ncg 9JEkOYVgNGd4HLMw4QN1F4vFYuZxPxqtjAQ8ZREyb+AUJsOloHWU90ZW2laEUuzdSmKDIIHTlVRV VrR5x/rTTIFN3WAOdMniPjH7G2kLDSWhZgR+LE+unpxXNm9LqbXYSljLrUJDLASlU4GP9kai5lxl wlCCUdoNVWNCnVQpNMMulK0DHTY6fLFxT7pi10FrOONRdDbIb6WPSY1Ih2zvkDTskBH4OdUlSnCE Okrmwghm/eq0dEBWF0bizDs7eHMoVD1ossZCkdYh6zqcscpHGrt1iALODm11dOb52LQ5oveUXMMn URRY4NE3EI2k5rOmyl9tVFOip+s9XJy/Of8e4yBhrEQLw5QFQdg3BLuoLc6+P5a3ke9Gn56Sz5bz 0zD07ZsnpfGR+sSFlph1K23L6boXtaRNXRT1HXF/4xr+d19IJHe8mNLhzt3x4uTuxdN0cccDoBd4 Pm/v4ScpcszfB6z2ZUn0f4DlxRweOhL+K2V/LzB8+wCYhn2V/ygbJGwWBPxYSx4Np3tVKNHsH6el 7tXTYj5OQoVBzBLOIUhDrLLpM2VUmLoxuK/luiMZn9lXpxPgIZ7QES5z/4+bYBzHfmtXPMM1SQYZ Fo3dyPpK2LBjnfhOpO1tDmyJpd3D1jJiTpPJszX30Ed6ejEOajhB+eFzEWLmsVnsD7QcCOGl9tVp UC7c4N9rduQ3tW4psh1G41ZlEpa/X63slsHQtkFUULdmW1MVQuEv7Aw2jSipjrvp8DAMoKjTg3JH gBuRfZDGarWDvqKJ2Tb9Z2pyHHe4/vjDoh/ZCbyHfoh8SC+eRn4QdhvgN29XNk6i2sMHue/mE40t kQJlp4/1/nEf86n+0qaMhO3A9fm40Xnr5q+dqKywWNfYVxr5sVWNpL0Pbmzw+WEHpLRB/rc2W3Hh sEyqW+H+c20ITfukPzt7aGlP+NPh4AJrhSllR7Ssvum6WG/Lxaj5RNgMA9e4fpGFRq+fHIv7GzRU w2uZyXKNngTeS7tlP/nu/a+U0fH1I1+2eP4LL5g6XWVuZHN0cmVhbQplbmRvYmoKMTEzIDAgb2Jq CjEzMjUKZW5kb2JqCjEyOCAwIG9iago8PC9MZW5ndGggMTI5IDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnicrVZLc9s2EL7zV+wtzcRC+RBEqTclcTJOnEzrqj200wNFLkkkJCgDlB3N 5JL88u6ClEPKqp22WnlAkMS+v/3oa/BFAD7/+mtaez9exVBYLwD+mcKT/lxEizlEsrtOF9NIhBDP Fnwx6OUeawZw9brfkNK1Fziz0F/SGp6vyPSCHgjpLyJY5V7nMoCY/uJQRPMFrGrvB3i6+uCdr7xf vE63t+v/J7tyIeJ47uxe6BaNxnby0iR5C9/kHdoSLpX+COe2TdaVsmWNeniC5c1WI4R+EI7C+59p h4FYTKULT54s7VhEvpQj4wLgRVPXic7gVWPqpGVnkxkfnMYwCaUIw5CsZFR+KsjlOdRobVKghbTR VtkWmhwSuumMtLsNAm8SsGgUHaPX/HBSoS7acsL2g1DMAp+aeums3iTVFmGTmKRG6oQVT594USzm URTuj3TybDKSZ/dX0jww3snnuyxXHOBnevs7rUKI/Z40/6WjgxBHDmCpAVVRtpO1amFLhSo0ZqAI aQUaUBnBSOU7pQtoS+yq1uT/FH0nfeGpY6tSWciadOvQmGGuNBWaDeVNVTW3bLZviB3l1cmXpKro fUY6iSHnDayRu5krU1OQ6x1cLN8vz6iBCKR+CkhPiRr8cA6SuML3Qwe9XzFtVaMhCE4FcOnPhD+f jrx8/ckhehpJ9+oQ0UPxeXHjfoXXW7QtlXpJROb2XCbcswChu+Jz9Cw5Auh7ohkL68Ywsu8CuH82 uAtgmaa4cf7dhvz1YVB/2LM40tbwQNuN4SCT45YexpwTtrOvQp/4rWpLBziLOiNA85DTXWNUoXRS HYnOSW/lkTJEgz58IJBQ8N1m731g5lB3yssyu0HTKos8H6R9oXPitrsu2I6yMrxRKT6x31sGan6L j4Quefltk/HJvV/nLi0TzaRJiHEpfGO77/Fc0py6weTJ1W5ylaYU6KN125iPjwS1YmJQhrqXN1sD X4YQPxsiZnTzcFwDbJ25m0G/vjpaSYmKeMJvsNpRx3I0lMORjvEMdT3oOKjYmsTxwv5DcyQ7Ymy7 1/8DTUPAg7ohp0zlOVfWOppEiy4WKlhq1Nox8MN5nYjvgpkUch5BKKWIotmI72anojuqCBkfOxGO 7QIZuDeTIJ4JSZ98Zru3WFnc3UfX+aeNMoSol5hivaZhjvwz9//Mwbk/f6ZuQPzXIPyC1r8BcfN3 L2VuZHN0cmVhbQplbmRvYmoKMTI5IDAgb2JqCjkwMAplbmRvYmoKMTM3IDAgb2JqCjw8L0xlbmd0 aCAxMzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytV02P2zYQvetXzC0Jaqv6 sC3puEUWRdsN0KZGLkUPtERZbCXSS1K7MdBL8ss7Q1Je22t0k8bUQrSo4ZvHmach9x6SOIWErtDX Q/T9+wK2JkqBLr2NlkkZ51UJ+dL3i2qRxxkUq4o6zaM2opkpvP8x/MBJ91HqYCF09QA/rBG6woF4 mVQ5rNvIu0yhwL8ii/OygvUQvYY367+i23X0W+TnBtzkf+Euq7goSof7k7RcS27nbzVrLTy1d9x0 cCfk33BrLNv0wnQDl8cW1H4eJYcsSbMTet+47CyNq8XS0VtdbdlFnCfL5Ql4DPCB9SM35GS+IoNF AfNsGWdZhrMbDPtkAkxz4LJWDW9gNEJugYHd7/i853Jru/kDmUGr9MDsDB47jva2486G8NMsXqUJ JvPOoTLZgJ/pkBWGcbO36ILVnXtJc4NBK3jfQK2kZUKaozdvXjks1boxz0BIB2RwcWtHguClAtaL rXQZ1Px+FJrTb+NcSRWAdqxpcGUxPh6C4OliS+B5Sy+MZRfGckQ8C4BDTNE6hwUsYQUFlFB9zVgg DfDd/BuvA9I/dFtjxgJv93zns3B4doKAOI6vSiAv4jLPsyk8RyQO7UYCF9vOzjfCwigNJhTFKPAL 3nINW/FAqpw0h6q4GPRn7SCdC2k/WvrXszho9AtIBAn70Hq9H4T8nJY3O22BqptCcG5Js/BBWmTI DDS8FUQWB788NpQJ4nCl6rbI07isUl/d4vRa9a2s4ipdlSfwWAJ+V6OuOdw0jebG17m09JbndQ6r xZk5RuYDfKKbU2PyGToMIgvhD/XIV0IK+4UqZ6ym95rvEA/rjTfucVeZ92yPcmHBEzNBR1a5oBtP xGn4dUjEgIZsy3FVNyQzLkGzRignPd0yNB/YHik+4I+xt2LX8yNXASg4DPVR+DViNxrvvFbDMEpR M6zFTO4nImHaJ24+HxgxSxOlwk7W/di4r+CYKUbFfwi0i/r1Cmt4315RTjnmO0nyIKfs2nI6hseI vcPt70URkdGZdNIXpBOEckFBJ9JxsSV0jPNjJ3CntJRCF98phyHmBwHRU0jZk4CIpq8MbgN0CkI/ llmh5FSMnCe/qeIeGjDMjteiFfUk1OPcSmIQooRP3gEB1kxOGgEz1t1BQrgo0r5nzGXD9StajrHc BcfUHW/GnrvzBNqQfuBR9D3sFN58GTtamZm55RhFr2x3RZllaYHDiyCz/NoyO4an9IiBq9G+qLRg dya27D/Elmcn29YFwYWNbIbpNxbIjNLN8NzkhNoKbWxQUDhw+fTxj6gM3GemjLCPYhgHLy00hA23 jxxrltVMmkFgvVN4lpvU6nI/IwkZjoQbMx0uXI1ifa8evRvNa461T5P+BkXHu7oeNVarHpFCOHyF JQsWUCTt2BulfdUi8RiSCJUjEqYaKDqTiMj1Ko/xtLx0QfmF94bvn2+Otx93eIw08BYpDRuklCcz 97/Amd0fv1ItLP98UuMW7/8C4G19FGVuZHN0cmVhbQplbmRvYmoKMTM4IDAgb2JqCjExMjMKZW5k b2JqCjE0NyAwIG9iago8PC9MZW5ndGggMTQ4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3Ry ZWFtCnicrVdLc9s2EL7zV+wtzTRC+RBfvbW202lrZxpHzSWTA0StSLQiKANQXHV8aX55FyBkUZKV NA1Jj2iDi28X37cP+Q5CFkFob/+s2uC72xxqHURgb1UHaViwpCwgSfvntJwmLIY8K+1DYbAM7M4I bn/yv9CmuyBysOAfVQs/zgi6pAWWhmUCs2XQu4wgp588ZklRwqwNvoHnsz+Cq1nwOuj3etzwf+Gm JcvzwuH+LA0qiWZyqfjSwP66Qd3AtZB/wpU2fL4SumlRDi3s9ctGIsRhFB+E95XHjiNWTlMXXsam Yx28KFkZZcUBPAO4aPhqhbJG62cSFb3RJE5ZHMcEsCDuAWYN7i1hdv0W/rEfs+0aIfkIDdfA4S1f bRCqThoupJA1LSkuF1272k4sehSzLApJz2uHWTWdRgnzrUHQRtkNpuEGhIaNxgWYDhZI6rSCODYU wFKRJhK1hm4JXG6fP3M4CterrbU2DW1t6T2vkfUxK6y6lnRbcCM6qUFIeEfbxlAqKWOWFlPI8oje RY7P25cX07DIxpJsmmQsJxGGLt4DX9vz3gvTOMmSLHVGk0d6F56WmivHYo0SlSPAEmeZrB6l/GA1 I7J+AIn3/V9w8/ubGczxnGSw7BQgr5qjjDAktm6FMbiwgBJEu+6U4VQ0a64M+R4IxrewVp3ByoVF uu2ktmkgSF4bD+VNg/YQEkXdzMmt0B6DV2ZDzi0KaluX7iVt02g9OeHVgrLI54N2CUEW1lVHCTXf pQ/tXgyT9ZicPrNwHwNZ2QVpfaD4QHs9kstezdvdRko2Dreo15R5PUUu0vn2AI+NlI/UOdI8JLkS 3znSsTvHEJ7o3J3ss43jgIJ935h+om8MmsJTaditBUm7VKQWP8zCMdkMc5amuWdztKJ+ZHMAT2za UTOhskAFL5XNoYtuY2fTZ9k9t/GI7fQc20/wa9PTlgWqZxqqjVKuwDam7qw6qzMOXwDKqrM1Z/1I XxSvJnNhYCO1qCW9EmRZW9u201QstCiWouKuLEjypVDa+N6txd/oG5bHOjzfoGmgq0gXGfSRUe3R EBkxG6ZRyeLCJ0M+djIM0On0N9dXX5gEJzuO1C/P1ppl9zQDzqt/4ulI9l5wL9hXyt478ljnZddI UQqzBb0RBseXPkkiFoa7tlqMrf0Q3jcCeE3DjU70n4p/Z3wkefbRDloawPqwnlvkeqOIOlstT0h/ 59HslN8NTz/qdj1XEOZufGkvG5m33BzW60F0fiZqmybLbrXq7vX3ZPd4qN774Arh9IqeWIsJ5egM BygRxJDAFFLIIIcCyk+t+cj317eTL7xPEB4uHuwIhAd4Y1Obnq92XyUuueHAGBvFaxRnLIoix8Gv uNK4PeXq6q+1oC9McEl6tnOqpiR84f5/ObJ79xvJDuX7fRHV9PkvhFOiKGVuZHN0cmVhbQplbmRv YmoKMTQ4IDAgb2JqCjEwNjUKZW5kb2JqCjE1OSAwIG9iago8PC9MZW5ndGggMTYwIDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicvVZNc9s2EL3zV+z4kmYqs/yQLCk9ubaTKrVjx2Y7 0+n0AJErES0JygBoWx1fnF/eXZCivxTGaTuFNKINAg9vd9/u4hICP4SAP+0zLb3vzsewNF4I/NFL bxRM/Hg6gXjUPIfTYexHMN6b8kOjt/B4Zwjn79o/aNOlFzpYaB9pCT8kBD2lCX8UTGNIFl5zZAhj +o4jP55MISm9b+B18od3lHgfvWZvixv8I9zR1B+PJw53pixqhXb3UIuFhftxgiaHY6n+hCNjxbyQ Ji9RPVzB432tEKIgjJhePPYncRxBckx8AQ7g+TioylWBFt/ATrgDcgE2RyjRGLFEkCot6gwNiKJ4 /coLI38vDKYbuG1DoVzm80pLtQRd1WSKgUWl4TqXae6wTVXrFCEXBgoyhmA/h3VZi0LaNWTCCp/s rwsrU2Fs44SP7dvk+BfTA6IqXRL7NaSVskIqejYGk3ELfmdlpb4HAbVy4D1QtqJlK6GJRV0I3dkK 11VdZM9O6kGqFC2zubAdxqvGG53NQmUtbC6usI8UufQAFoVYQrWAnWDHp8XRyI+iKN4E6pwi+HTQ HOorzPwW+0L+hU/XJBwunie3zdeWUKpGH60usnsXMPndl0mkEGvUILJMk8rQDKCUqjYQ+nygNGDq 1arSti+o3WYmVKBa2pwAOEDh3hb7P2xYHpKSWoh9MHhZoyIpEkZnh8a00hmRQkF6bSNJYn6ZabQb 5RW66FktlCmlBUpWUhtHiGDZe2isJN1h1mMhebgqOYmcKjQWUsylU8bd7PD806A5Iu9TxhNp7T7y +xYv7Ss4OT7qcv/ix9Ofjw/hw2nSpU5ZaWTZKhIwPsvCjZJYNZ0/OXdZPuLZcpCuMpAjyBMg+J+i qK7Nm3uTgi1WhVvmoi1z8daIcb2NIIYhjGAPxjCB6dfMddS+3f2Xnw7pdnZ7ent2q9t0hFuYbUJP gab3vKgT8H4TPfB9/z/l8qRRzO5aDp/uHfqgPRhUGbKuzlu9XzQSJ4KWMvjrOgXrwOoaB1y8+ARV 2S3qPL2r7bL6MqVkk3b/A6ezOy2p1dn1FzjhzQpTa7g+1QYdnyavid3LiDEUS6JNTvOIGMA7CoIi SLK7t6qQdlz3bQvRWdM3TvZ/hTkytYxTNcNUZk3J+xxO083ZBCrXuWtTBFBSjeA60TSVJ756rOpm JA+LIR19RbcFpPMLMkevQXNv5uq8sfrFvrLUrpyFXUDJ9Q8uH66Nyb4O0x656Un0parHYHZ3TuKq lZFL5UhbXKL2e6CSiq9P1bXT4kKLlG8comBHNGG4EkVNjiAHcUvtp8V3oFUhaR1ZGEc+N7IV6gXp y8VjANfS5kyWzqFi24PFgSBHhIMHFw3e+ChStCC4iQI+pweqscCtffuWfJLRVYqvC+6KwyY6tTvL RoE/HA5HLoA/YWFw/Rzu6GYlSapwSOWlnFPTioOBu9M+XvbbGfepMPidYNuL+JJ+/wYzlBWDZW5k c3RyZWFtCmVuZG9iagoxNjAgMCBvYmoKMTExMgplbmRvYmoKMTY1IDAgb2JqCjw8L0xlbmd0aCAx NjYgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1Vktz2zYQvvNX7PiSZmqxfEiW 2Js78jRq7TyVzGQ6PUAkSMEhAQUArWiml+SXdxegqGfdtGkhjyiDwLe73z4/QhTGENGne+ZN8MPr MVQmiIE+ugpG0SRMswmkI/8cZsM0TGB8ldFD86AM6GYMr3/ufuClj0HsYKF75A38NEfoDDfCUZSl MC8DLzKGMf6NkzCdZDBvgu/g6fw+uJkHrwJ/t8ON/hXuKAvH44nDnUnLteR2MNWstLBbd9ws4VbI D3BjLFvUwiwbLvdP0PqllRySKE5IvXQcTtI0gfkt6nt+tbI1CMbDp0+CZBQmSZJuj18XhebGHBy/ hho1GNRswzWw7oAqgYHkoloulCYguj1fcpgBkwW8gLJmlQGmObSGF2AVlCwXtbDMcrB40K7VYM02 9JrQSIZBnDgJr+Io2yq04HbNuexFCVmBVi3yZc6pD1IVBM8sFIob/NfCkj1wVJYEQK5kKapWe412 FsCitafCNc+5eEAY5p3wqmVowAZfv4NSq8YL6jHWwi6daaTEE9OR0HFjuCWRF/EFvHn24u3tFHeQ KCbh7vYGGuSUVdxDnJFG+x3QgUyUMoOFsD18dBGSH4TpIRvkmON1dN4CeehQNK/ammlo2tqKnBmL rn/g2grDXYShOQwDxb9C4AOpHQaSaZmQ5BIl6w1eMPi75vB8y8iUWUYsKl2Qt/rU+baUHA1HmO8u c67C7L/KyUkWZvHVZB8dqXyO8af0B3jJNGs4hh2JG8QTf3bQx1/RJ0B/0jnuM33NNysO4y9gVjwX pcCAoih5YHXLfSLtEozgj6Jw1QOaJaPIZblWxmPITr3PDFNytVJmG9j9pW34edF5/xa97gKARH8J vervnEadW0mA5hxQ37owP54mG67oTHWJz+wlZ/bS03xziDGeTmEII7iCMUwg+yd7nbUA3w++8dMj /bHn0dmU/qc15eiu/0Ha8fLSvGPCMPx6iXjyqBUcmuGXq9hTCkKKpl2kYZRgsciXTFa8OFNonflH qhJW4fYXvFRY+LEmWSoOB9CXIORZz5+sRtTY8LB4yMJsi5qgWlyqVg8WG+wjrTSikrz4S/oApVle kdhGYSWj45QGDEucQyiFNhbRn7EHUpU9guRtq1xDsKLBu1jhfBKuu2RG2lZarViFTe4RJEws1VZL bGP7SYxazKwr16w2jn/XOcu+3p5btWhET7LT6iC792qHd8ZjTCG9kmReIjX4M6/bwiGvFRSiLLmm xuAMNX+jVd8J9tzuu+MBlmP0XB/38X64rr3DjHUzwF7vOXSBD+Wvi7Beu67+oVENtjkHgWx4QGEe jQm83QgMQeKsC/QT8k8NfLsqaA7qerTZjgSdVb6dnrQeaiiUCf7yqYk9mqOaKDlxfy8Jo2vX+l1/ 3wYsOkZg8tJUUqgGtfHkbODu+v0uMneTAQ07xs8HbtK6b43toO6VY2a/UWHKKJpF1pjZiL8b0NrV wKpBQQPDPm+jKBwOhyNn4q+8Nvy46uC6+bRCjQ0WpZw3CzQ2jS7dPHx47LeXNA7F8e+7SaTC7z8B 69RL6GVuZHN0cmVhbQplbmRvYmoKMTY2IDAgb2JqCjExNjUKZW5kb2JqCjE3MiAwIG9iago8PC9M ZW5ndGggMTczIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVNNj9owEL37V8yt Xanr5oMQ3BtbUMV2iyiK9lL1YJIJMUsccAKU4+4v33EwYSsuVVvHspP5ePPsN9mCx33w7OP2tGQf 5zEsa+aDfcySRd6Ah2IAYXTae6IX8gDivrCbQZYzm+nD/It7oaQt81tYcFtawl1C0IIMPPJECEnO TiV9iGnGAQ8HApKSvYebZMXGCfvOTrkO1/sr3EjwOB60uBPdoNHY3I6MzBu4jG9YF/Cg9BOM60Yu 1qouStRvI+y432mEwPMDSy+M+SAMA0geiC+A0nllStmoSvObdyyIeBAE4dmbFAgZ5kpjBlNsDpV5 gpk0skQiVIM0+ImSbKRnC30upNa4dibfmmbDKUxGzhK0FjSlauC+UlrppfOE1nOHMq00FTiuK5k5 z/NerndYQ1PBAoH8uTIl0VkcYTKcDl8orLvxf1My6kWdkn3ue/9LTNE/3elbfA7X9wlz3NJJG1v3 9ixE95JknSJXGSTXIzzbJTluEMQLNXfroGsrZEMLkiVVG0XNYeH9gPd9T5xlrlFnbVC6M8b2j3bc Nl2liwo2ziaQscrtlxPKleSWo6qBZm2hSKcM9ypFx6WQe4TVjkivqravZFetMg6K+goqQjYHVSPs tDy0lvyPOBKBSeOAClmDruDROmx7h8Ljohe15/6K6xqPcDXGvzbKENsRplguCDb0PrR/z+9hP2Zy ieAHPy8NuKT1Ff1aMRtlbmRzdHJlYW0KZW5kb2JqCjE3MyAwIG9iago1NDEKZW5kb2JqCjE3OSAw IG9iago8PC9MZW5ndGggMTgwIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVdb c+I2FH7nV5y3dmfA9QXf8sYGp0sXNpSQzu5kMhlhC1BrW8SSk/CY/PIeycbcZzpbDIPBOufTuX5H PINpWGCqV32Ps9ZvEx8WomWBehWLlmsGhhMG4LjVvRt2HcMG3wvVraCteUtpWjD5vf6CSs8tS8NC fYsz+DxF6BAfGK4ZOjCdt6otLfDx7duGE4QwzVq/wqfp361o2vqzVenWuOZP4bqh4fuBxh3kkhY5 lZ1+QeYStteIiiUMWf4PREKSWcrEMqP5roS6/ihzCrZp2Xvm/U+3bcsIu642z7+Y277hmK67B25o LwVZUJAFyUXGhGA8V1t2PCXe9aFju4Zt24iVYBIaBQF3X27vh32YURAqLKVg+QLu+2NY8ULCd3h/ IWmJwFyJEARe5DSB2VqhW7bhWSYmdqgxB71vvQ80Rkc75vmcLcqCSDQFSJ4ASV5oIZmgOv7ZxoDR /d10s/2nXzTQK5NLVIHBGL7wFeJlTAKfg+26baC4SAtlEIEUd+qkPCYplDmLiZC4S1IgdI3EtSAq 7IqSNO3kPMG9329uTPvqyvpQgupxwUuso2bB/qhxsjKVe/hUoKP3q4RIuuNK70cTSCKAzPgLbSvo aqHG0svafMEk3bFpNIxqu462g/f9BNRQs3UddPzdJLhKxm0pF1zlMjuV6bgsMItVslV0VgWPaYIP QaxozOYMV1mOqAcpfsBHl2iP0KuMdQPkGbury7gX3V2qSyzLNSwn3IN/1EX4cKkGt5B8bCSf3S2u r0cX88APDCt0DzzYJoyUbyxlpFhXyWRyDUtKEmwMLDwsobhgsyqHigUs09donSadSZ3OC0Wjyadv 4gZORclRFAWmbbndiwVlE/OdXR6xD7/SNcRLzmIKTAC2sGAJ1WESMV9RRR1yiSsJj0tFPqgyXVId mSBARN8/igwpUT1XTSgxjNjmRDGaYEKKCo7CnKcpf60SUlAKmijFCV5ERQWTayjJF1QR2NVxy565 kAUFLwt0bsttBzuc18RSkCyvSXiPGs9cZwsL1RzfCBzH3uw6XW6p5GSEGuqZ8WS9Fy967MP5in5X WDHPMtXAg77u4+nwL/Fh7NiA8ht+LZFWASsA04dEVqiayLnEXojTMtFN0QwR3UlHmeZFDSUPPDzB s72NlxWvIzbGeIWBoBXHb6m8oM9YH7KNBsZLPR82QbAatK20HqKTjcpmSCY0JWs9fxEaZ33CM5As o7gmXynNwawtVzEa9b4/TaK78e23u+ipHw17P56mg1GkPOJ5Ik44c04De69SqtEHc4zo1lEMcEFj yl50fSvLNnarANY/tkPwIPEFrU8tEhOAKf1MY1IiKo7DbQUlXOdQYbFCV8MqpW+1OXp6Cc2N+qCB ApWwDlZbT1olr0OF9IC0sMRTiLIbN0qwMjcJ37EF0XR9oRC+Z0QJYhNVHu2es9DIeElyJjKNViNh IfS/XI9fPLjQyLRc2wh9G2zPx5Nfdeqd3FyD41jupQjWNh2ja/l7e1xuSNiWZ5h2cOjBRR3w8M+O t+/AY7tKf3WqwfpUxaVKIl+keDybszdMmp6SQaiVD2dBXTWGEnJNo9tV5+6GeMekIBnFU2NNoH06 J9jF+psawyvFvScpu/Nz15a/7yfTA/bWfapW6tPwZL9SG08aiNERhFtDjBoq+g8g1wcgTn0fkTeW ldlhx8S8zDWA7xqe5wU6KF9pKnCQH13R2wpbXmA4Y5rNMM6O2db/1fbFHsaKhC3ncdtvC/z8F1CO 7U5lbmRzdHJlYW0KZW5kb2JqCjE4MCAwIG9iagoxMzE4CmVuZG9iagoxOTEgMCBvYmoKPDwvTGVu Z3RoIDE5MiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJ2SQY/TMBCF7/4V7wYr gYnjtmmuaAsCdiWosifEwU0mjSF2urbDUn49kzQVIG6Mo4yVvPfNjOVHZFIhm9aSayde7Qsco1CY VjiKdbaVutxCry95Va60zFFsyikFEq2YnAr7t8uGTY9CzVgsqXZ4XTG65A9ynZUaVSsuJRUKfopc 6m2JyonnuKm+il0lPomLd+Fm/8Vdl7IotjP3nU8UPKWXt8G0Cb/jnmKHO+u/YReTOfQ2do78n4op 3o+ekGcqn9rThdxqnaO6436BN0MAmbpDCsZHZ2O0g0fqCOZ0CsMpWJMID/sKLLzn9N30I8FGuLFP 9tRbam6eCZXLjcrKK/VwhgEDm8HBj+5AAXU3RPJ4sqnjf6O37RAcGhtTsIcxTVUPlJ6INZkswV7G TiwllQQq7ugCtD/NrG5Nnbgn7sT6uh8bapAGOOstS2gxx7OvuzD4q2lo4ShGc6R4nTglaiTLN9la ar2aR/hAfaQz/ondj5MNbL2lmuapdPZiPtm/ZZ8/cgGo1RfGLtfhyO9f4Re2lGVuZHN0cmVhbQpl bmRvYmoKMTkyIDAgb2JqCjQwNAplbmRvYmoKMTk3IDAgb2JqCjw8L0xlbmd0aCAxOTggMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytVk1z2zYQvfNX7K3JjIUQ/BDJoxtrGrd268Zy Lx4fIBISUZOAAoBy+O+7ACkqktxLK8ljyhD2Yd/b3Qd/g5BQCN17fJZt8OlrBhsTUHBvvQnSMCdx kUOcDs+kSGISQTYv3EPzYB24SApffxk/YNC3gHpYGB9lCz8vEbrABZKGRQzLdTAcSSHDnywicV7A sg0+wMfl38FiGfwZDLEjbvifcNOCZFnucW+l5VpyO7vRbG3h8LrnpoY7IV9hYSxbNcLULZc/7nCv XzvJIQppdJTe/6QdUVIkqU8vvxjtjMRhmh6BE4AHrUpujJAbUGsQslSt+9ziGttw406fzV1kksEs SkkURQhbYT0ArmV/iGicUqWSa7HpNLNCSVAaWLXj2grDvXQj6pX/RjpsGpE5DbHCdx5xQuu2FbMc jIuyCpiHnzWqZA1iVhqBruCtVobD7QN8UVusVCssCPPxJ48klYUI6bash5rtOKw4l7BW+o3pilew 6hFUqw6Lj6lUcP/0uMQ9UAlT+h0EgSa+Q3a3J9ntRQJbM+u4WyYkbv7LgLI1AuO6hN+5fVP6FeFO yD4wzVruEvAhj1/+eLq7cTmIjVT63QyepOFlh9+dV+qdeIDHk93nSUzhTCN5Xup+azHAScI6JCGt KJlb6XyP4ApsXctUiLvX2mx5KdbCnwPPuHiJOaBZTmiRQpqjoTgFsF+vF4+XGgdaZIRSegT/4mk/ X2qSo4SS6JjA58/3lyIQzdGd59kxAZwJYWvwTSJsj92P7SVwZtTK9SZWaK1V64ea5oWPn00NMQy1 qzDrvotGMN0fkGrOKjcqBpvElFqs9tW+kFhxPicRWnKahZjOQOd2sVjkYUTT5FKiJUlB4jg+OuUF 52SJpF9574WJsfHcnlNhjOp0yb2h4IxNgnLhR93p6rXzPtiwHtfGiNGv0PTecbwp7l81f8cGrrEI O4HQ48y3mIr3HobBW7QVNKfJIO7vFngKOg06VOcuO+eC50bAWVmD5GJTr5Qmg7m70NEg8Eovudgh Yd9h7AQSGezNwC2jvzfqbe+A3h7xdmFoHZi36kzTH/DOrGYE2h88KeSRR03P7dpf2IOVIT+8G0RZ T3fBdPBJ2s702I6JBu937v9y98YE6nM7UNtH7VjT8R/81jDHw52KkqP8wuDl52Vq3PxNHusqOXRX 4lX/jTeG93D2WnzfCuwYuEGJ2hUCxOGV/x/jeNvzg5OHpi8Hx93g738AsMmeWmVuZHN0cmVhbQpl bmRvYmoKMTk4IDAgb2JqCjkzMQplbmRvYmoKMjA3IDAgb2JqCjw8L0xlbmd0aCAyMDggMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytVkF32kYQvvMr5pbmPVARGDC5Edvto7WTlPCS Q18PizRCm0i7eHcFJjfnl3dmtcgISA9thW0ZSfPtN998M6tH6Ecx9PkTzknZ+XkxgbXtxMAfs+6M +tfRcHoNw1F9vppeDaMBTMZTPhnsZB2OjGHxa/iHgh47sYeFcEpKeLsk6CldiEb96RCWWadeMoYJ /UwG0fB6Csuy8xO8Xn7p3C07f3Tq2IDb/1e4o2k0mVx73LlyaBS63q0RmYOX4wFtDvdSfYU768Sq kDYvUR0/wcdvlUIY9ONBi95/THsQR9Orkac3/d/SnkTD/mjUAo8AZptNIRPhpFbgNFz3B1E8iq54 1d6YI64m0BuMosFgQHAp1QFgmUsLFhMflKJNjFyhhVzv4OH+DhJdFSmsECqLKUgFQjW4vZWgi4we D6Jx3Kfa3nvMe/35w+xddAJO/yrt6NeURHGL/j7CVhQVLehy4aAUe1BICzn9+pWHopUTXZaV4rz8 DfquMrmuDB5zIWpJUaX4huKaDGs2mgmpNTyPibF03yksBZtr4+A5HodLaWrQWrRRWJeCbsRGrGQh 3R5S4QSs9g67gHaDiRRFsSfKCLe4lQnCcr9Bj7vABCk3A+8VIZ3oQsfnHBXM0wIhk1ikfr1zvnMl Ha0hv9W11BnM7j72bm4eIDOiZEkqdnrDdkaV8zx2ZGxJuZJMeDA6CCjY+XRNkLpyna+0gZ0vrEXi LHxnnNNd4CNVhqpCyog1r6qckMrjU+qZLgq9o2+XNf+oK0OMZrWydONT9xSBV0fzyp5W42F2c1G8 UCUyztyxnYS1VcmmYO+0AItWwWu8NgjHe08L60PpGbA15cMTJDvfCelfrtSDTvGfc7tkoyOXLWWJ unI1hsyOYn2GCszT+yxj23jX1HU+dmlOXkS1Dix2ubYEIL8hh6dILimlojRXtV9pOO60uVBsOg6N 5U13Id15FiCChXKSzlZZJhPJs5Q08/pZdlpJUrAcnAHpKRlSFOfLsjMpbxf8SBgbTZbcSZcHX8Is SXDzQxda6oegBglg4dmHSkfl26kwXL53YUUSB9CFX8N6wXiibQpBRa+LHZBaovq+rmN9LiQm8+oV Yk9F+sU35E3dkPx4dBAqYDVyicJqSvCxkoZtR6lvUbHPkhyTYxHCKDskEXCSA6euJ0Te9fkfSzTz A6jdtI4m0+Va0jBg85p6YpHXeFJXzK0Zqn7sElhmdHk8PDJtzktJ1is5iVRjPelzscV69LSc5dug 68nXa3MpmUpIlIbBj6ywwC+0mbzkpkkr4lK2fcnjIGDxdc8gbD7N3pFe0OQdcbBhx/PF8tORm3OD RupUJlR+mu1OWuS3B3vixXNJqJK65Lvz28Vho8s8Q5SmIWzrnZAKumvtts0mmOSau7qQX5G2nYTK L0nDgOXTw9ZbDfuDtGm6n+ZKQMInaR0T4qiav1RVva9ujN5KMsRRS9Os6O1oTzZYyDDELuj2FhNR 2YulZiYtzQ61I7uZ4zRPhHvZvBovenPyFCXx9geTcE1X2Bi33gZCrk2kb1TmPR5G9NY08ov8joUl nLPj7mlD/WlpY0+wXFFLD/td/07YfuzPD2zAePwXwYY3ujX9/RtYKmS5ZW5kc3RyZWFtCmVuZG9i agoyMDggMCBvYmoKMTIxMgplbmRvYmoKMjE0IDAgb2JqCjw8L0xlbmd0aCAyMTUgMCBSL0ZpbHRl ciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydkM1OwzAQhO9+irlBpeLacdMkR1ArVCioVOGEOLjp 5qckThsHib49ThoEiBu7lseydj7v+gjBJUSXgyYVm2wCZJZJdNlkzBchV1EI5Z91Gk0V9xDMok4a YinrnBKb2+HgTEcmeywGSSrcxA4duQvui0ghTtn5SYnArcDjKowQV+wSo3jPFjF7YmfvwBX/4voR D4Kw5y5NS42h9mre6LTFdzyQzbEqzBsWttXbsrB5ReZnRRd374bgCel17amAh0p5iFeuX+D5sNMt oSJrdUYWlT5hS7Adpa2R5NpkhDan/mioHGN9/YjlfAxtdpO6GV0w6fGZFNEX8kBNVbTY14UpTIa0 1JlFbaDLEqbekeXOM1Nuan/We+6ptHTCn1h8HIrG9TSnhKotNVBi3M/xu+xl7TqHDF4ddvj8zO2f 8yKCaWVuZHN0cmVhbQplbmRvYmoKMjE1IDAgb2JqCjMyMgplbmRvYmoKMjIwIDAgb2JqCjw8L0xl bmd0aCAyMjEgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytUctOwzAQvPsr5kYr UeNHU8dHUCsEFJVWuSEObbpNS5tA4yDg77GTIIi4AbuWx7JmZ3fsIwSXECFbTHN2tjDIHJMIWWYs EjHXNoaOGhzaoeYKZmQDlMQ2LFRKLC7bgy86MlnLooU0x0Xipa2/4JGwGsmGNS0ljF9GcR1bJDnr oZ88sknC5qypbXXFr3Qjy42Ja92roqKyoGowLpebCl9xS26L6a7YY+Kq5eqwc9uciu+MENcvBUEJ qTrj/dG2ktwOo3o8Kf7Ld6z5SArbUefAebovnl4PtM4o2HOh3UCqhjtQEVdKeZ21/wEgmY1nPDBG 0jQiU9a7oYOjd/yIydvzriSHMaWUr6iEFqf1U3Vp93fLjCDjh/7Jp8/M7x8reIrdZW5kc3RyZWFt CmVuZG9iagoyMjEgMCBvYmoKMjkxCmVuZG9iagoyMjcgMCBvYmoKPDwvTGVuZ3RoIDIyOCAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1WWXPaMBB+96/YyUubmaDaMsZ23mignbTk KHHy0umDMQsoNTKRDCn/visfCWePlHa6Zrwasftpj28FD2AzB2zzVDqZWm/6Poy15YB51Njy7IC5 YQCuV+pm2HQZB78VGqXQGlnG04H++2pBTg+WU8BCpZIpvI0IOqQN5tmhC9HIKo90wKePz5kbhBBN rddwHN1b3cj6ZJW+Fa79IlwvZL4fFLjnMkclMW90VDzK4VkuUE+gJ+RX6Oo8HqRCT6YoVy2MfJhL BG47fC28P0ybOyxsekV4jnOovAOXtRw7XENnAOftyzacZVKLIao4F7QyJzYcXpo3uMc45wQ1pCYA RFedq1O47VzDLFO5MX0y6BUGBaDQxIGHOeoch5BngHUJIQaJj7Q1a6S4wJTMxkLnankCSZymZH10 0eueHr+y6gAq2D3tODox8Ekm81hIIAQgd8gG95jkmjCzIc4yIc06lkOCNVh6PmhU5wrUjHY3cogm aLCypCgIZZqKZAmjTAHGyaTIoI7bpDpYwnk3ekd7C4GPp+b77QQWcUr1gFgRtNZiLE1lJiqbjyek cRUBZipLUGswoR2IVB71v8iwIBU7GK3CVlm5VXyi1Q0mcyXyJdzMRY4lpeoib1JqJ2MShXFOpTLN 2ubIBvwRMwdsFPyuLLiK5RhhpLIpxUvA3PNMWV2fBa7La+Pavhr9WAo5hj3SxxEqlAluN7kUu3gH NmeOx5rPtViVaEIZD7Nkblhc8dIIhVfoy2y3327vjWyq1B2qdLNgHAFRxHm6hLms2XdAcjWdkHE/ rMnFD02uVXwi11k2ndI0Q7ScHZ5aa+D/F7FKXpW3YL/M6OfUePJ2VrzbSYKzHc77vfm2t6nSehh7 vd21yM3l/DtnN0vVHi5Q5ULjjt/hH3iX8wS3s6Hp+h75tYFqNcx4/oOB4naTBSGvB8o99ECt4tNA Rb27vzNMT8AvGKQgoJn3/cL4I6Yad1yE3W8zoQiigwlOB6jAtU+Kv2PrZp+vYzrBCb88d2hM7+83 n6gjZW5kc3RyZWFtCmVuZG9iagoyMjggMCBvYmoKNzcyCmVuZG9iagoyMzcgMCBvYmoKPDwvTGVu Z3RoIDIzOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1VUW+bMBB+51ec+rJV ajwwIcBj2mRTujRKM7SXaQ8OXAgrmMY22vLvZwNLsiwUbeuBcoj4++58vu/YgU0csM3V+riw3q18 SKXlgLlEanl2QNwwANdr/DAcuoSCPwqNE2htLIN0YPWhfdCgneXUtNC6uIDbSFOH+gXx7NCFaGM1 IR3w9e1T4gYhRIX1Fq6jb9Y0sh6tBtvy2v/E64XE94Oad8YVCo5qMBFso+BoDyi3MM/4E0ylYus8 k9sC+ekKY/cVR6C2Q016rk8C16UQzXW+tX1meYUtHeMZT6HDVrhBgTzG6zeWQ8nIscMTGtCZ1/ap rESMME4SgVKek0TbTEJSxpVJVBMd0E67pTLBrgReQNP2/6zAsjovQC/abdzdluU58vRyAp3o4a/y yOeSy47sO9Fe48wpDnK2RwHvBSsQ7srKHHsPenREw2PF8kzt/yK237gFqu+leIIlM5EPQfvQQRd6 hbsKpXoZHTbuYT69tOGO2GfdW7euhGBAPQ+YQIgroTtU5XuoOJMySzkmROMOovw/sXsuJa0mHYcM X0vu4YhQSt1TenKhrtLE01ttFh8eoqSuxWy8GIOulmiKjwmoEmKBTCEwkNVaYJpJJfY3EJs2T+Cq jWBoz/R8jHlFDmUWzEhjI8pCZ63JddHJn2cCrz9RtC45x7yDpG+iLMcLmE26UuibKEsURabgvswu baRvotwii0uuy7nPS5b0oS9397C3u2loE1uvMbiPmEu8MAOmP54zPY9hgjEWay0z176pPwq/L/uy ZKn5WHw9iibVvz8BXEm+dGVuZHN0cmVhbQplbmRvYmoKMjM4IDAgb2JqCjYwMgplbmRvYmoKMjQ0 IDAgb2JqCjw8L0xlbmd0aCAyNDUgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyt VcFymzAQvfMVe2szY1PAxjbHJnHatEkndX3L5CDDAqpBIpKI7b/vSkBqJ9NLE2CQRtK+fbtvWR4h 8EMI7N2Pae19Ws2h0F4I9laFFwcLf5IsYBJ34zSZTvwI5rPEDgq93LOWIay+9BMyevRCBwv9kNZw vibohBb8OEgmsM69zmUIc3rmkT9ZJLCuvY9wtv7tLdfeT6+z7XGD/8KNE38+Xzjca2FQCTTjS8Vy A3+vW9Ql3HCxhaU2bFNxXdYojk/Y61srEKIgjE7ovTHsKPSTaezovQB+Q9yLiT8Lg+QE3Qf4hWmr uDnAhRSaZ6iY4TSzXsdh1JmMo9iPoojgMhIC4FpAgYKOVnB7s4SSaTAlgjYKRWFKDUxksEO2Fag1 apC5269sMit2QGXRB/D1jcPUAw9TMgOcHlEiLWjiuCZjSXnGfYqNpQdcd+fI/QfCb3raZx8clsLH lityzFJnIArHiKVuas1FKms7/5w9oTJco5W2420l73FWhIOa1muKgxUEmEsFu5KnpQtIYYqcAFwG hIRGcdrfCrmrMCuIc94DueygoOwSW5uyXLEaIZWtrT6K8BxT1mrsMsX1CHjdVI4UKnLfatMjbciK KczbioKAUu4s9gGsLRfErnZ5ALkxjAvMyJGs7RHab6TWfFMdxs9ZaqwY2XN0xOOK+OOeWeejE0CH 0wqn0pFJD6VL2VYZpcBYgkQmAyOhlhnPD5TUA5WGtGb/pDjgvID3af259ro6sbXwVTYkU01FknMk v5Q1VlWDHBk0LN0iyUZVQupwOuT4pFJYl4T5ovaiOB45jWq253VbQ4UF1fYTq1o8EkfJ1smRYaqc Ns6GyPTsO0oUmiUzcHDyUNQ7prLRa4o9J1eir6FyS83JTyX2ROWheMEFM4OwDATyotxI5b4S+1Vg WgpOZUvBDyUjlZK7weT67mkGPy7hnnbfo19Fk6lrJ3FEf4tZ16tXVxfTxSx8r84VzRM/WExPXDz4 rkNF9BuyW+PpNOx+FdShvmOlKemvruW+cV3hkkSoN/TZToKR692nx+7vqPQgCh+O+Bf0/gMgSfpZ ZW5kc3RyZWFtCmVuZG9iagoyNDUgMCBvYmoKODAxCmVuZG9iagoyNTIgMCBvYmoKPDwvTGVuZ3Ro IDI1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1XS3PiOBC+8yu6cpmdKkdr SX7uLQFmQxJYFtiZw1QOji3AE9sikkmWvWV++bZkQiCkMrWzNhQ2stTqr79+6R5cQsE1n+09LTu/ TkJY6A4F81GLju9GhMcRcL+5e7HHCYMwiM1Nic68Y1ZSmPy+fcBF9x1qxcL2lpZwPkPRMQ4Q3405 zOadZksKIX5DRngUw6zs/AIfZ986/Vnnz06zdivX/Sm5fkzCMLJyB1UtVCXq055K5jW8XEOhl3Cd V3fQ13VyW+R6WYpqf4a5LteVAOZSdqDe/4TNKIk936pHeVu4I04C6sYH0gnARMyFElUqdIsIgjgg IeNbBIS2hQHFMoZy9+UjhpFUZVLnD+IVmlPmN/N3D7MMPQng61l/etMQOMKFskoKGFS6zut1LUDO YVonVZaoTAPeYSbSZSULudg4RixljSVn11bY3nUyXYk0n+epFQpzqaBeCjjLHhLUKYN+larNyr57 3uHjh9dCnlC57ycOfBqMp0Dj0EF8D6K8FQodzaUEV+zgNBp87XaHPwnnw3toJiKVJTp99gLnvJDp HXTz1RLVGcpMaCP/j5VQds5vMFuKY0ion51sRZyt0SZV/Wwko1FXVvM8M4NJkdcbBD8dQ+S6p8ei eNR1YJhsjC28t2wx6Pf7kcuo7928i+7AQP1CpLVClQqrT/NXVnmqkbNFXgmhtHOszMmXXIlCaA1j nGDtfqZEAiNRP0p1pxGIUWdnf8TECPWJ9wYwxBM49vctVJNPXUZpjCyfqySrhEITEQdOrsQGcCtk 1ph2rQXkFeBkDbVEiJmxsnjXDhNxv0YUNrddiwdRGK1xRRupgMWUBLEPXoSJnDc557w7Buq1lRE4 i4nPooMdHGgrlXEP6eLxgXQ0LhgqWkMQM+JH/BWCYaLSJUZ/HBKbyThmbTPrKJOhOp4bBegY/UTX RXInHOihZ0zTZV4Uxk8u8Z9x6imBrsLoNWMnExyRZYWu+35G2/OOxsWmIl2rJkZbchIETSLuged5 +I69OIkbtGbjMCZxyA+2aNFLLIOHAIyXGF7aQuBhe+UaPz9AsO0+XJ+0WLw9GhMWPddu1nbt3hNP TBae/+fijbblnPro8j0lS+3ABD38XK6rrHH2z7L4Bwfw6VqUsnJgho+YoO/yCid3yQ+KuImVIcZK gm3hBkOlt6mSMk/hQuq6qVSLdVPtYKxkLVNZmMg4zuiD8UMAT72LLt6/t5hUA+zLgxB4EGHcBDt3 MzZpLWBwLKD0YA/jboWtu7zJSYzHdtKbOSkK6I1pR1Qttgxgl5aVibpzoG/yU16utCHnyzY9XRCY yiIvk+pHTdZI5IvlLeaiXq5TbI3UxmamwRjwWRte0OyDdo3ueTFmZ88Ymbj7MY44W4vxuDmW7O9h bXHqsci+Od1ZJXttlalY1bsmsSkab/QQAeUu0tItEmwVtrz0RKIKNKMNDUvFJTGD+PpkKG/zwjSw 6P3pu23EtuWBp+HZqD/7Ds8kLaXM9ojaRczT6KI3RoKOw6Ylxige8hjajAUhnnfCHWPGBG0xxlxk jLGDPRw4W6m8MIdC2sQJ5ZGd9VacBL5v4uRzorVYm2I9Rg6u8hI7AJO0cl2bcn1lafpmORltSeqR 98PkHENvKQpT6+W6zqsFnmhNi6vhL41HERMx46ReYp4r0nXR5LO8OqbjWj6ejuUjOpbZ9Vpqvdnv b9tqAnyPhD42ViG+4i9koXlaCy8skzQ+3OO50TIn+G2jxT07a8eaIesKu2JstI+u/t8rbI40cpM2 scddx8o6nPZ1nCywTrObPSgL/P0XrMQADGVuZHN0cmVhbQplbmRvYmoKMjUzIDAgb2JqCjEzNTUK ZW5kb2JqCjI2OSAwIG9iago8PC9MZW5ndGggMjcwIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnicnVFNTwMhEL3zK+amRkU+ZFl6smpj1JrUup6MB7ql3dUuKNBE/73sh1GjJwfCkJl5 j8fMKxBMgbRr8GWDjuYS1gFRaJdfI0FyzFUOXPT+WB1zzEBmqnXeoBVqkRTmF8MlgV4R7WhhcGUD p0WiVimABVEcihXqn6Qg05YM81xB0aBd2Cue0KRAt6jHDrzkX7xCYSnzjvfSRuOtiYfnXq8ifNmN CRVMa/sMkxD1YlOHqjH2e0VrV1trgBHKWnlc4pxzBsUU7Y63sXJ+J8B4ufQmhL0dxARmjPEunaDz uqy0X8K12QTznvKU4YwS9ZmfNAvj4cz5F+d1rJ1NJW2cCSgq1wRnYbbRpRnCpy5EZw/gRoegy2ob TIwBgDBGyVByfzf+LWNWOWtGsE8hoxKUSANmTPwlR9ebEfheNX7uVJ+YViQuXZMAgimcZbID9J+C XzZ5e6lTO+DclB0UODno+vez7GGm16mv/DHRDkNfp/MDHhOdPWVuZHN0cmVhbQplbmRvYmoKMjcw IDAgb2JqCjM3MgplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTQgMCBSCi9Gb250IDE1IDAgUgo+PgovQW5ub3RzWzEwIDAgUgoxMSAw IFIKMTIgMCBSCjEzIDAgUl0vQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA4MyAwIFIKL0ZvbnQgODQg MCBSCj4+Ci9Bbm5vdHNbMTkgMCBSCjIwIDAgUgoyMSAwIFIKMjIgMCBSCjIzIDAgUgoyNCAwIFIK MjUgMCBSCjI2IDAgUgoyNyAwIFIKMjggMCBSCjI5IDAgUgozMCAwIFIKMzEgMCBSCjMyIDAgUgoz MyAwIFIKMzQgMCBSCjM1IDAgUgozNiAwIFIKMzcgMCBSCjM4IDAgUgozOSAwIFIKNDAgMCBSCjQx IDAgUgo0MiAwIFIKNDMgMCBSCjQ0IDAgUgo0NSAwIFIKNDYgMCBSCjQ3IDAgUgo0OCAwIFIKNDkg MCBSCjUwIDAgUgo1MSAwIFIKNTIgMCBSCjUzIDAgUgo1NCAwIFIKNTUgMCBSCjU2IDAgUgo1NyAw IFIKNTggMCBSCjU5IDAgUgo2MCAwIFIKNjEgMCBSCjYyIDAgUgo2MyAwIFIKNjQgMCBSCjY1IDAg Ugo2NiAwIFIKNjcgMCBSCjY4IDAgUgo2OSAwIFIKNzAgMCBSCjcxIDAgUgo3MiAwIFIKNzMgMCBS Cjc0IDAgUgo3NSAwIFIKNzYgMCBSCjc3IDAgUgo3OCAwIFIKNzkgMCBSCjgwIDAgUgo4MSAwIFIK ODIgMCBSXS9Db250ZW50cyAxNyAwIFIKPj4KZW5kb2JqCjg1IDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA5NCAwIFIKL0ZvbnQgOTUgMCBSCj4+Ci9B bm5vdHNbODggMCBSCjg5IDAgUgo5MCAwIFIKOTEgMCBSCjkyIDAgUgo5MyAwIFJdL0NvbnRlbnRz IDg2IDAgUgo+PgplbmRvYmoKOTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDEwMiAwIFIKL0ZvbnQgMTAzIDAgUgo+PgovQW5ub3RzWzk5IDAgUgox MDAgMCBSCjEwMSAwIFJdL0NvbnRlbnRzIDk3IDAgUgo+PgplbmRvYmoKMTA0IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMDkgMCBSCi9Gb250IDEx MCAwIFIKPj4KL0Fubm90c1sxMDcgMCBSCjEwOCAwIFJdL0NvbnRlbnRzIDEwNSAwIFIKPj4KZW5k b2JqCjExMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgMTI1IDAgUgovRm9udCAxMjYgMCBSCj4+Ci9Bbm5vdHNbMTE0IDAgUgoxMTUgMCBSCjExNiAw IFIKMTE3IDAgUgoxMTggMCBSCjExOSAwIFIKMTIwIDAgUgoxMjEgMCBSCjEyMiAwIFIKMTIzIDAg UgoxMjQgMCBSXS9Db250ZW50cyAxMTIgMCBSCj4+CmVuZG9iagoxMjcgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEzNCAwIFIKL0ZvbnQgMTM1IDAg Ugo+PgovQW5ub3RzWzEzMCAwIFIKMTMxIDAgUgoxMzIgMCBSCjEzMyAwIFJdL0NvbnRlbnRzIDEy OCAwIFIKPj4KZW5kb2JqCjEzNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTQ0IDAgUgovRm9udCAxNDUgMCBSCj4+Ci9Bbm5vdHNbMTM5IDAgUgox NDAgMCBSCjE0MSAwIFIKMTQyIDAgUgoxNDMgMCBSXS9Db250ZW50cyAxMzcgMCBSCj4+CmVuZG9i agoxNDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDE1NiAwIFIKL0ZvbnQgMTU3IDAgUgo+PgovQW5ub3RzWzE0OSAwIFIKMTUwIDAgUgoxNTEgMCBS CjE1MiAwIFIKMTUzIDAgUgoxNTQgMCBSCjE1NSAwIFJdL0NvbnRlbnRzIDE0NyAwIFIKPj4KZW5k b2JqCjE1OCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgMTYyIDAgUgovRm9udCAxNjMgMCBSCj4+Ci9Bbm5vdHNbMTYxIDAgUl0vQ29udGVudHMgMTU5 IDAgUgo+PgplbmRvYmoKMTY0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSAxNjkgMCBSCi9Gb250IDE3MCAwIFIKPj4KL0Fubm90c1sxNjcgMCBSCjE2 OCAwIFJdL0NvbnRlbnRzIDE2NSAwIFIKPj4KZW5kb2JqCjE3MSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTc2IDAgUgovRm9udCAxNzcgMCBSCj4+ Ci9Bbm5vdHNbMTc0IDAgUgoxNzUgMCBSXS9Db250ZW50cyAxNzIgMCBSCj4+CmVuZG9iagoxNzgg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE4OCAw IFIKL0ZvbnQgMTg5IDAgUgo+PgovQW5ub3RzWzE4MSAwIFIKMTgyIDAgUgoxODMgMCBSCjE4NCAw IFIKMTg1IDAgUgoxODYgMCBSCjE4NyAwIFJdL0NvbnRlbnRzIDE3OSAwIFIKPj4KZW5kb2JqCjE5 MCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTk0 IDAgUgovRm9udCAxOTUgMCBSCj4+Ci9Bbm5vdHNbMTkzIDAgUl0vQ29udGVudHMgMTkxIDAgUgo+ PgplbmRvYmoKMTk2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4 dEdTdGF0ZSAyMDQgMCBSCi9Gb250IDIwNSAwIFIKPj4KL0Fubm90c1sxOTkgMCBSCjIwMCAwIFIK MjAxIDAgUgoyMDIgMCBSCjIwMyAwIFJdL0NvbnRlbnRzIDE5NyAwIFIKPj4KZW5kb2JqCjIwNiAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjExIDAg UgovRm9udCAyMTIgMCBSCj4+Ci9Bbm5vdHNbMjA5IDAgUgoyMTAgMCBSXS9Db250ZW50cyAyMDcg MCBSCj4+CmVuZG9iagoyMTMgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0 Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0 XQovRXh0R1N0YXRlIDIxNyAwIFIKL0ZvbnQgMjE4IDAgUgo+PgovQW5ub3RzWzIxNiAwIFJdL0Nv bnRlbnRzIDIxNCAwIFIKPj4KZW5kb2JqCjIxOSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjI0IDAgUgovRm9udCAyMjUgMCBSCj4+Ci9Bbm5vdHNb MjIyIDAgUgoyMjMgMCBSXS9Db250ZW50cyAyMjAgMCBSCj4+CmVuZG9iagoyMjYgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIzNCAwIFIKL0ZvbnQg MjM1IDAgUgo+PgovQW5ub3RzWzIyOSAwIFIKMjMwIDAgUgoyMzEgMCBSCjIzMiAwIFIKMjMzIDAg Ul0vQ29udGVudHMgMjI3IDAgUgo+PgplbmRvYmoKMjM2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyNDEgMCBSCi9Gb250IDI0MiAwIFIKPj4KL0Fu bm90c1syMzkgMCBSCjI0MCAwIFJdL0NvbnRlbnRzIDIzNyAwIFIKPj4KZW5kb2JqCjI0MyAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjQ5IDAgUgov Rm9udCAyNTAgMCBSCj4+Ci9Bbm5vdHNbMjQ2IDAgUgoyNDcgMCBSCjI0OCAwIFJdL0NvbnRlbnRz IDI0NCAwIFIKPj4KZW5kb2JqCjI1MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgMjY2IDAgUgovRm9udCAyNjcgMCBSCj4+Ci9Bbm5vdHNbMjU0IDAg UgoyNTUgMCBSCjI1NiAwIFIKMjU3IDAgUgoyNTggMCBSCjI1OSAwIFIKMjYwIDAgUgoyNjEgMCBS CjI2MiAwIFIKMjYzIDAgUgoyNjQgMCBSCjI2NSAwIFJdL0NvbnRlbnRzIDI1MiAwIFIKPj4KZW5k b2JqCjI2OCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgMjcyIDAgUgovRm9udCAyNzMgMCBSCj4+Ci9Bbm5vdHNbMjcxIDAgUl0vQ29udGVudHMgMjY5 IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0IDAgUgoxNiAw IFIKODUgMCBSCjk2IDAgUgoxMDQgMCBSCjExMSAwIFIKMTI3IDAgUgoxMzYgMCBSCjE0NiAwIFIK MTU4IDAgUgoxNjQgMCBSCjE3MSAwIFIKMTc4IDAgUgoxOTAgMCBSCjE5NiAwIFIKMjA2IDAgUgoy MTMgMCBSCjIxOSAwIFIKMjI2IDAgUgoyMzYgMCBSCjI0MyAwIFIKMjUxIDAgUgoyNjggMCBSCl0g L0NvdW50IDIzCj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBS Ci9EZXN0cyA4IDAgUgovTWV0YWRhdGEgMjc1IDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBl L0V4dEdTdGF0ZQovT1BNIDE+PmVuZG9iagoxMCAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFsx NzYuNzU1IDQyOS4yNjQgMjE3LjQ2OCA0NDAuODI1XQovQm9yZGVyIFswIDAgMF0KL0E8PC9VUkko aHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9iY3A3OCkKL1MvVVJJPj4KL1N1YnR5cGUvTGluaz4+ ZW5kb2JqCjExIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzI0Ni4xMTYgNDI5LjI2NCAyODYu ODI5IDQ0MC44MjVdCi9Cb3JkZXIgWzAgMCAwXQovQTw8L1VSSShodHRwOi8vdG9vbHMuaWV0Zi5v cmcvcGRmL2JjcDc5KQovUy9VUkk+PgovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTIgMCBvYmoKPDwv VHlwZS9Bbm5vdAovUmVjdCBbMTcwLjQ0OSAzNjYuMjA5IDQ0NC40NjggMzc3Ljc2OV0KL0JvcmRl ciBbMCAwIDBdCi9BPDwvVVJJKGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8pCi9TL1VSST4+Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxMyAwIG9iago8PC9UeXBlL0Fu bm90Ci9SZWN0IFsyNjUuMDMyIDE4OS42NTQgMzA1Ljc0NiAyMDEuMjE0XQovQm9yZGVyIFswIDAg MF0KL0E8PC9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9iY3A3OCkKL1MvVVJJPj4KL1N1 YnR5cGUvTGluaz4+ZW5kb2JqCjE0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1IDAgb2Jq Cjw8L1I5CjkgMCBSPj4KZW5kb2JqCjE5IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2 IDc2OS43NjIgNzguNzQ1NiA3ODEuMzIyXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMgovU3VidHlw ZS9MaW5rPj5lbmRvYmoKMjAgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbOTQuNzgyMiA3MTku MzE4IDMyNC42NjIgNzMwLjg3OF0KL0JvcmRlciBbMCAwIDBdCi9BPDwvVVJJKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykKL1MvVVJJPj4KL1N1YnR5cGUvTGluaz4+ZW5kb2Jq CjIxIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzQxNi4zNjYgNjY4Ljg3NCA0NzUuOTk2IDY4 MC40MzRdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xMQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjIg MCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbODguNDc2NyA1ODAuNTk3IDk3LjY2MjQgNTkyLjE1 N10KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjIzIDAgb2Jq Cjw8L1R5cGUvQW5ub3QKL1JlY3QgWzUxNy4yNTUgNTgwLjU5NyA1MjYuNDQgNTkyLjE1N10KL0Jv cmRlciBbMCAwIDBdCi9EZXN0LzMKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjI0IDAgb2JqCjw8L1R5 cGUvQW5ub3QKL1JlY3QgWzEwMS4wODggNTY3Ljk4NiAxMjIuODg0IDU3OS41NDZdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdC81Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoyNSAwIG9iago8PC9UeXBlL0Fu bm90Ci9SZWN0IFs1MTcuMjU1IDU2Ny45ODYgNTI2LjQ0IDU3OS41NDZdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdC8zCi9TdWJ0eXBlL0xpbms+PmVuZG9iagoyNiAwIG9iago8PC9UeXBlL0Fubm90Ci9S ZWN0IFs4OC40NzY3IDU1NS4zNzUgOTcuNjYyNCA1NjYuOTM1XQovQm9yZGVyIFswIDAgMF0KL0Rl c3QvNwovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjcgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBb NTE3LjI1NSA1NTUuMzc1IDUyNi40NCA1NjYuOTM1XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNgov U3VidHlwZS9MaW5rPj5lbmRvYmoKMjggMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbODguNDc2 NyA1NDIuNzY0IDk3LjY2MjQgNTU0LjMyNF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzkKL1N1YnR5 cGUvTGluaz4+ZW5kb2JqCjI5IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzUxNy4yNTUgNTQy Ljc2NCA1MjYuNDQgNTU0LjMyNF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzgKL1N1YnR5cGUvTGlu az4+ZW5kb2JqCjMwIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzg4LjQ3NjcgNTMwLjE1MyA5 Ny42NjI0IDU0MS43MTNdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xMQovU3VidHlwZS9MaW5rPj5l bmRvYmoKMzEgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNTE3LjI1NSA1MzAuMTUzIDUyNi40 NCA1NDEuNzEzXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMTAKL1N1YnR5cGUvTGluaz4+ZW5kb2Jq CjMyIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzg4LjQ3NjcgNTE3LjU0MiA5Ny42NjI0IDUy OS4xMDJdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xMwovU3VidHlwZS9MaW5rPj5lbmRvYmoKMzMg MCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNTE3LjI1NSA1MTcuNTQyIDUyNi40NCA1MjkuMTAy XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMTIKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjM0IDAgb2Jq Cjw8L1R5cGUvQW5ub3QKL1JlY3QgWzg4LjQ3NjcgNTA0LjkzMSA5Ny42NjI0IDUxNi40OTFdCi9C b3JkZXIgWzAgMCAwXQovRGVzdC8xNQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMzUgMCBvYmoKPDwv VHlwZS9Bbm5vdAovUmVjdCBbNTE3LjI1NSA1MDQuOTMxIDUyNi40NCA1MTYuNDkxXQovQm9yZGVy IFswIDAgMF0KL0Rlc3QvMTQKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjM2IDAgb2JqCjw8L1R5cGUv QW5ub3QKL1JlY3QgWzEwMS4wODggNDkyLjMyIDEyMi44ODQgNTAzLjg4XQovQm9yZGVyIFswIDAg MF0KL0Rlc3QvMTYKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjM3IDAgb2JqCjw8L1R5cGUvQW5ub3QK L1JlY3QgWzUxNy4yNTUgNDkyLjMyIDUyNi40NCA1MDMuODhdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dC8xNAovU3VidHlwZS9MaW5rPj5lbmRvYmoKMzggMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBb MTAxLjA4OCA0NzkuNzA5IDEyMi44ODQgNDkxLjI2OV0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzE3 Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagozOSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs1MTcu MjU1IDQ3OS43MDkgNTI2LjQ0IDQ5MS4yNjldCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xNAovU3Vi dHlwZS9MaW5rPj5lbmRvYmoKNDAgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMTAxLjA4OCA0 NjcuMDk4IDEyMi44ODQgNDc4LjY1OF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzE4Ci9TdWJ0eXBl L0xpbms+PmVuZG9iago0MSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs1MTcuMjU1IDQ2Ny4w OTggNTI2LjQ0IDQ3OC42NThdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xNAovU3VidHlwZS9MaW5r Pj5lbmRvYmoKNDIgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMTAxLjA4OCA0NTQuNDg3IDEy Mi44ODQgNDY2LjA0N10KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzIwCi9TdWJ0eXBlL0xpbms+PmVu ZG9iago0MyAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs1MTcuMjU1IDQ1NC40ODcgNTI2LjQ0 IDQ2Ni4wNDddCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xOQovU3VidHlwZS9MaW5rPj5lbmRvYmoK NDQgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMTAxLjA4OCA0NDEuODc2IDEyMi44ODQgNDUz LjQzNl0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzIxCi9TdWJ0eXBlL0xpbms+PmVuZG9iago0NSAw IG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs1MTcuMjU1IDQ0MS44NzYgNTI2LjQ0IDQ1My40MzZd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xOQovU3VidHlwZS9MaW5rPj5lbmRvYmoKNDYgMCBvYmoK PDwvVHlwZS9Bbm5vdAovUmVjdCBbMTAxLjA4OCA0MjkuMjY1IDEyMi44ODQgNDQwLjgyNV0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0LzIyCi9TdWJ0eXBlL0xpbms+PmVuZG9iago0NyAwIG9iago8PC9U eXBlL0Fubm90Ci9SZWN0IFs1MTcuMjU1IDQyOS4yNjUgNTI2LjQ0IDQ0MC44MjVdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdC8xOQovU3VidHlwZS9MaW5rPj5lbmRvYmoKNDggMCBvYmoKPDwvVHlwZS9B bm5vdAovUmVjdCBbMTAxLjA4OCA0MTYuNjU0IDEyMi44ODQgNDI4LjIxNV0KL0JvcmRlciBbMCAw IDBdCi9EZXN0LzIzCi9TdWJ0eXBlL0xpbms+PmVuZG9iago0OSAwIG9iago8PC9UeXBlL0Fubm90 Ci9SZWN0IFs1MTcuMjU1IDQxNi42NTQgNTI2LjQ0IDQyOC4yMTVdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdC8xOQovU3VidHlwZS9MaW5rPj5lbmRvYmoKNTAgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVj dCBbMTAxLjA4OCA0MDQuMDQzIDEyMi44ODQgNDE1LjYwNF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0 LzI0Ci9TdWJ0eXBlL0xpbms+PmVuZG9iago1MSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs1 MTcuMjU1IDQwNC4wNDMgNTI2LjQ0IDQxNS42MDRdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xOQov U3VidHlwZS9MaW5rPj5lbmRvYmoKNTIgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMTAxLjA4 OCAzOTEuNDMyIDEyMi44ODQgNDAyLjk5M10KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzI3Ci9TdWJ0 eXBlL0xpbms+PmVuZG9iago1MyAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs1MTAuOTQ5IDM5 MS40MzIgNTI2LjQ0IDQwMi45OTNdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8yNgovU3VidHlwZS9M aW5rPj5lbmRvYmoKNTQgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMTAxLjA4OCAzNzguODIy IDEyOS4xOSAzOTAuMzgyXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMjkKL1N1YnR5cGUvTGluaz4+ ZW5kb2JqCjU1IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzUxMC45NDkgMzc4LjgyMiA1MjYu NDQgMzkwLjM4Ml0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzI4Ci9TdWJ0eXBlL0xpbms+PmVuZG9i ago1NiAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs4OC40NzY3IDM2Ni4yMTEgOTcuNjYyNCAz NzcuNzcxXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMzEKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjU3 IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzUxMC45NDkgMzY2LjIxMSA1MjYuNDQgMzc3Ljc3 MV0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzMwCi9TdWJ0eXBlL0xpbms+PmVuZG9iago1OCAwIG9i ago8PC9UeXBlL0Fubm90Ci9SZWN0IFs4OC40NzY3IDM1My42IDk3LjY2MjQgMzY1LjE2XQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QvMzQKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjU5IDAgb2JqCjw8L1R5 cGUvQW5ub3QKL1JlY3QgWzUxMC45NDkgMzUzLjYgNTI2LjQ0IDM2NS4xNl0KL0JvcmRlciBbMCAw IDBdCi9EZXN0LzMzCi9TdWJ0eXBlL0xpbms+PmVuZG9iago2MCAwIG9iago8PC9UeXBlL0Fubm90 Ci9SZWN0IFs4OC40NzY3IDM0MC45ODkgOTcuNjYyNCAzNTIuNTQ5XQovQm9yZGVyIFswIDAgMF0K L0Rlc3QvMzYKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjYxIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1Jl Y3QgWzUxMC45NDkgMzQwLjk4OSA1MjYuNDQgMzUyLjU0OV0KL0JvcmRlciBbMCAwIDBdCi9EZXN0 LzM1Ci9TdWJ0eXBlL0xpbms+PmVuZG9iago2MiAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs4 OC40NzY3IDMyOC4zNzggMTAzLjk2OCAzMzkuOTM4XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMzkK L1N1YnR5cGUvTGluaz4+ZW5kb2JqCjYzIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzUxMC45 NDkgMzI4LjM3OCA1MjYuNDQgMzM5LjkzOF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzM4Ci9TdWJ0 eXBlL0xpbms+PmVuZG9iago2NCAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs4OC40NzY3IDMx NS43NjcgMTAzLjk2OCAzMjcuMzI3XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNDEKL1N1YnR5cGUv TGluaz4+ZW5kb2JqCjY1IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzUxMC45NDkgMzE1Ljc2 NyA1MjYuNDQgMzI3LjMyN10KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQwCi9TdWJ0eXBlL0xpbms+ PmVuZG9iago2NiAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFsxMDEuMDg4IDMwMy4xNTYgMTI5 LjE5IDMxNC43MTZdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC80MgovU3VidHlwZS9MaW5rPj5lbmRv YmoKNjcgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNTEwLjk0OSAzMDMuMTU2IDUyNi40NCAz MTQuNzE2XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNDAKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjY4 IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzEwMS4wODggMjkwLjU0NSAxMjkuMTkgMzAyLjEw NV0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQzCi9TdWJ0eXBlL0xpbms+PmVuZG9iago2OSAwIG9i ago8PC9UeXBlL0Fubm90Ci9SZWN0IFs1MTAuOTQ5IDI5MC41NDUgNTI2LjQ0IDMwMi4xMDVdCi9C b3JkZXIgWzAgMCAwXQovRGVzdC80MAovU3VidHlwZS9MaW5rPj5lbmRvYmoKNzAgMCBvYmoKPDwv VHlwZS9Bbm5vdAovUmVjdCBbMTAxLjA4OCAyNzcuOTM0IDEyOS4xOSAyODkuNDk0XQovQm9yZGVy IFswIDAgMF0KL0Rlc3QvNDQKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjcxIDAgb2JqCjw8L1R5cGUv QW5ub3QKL1JlY3QgWzUxMC45NDkgMjc3LjkzNCA1MjYuNDQgMjg5LjQ5NF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0LzQwCi9TdWJ0eXBlL0xpbms+PmVuZG9iago3MiAwIG9iago8PC9UeXBlL0Fubm90 Ci9SZWN0IFsxMDEuMDg4IDI2NS4zMjMgMTI5LjE5IDI3Ni44ODNdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdC80NgovU3VidHlwZS9MaW5rPj5lbmRvYmoKNzMgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVj dCBbNTEwLjk0OSAyNjUuMzIzIDUyNi40NCAyNzYuODgzXQovQm9yZGVyIFswIDAgMF0KL0Rlc3Qv NDUKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjc0IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzg4 LjQ3NjcgMjUyLjcxMiAxMDMuOTY4IDI2NC4yNzJdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC80OAov U3VidHlwZS9MaW5rPj5lbmRvYmoKNzUgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNTEwLjk0 OSAyNTIuNzEyIDUyNi40NCAyNjQuMjcyXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNDcKL1N1YnR5 cGUvTGluaz4+ZW5kb2JqCjc2IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzg4LjQ3NjcgMjQw LjEwMSAxMDMuOTY4IDI1MS42NjFdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC81MAovU3VidHlwZS9M aW5rPj5lbmRvYmoKNzcgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNTEwLjk0OSAyNDAuMTAx IDUyNi40NCAyNTEuNjYxXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNDkKL1N1YnR5cGUvTGluaz4+ ZW5kb2JqCjc4IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzEwMS4wODggMjI3LjQ5IDEyOS4x OSAyMzkuMDVdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC81MQovU3VidHlwZS9MaW5rPj5lbmRvYmoK NzkgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNTEwLjk0OSAyMjcuNDkgNTI2LjQ0IDIzOS4w NV0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQ5Ci9TdWJ0eXBlL0xpbms+PmVuZG9iago4MCAwIG9i ago8PC9UeXBlL0Fubm90Ci9SZWN0IFsxMDEuMDg4IDIxNC44NzkgMTI5LjE5IDIyNi40NF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0LzU3Ci9TdWJ0eXBlL0xpbms+PmVuZG9iago4MSAwIG9iago8PC9U eXBlL0Fubm90Ci9SZWN0IFs1MTAuOTQ5IDIxNC44NzkgNTI2LjQ0IDIyNi40NF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0LzQ5Ci9TdWJ0eXBlL0xpbms+PmVuZG9iago4MiAwIG9iago8PC9UeXBlL0Fu bm90Ci9SZWN0IFs1MTAuOTQ5IDIwMi4yNjggNTI2LjQ0IDIxMy44MjldCi9Cb3JkZXIgWzAgMCAw XQovRGVzdC82MgovU3VidHlwZS9MaW5rPj5lbmRvYmoKODMgMCBvYmoKPDwvUjcKNyAwIFI+Pgpl bmRvYmoKODQgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKODggMCBvYmoKPDwvVHlwZS9Bbm5v dAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdC8zCi9TdWJ0eXBlL0xpbms+PmVuZG9iago4OSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0 IFs2OS41NiA3MTkuMzE3IDc4Ljc0NTYgNzMwLjg3OF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQK L1N1YnR5cGUvTGluaz4+ZW5kb2JqCjkwIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzE0NS4y MjcgNTMwLjE1MyAxOTIuMjQ2IDU0MS43MTNdCi9Cb3JkZXIgWzAgMCAwXQovQTw8L1VSSShodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcGRmL3JmYzQ4NjEpCi9TL1VSST4+Ci9TdWJ0eXBlL0xpbms+PmVu ZG9iago5MSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFsyNjUuMDMzIDUzMC4xNTMgMzEyLjA1 MiA1NDEuNzEzXQovQm9yZGVyIFswIDAgMF0KL0E8PC9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3Jn L3BkZi9yZmM2MTMwKQovUy9VUkk+PgovU3VidHlwZS9MaW5rPj5lbmRvYmoKOTIgMCBvYmoKPDwv VHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgMTg5LjY1NiA5MS4zNTY3IDIwMS4yMTZdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdC81Ci9TdWJ0eXBlL0xpbms+PmVuZG9iago5MyAwIG9iago8PC9UeXBlL0Fu bm90Ci9SZWN0IFs5NC43ODIyIDEyNi42MDEgMTQxLjgwMSAxMzguMTYxXQovQm9yZGVyIFswIDAg MF0KL0E8PC9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9yZmMyMTE5KQovUy9VUkk+Pgov U3VidHlwZS9MaW5rPj5lbmRvYmoKOTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKOTUgMCBv YmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKOTkgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjku NTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC82Ci9TdWJ0 eXBlL0xpbms+PmVuZG9iagoxMDAgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNzE5 LjMxNyA3OC43NDU2IDczMC44NzhdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC83Ci9TdWJ0eXBlL0xp bms+PmVuZG9iagoxMDEgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMzk3LjQ0OSA2OTQuMDk1 IDQ0NC40NjggNzA1LjY1Nl0KL0JvcmRlciBbMCAwIDBdCi9BPDwvVVJJKGh0dHA6Ly90b29scy5p ZXRmLm9yZy9wZGYvcmZjNjU1MSkKL1MvVVJJPj4KL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjEwMiAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMDMgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoK MTA3IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDc2OS43NjIgNzguNzQ1NiA3ODEu MzIyXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvOAovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTA4IDAg b2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDcxOS4zMTcgNzguNzQ1NiA3MzAuODc4XQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QvOQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTA5IDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjExMCAwIG9iago8PC9SOQo5IDAgUj4+CmVuZG9iagoxMTQgMCBv YmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJdCi9C b3JkZXIgWzAgMCAwXQovRGVzdC8xMAovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTE1IDAgb2JqCjw8 L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDcxOS4zMTcgNzguNzQ1NiA3MzAuODc4XQovQm9yZGVy IFswIDAgMF0KL0Rlc3QvMTEKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjExNiAwIG9iago8PC9UeXBl L0Fubm90Ci9SZWN0IFszNDAuNjk5IDYzMS4wNDEgMzYyLjQ5NiA2NDIuNjAxXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QvNTIKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjExNyAwIG9iago8PC9UeXBlL0Fu bm90Ci9SZWN0IFsxMjYuMzEgNjE4LjQzIDE0OC4xMDcgNjI5Ljk5XQovQm9yZGVyIFswIDAgMF0K L0Rlc3QvNTMKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjExOCAwIG9iago8PC9UeXBlL0Fubm90Ci9S ZWN0IFsyNjUuMDMyIDYxOC40MyAzMzAuOTY4IDYyOS45OV0KL0JvcmRlciBbMCAwIDBdCi9EZXN0 LzU0Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxMTkgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBb OTQuNzgyMiA1MzAuMTUzIDE2MC43MTggNTQxLjcxM10KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzU0 Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxMjAgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNDQ3 Ljg5MyA1MzAuMTUzIDUxMy44MjkgNTQxLjcxM10KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQxCi9T dWJ0eXBlL0xpbms+PmVuZG9iagoxMjEgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNDM1LjI4 MiAzOTEuNDMyIDUwMS4yMTggNDAyLjk5Ml0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzU0Ci9TdWJ0 eXBlL0xpbms+PmVuZG9iagoxMjIgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMjcxLjMzOCAz NjYuMjA5IDMzMC45NjggMzc3Ljc3XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMTMKL1N1YnR5cGUv TGluaz4+ZW5kb2JqCjEyMyAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs0MTYuMzY2IDM0MC45 ODcgNDgyLjMwMSAzNTIuNTQ3XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNTQKL1N1YnR5cGUvTGlu az4+ZW5kb2JqCjEyNCAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs5NC43ODIyIDI5MC41NDMg MTE2LjU3OSAzMDIuMTAzXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNTMKL1N1YnR5cGUvTGluaz4+ ZW5kb2JqCjEyNSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMjYgMCBvYmoKPDwvUjkKOSAw IFI+PgplbmRvYmoKMTMwIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDc2OS43NjIg NzguNzQ1NiA3ODEuMzIyXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMTIKL1N1YnR5cGUvTGluaz4+ ZW5kb2JqCjEzMSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA3MTkuMzE3IDc4Ljc0 NTYgNzMwLjg3OF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzEzCi9TdWJ0eXBlL0xpbms+PmVuZG9i agoxMzIgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNDQxLjU4OCA1NTUuMzc0IDUwNy41MjQg NTY2LjkzNF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQxCi9TdWJ0eXBlL0xpbms+PmVuZG9iagox MzMgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMTY0LjE0MyAyNTIuNzA5IDIyMy43NzMgMjY0 LjI2OV0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzE1Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxMzQg MCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTM1IDAgb2JqCjw8L1I5CjkgMCBSPj4KZW5kb2Jq CjEzOSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA3NjkuNzYyIDc4Ljc0NTYgNzgx LjMyMl0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzE0Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxNDAg MCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNzE5LjMxNyA3OC43NDU2IDczMC44Nzhd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdC8xNQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTQxIDAgb2Jq Cjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDQyOS4yNjQgOTEuMzU2NyA0NDAuODI0XQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QvMTYKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjE0MiAwIG9iago8PC9U eXBlL0Fubm90Ci9SZWN0IFs2OS41NiAzMjguMzc1IDkxLjM1NjcgMzM5LjkzNl0KL0JvcmRlciBb MCAwIDBdCi9EZXN0LzE3Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxNDMgMCBvYmoKPDwvVHlwZS9B bm5vdAovUmVjdCBbNjkuNTYgMjE0Ljg3NiA5MS4zNTY3IDIyNi40MzZdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdC8xOAovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTQ0IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjE0NSAwIG9iago8PC9SOQo5IDAgUj4+CmVuZG9iagoxNDkgMCBvYmoKPDwvVHlwZS9B bm5vdAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdC8xOQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTUwIDAgb2JqCjw8L1R5cGUvQW5ub3QK L1JlY3QgWzY5LjU2IDcxOS4zMTcgOTEuMzU2NyA3MzAuODc4XQovQm9yZGVyIFswIDAgMF0KL0Rl c3QvMjAKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjE1MSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0 IFszOTEuMTQzIDY2OC44NzMgNDM4LjE2MyA2ODAuNDM0XQovQm9yZGVyIFswIDAgMF0KL0E8PC9V UkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9yZmM0MDg2KQovUy9VUkk+PgovU3VidHlwZS9M aW5rPj5lbmRvYmoKMTUyIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDU2Ny45ODYg OTEuMzU2NyA1NzkuNTQ2XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMjEKL1N1YnR5cGUvTGluaz4+ ZW5kb2JqCjE1MyAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA1MDQuOTMgOTEuMzU2 NyA1MTYuNDldCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC8yMgovU3VidHlwZS9MaW5rPj5lbmRvYmoK MTU0IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDQxNi42NTMgOTEuMzU2NyA0Mjgu MjEzXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvMjMKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjE1NSAw IG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiAzMjguMzc1IDkxLjM1NjcgMzM5LjkzNl0K L0JvcmRlciBbMCAwIDBdCi9EZXN0LzI0Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxNTYgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKMTU3IDAgb2JqCjw8L1I5CjkgMCBSPj4KZW5kb2JqCjE2MSAw IG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA3NjkuNzYyIDc4Ljc0NTYgNzgxLjMyMl0K L0JvcmRlciBbMCAwIDBdCi9EZXN0LzI1Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxNjIgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKMTYzIDAgb2JqCjw8L1I5CjkgMCBSPj4KZW5kb2JqCjE2NyAw IG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA3NjkuNzYyIDc4Ljc0NTYgNzgxLjMyMl0K L0JvcmRlciBbMCAwIDBdCi9EZXN0LzI2Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxNjggMCBvYmoK PDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNTQyLjc2MyA5MS4zNTY3IDU1NC4zMjNdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdC8yNwovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTY5IDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjE3MCAwIG9iago8PC9SOQo5IDAgUj4+CmVuZG9iagoxNzQgMCBvYmoK PDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdC8yOAovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTc1IDAgb2JqCjw8L1R5 cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDU0Mi43NjIgOTcuNjYyMiA1NTQuMzIyXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QvMjkKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjE3NiAwIG9iago8PC9SNwo3IDAg Uj4+CmVuZG9iagoxNzcgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMTgxIDAgb2JqCjw8L1R5 cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDc2OS43NjIgNzguNzQ1NiA3ODEuMzIyXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QvMzAKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjE4MiAwIG9iago8PC9UeXBlL0Fu bm90Ci9SZWN0IFs2OS41NiA3MTkuMzE3IDc4Ljc0NTYgNzMwLjg3OF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0LzMxCi9TdWJ0eXBlL0xpbms+PmVuZG9iagoxODMgMCBvYmoKPDwvVHlwZS9Bbm5vdAov UmVjdCBbOTQuNzgyMiA1ODAuNTk3IDExNi41NzkgNTkyLjE1N10KL0JvcmRlciBbMCAwIDBdCi9E ZXN0LzUyCi9TdWJ0eXBlL0xpbms+PmVuZG9iagoxODQgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVj dCBbMTU3LjgzOCA1ODAuNTk3IDE3OS42MzUgNTkyLjE1N10KL0JvcmRlciBbMCAwIDBdCi9EZXN0 LzUzCi9TdWJ0eXBlL0xpbms+PmVuZG9iagoxODUgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBb OTQuNzgyMiA1NjcuOTg2IDE2MC43MTggNTc5LjU0Nl0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzU0 Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoxODYgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMTUx LjUzMiAyNjUuMzIxIDIwNC44NTcgMjc2Ljg4MV0KL0JvcmRlciBbMCAwIDBdCi9BPDwvVVJJKGh0 dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvcmZjMzMxNSkKL1MvVVJJPj4KL1N1YnR5cGUvTGluaz4+ ZW5kb2JqCjE4NyAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFsyMTQuNTg4IDI2NS4zMjEgMjYx LjYwNyAyNzYuODgxXQovQm9yZGVyIFswIDAgMF0KL0E8PC9VUkkoaHR0cDovL3Rvb2xzLmlldGYu b3JnL3BkZi9yZmMzMzE1KQovUy9VUkk+PgovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTg4IDAgb2Jq Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE4OSAwIG9iago8PC9SOQo5IDAgUj4+CmVuZG9iagoxOTMg MCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdC8zMgovU3VidHlwZS9MaW5rPj5lbmRvYmoKMTk0IDAgb2Jq Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE5NSAwIG9iago8PC9SOQo5IDAgUj4+CmVuZG9iagoxOTkg MCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdC8zMwovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjAwIDAgb2Jq Cjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDcxOS4zMTcgNzguNzQ1NiA3MzAuODc4XQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QvMzQKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjIwMSAwIG9iago8PC9U eXBlL0Fubm90Ci9SZWN0IFsxNzYuNzU1IDU4MC41OTYgMTk4LjU1MSA1OTIuMTU2XQovQm9yZGVy IFswIDAgMF0KL0Rlc3QvNTIKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjIwMiAwIG9iago8PC9UeXBl L0Fubm90Ci9SZWN0IFsyMzkuODEgNTgwLjU5NiAyNjEuNjA3IDU5Mi4xNTZdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdC81MwovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjAzIDAgb2JqCjw8L1R5cGUvQW5u b3QKL1JlY3QgWzM4NC44MzggNTY3Ljk4NSA0NTAuNzczIDU3OS41NDVdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdC81NAovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjA0IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjIwNSAwIG9iago8PC9SOQo5IDAgUj4+CmVuZG9iagoyMDkgMCBvYmoKPDwvVHlwZS9B bm5vdAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43NDU2IDc4MS4zMjJdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdC8zNQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjEwIDAgb2JqCjw8L1R5cGUvQW5ub3QK L1JlY3QgWzY5LjU2IDcxOS4zMTcgNzguNzQ1NiA3MzAuODc4XQovQm9yZGVyIFswIDAgMF0KL0Rl c3QvMzYKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjIxMSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i agoyMTIgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMjE2IDAgb2JqCjw8L1R5cGUvQW5ub3QK L1JlY3QgWzY5LjU2IDc2OS43NjIgNzguNzQ1NiA3ODEuMzIyXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QvMzcKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjIxNyAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i agoyMTggMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMjIyIDAgb2JqCjw8L1R5cGUvQW5ub3QK L1JlY3QgWzY5LjU2IDc2OS43NjIgNzguNzQ1NiA3ODEuMzIyXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QvMzgKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjIyMyAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0 IFs2OS41NiA3MTkuMzE3IDg1LjA1MTEgNzMwLjg3OF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzM5 Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoyMjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjI1 IDAgb2JqCjw8L1I5CjkgMCBSPj4KZW5kb2JqCjIyOSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0 IFs2OS41NiA3NjkuNzYyIDc4Ljc0NTYgNzgxLjMyMl0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQw Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoyMzAgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjku NTYgNzE5LjMxNyA4NS4wNTExIDczMC44NzhdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC80MQovU3Vi dHlwZS9MaW5rPj5lbmRvYmoKMjMxIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDU4 MC41OTYgOTcuNjYyMiA1OTIuMTU2XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNDIKL1N1YnR5cGUv TGluaz4+ZW5kb2JqCjIzMiAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA0MTYuNjUy IDk3LjY2MjIgNDI4LjIxMl0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQzCi9TdWJ0eXBlL0xpbms+ PmVuZG9iagoyMzMgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgMjAyLjI2NSA5Ny42 NjIyIDIxMy44MjVdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC80NAovU3VidHlwZS9MaW5rPj5lbmRv YmoKMjM0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjIzNSAwIG9iago8PC9SOQo5IDAgUj4+ CmVuZG9iagoyMzkgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNzY5Ljc2MiA3OC43 NDU2IDc4MS4zMjJdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC80NQovU3VidHlwZS9MaW5rPj5lbmRv YmoKMjQwIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDUzMC4xNTMgOTcuNjYyMiA1 NDEuNzEzXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNDYKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjI0 MSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNDIgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRv YmoKMjQ2IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzY5LjU2IDc2OS43NjIgNzguNzQ1NiA3 ODEuMzIyXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QvNDcKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjI0 NyAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA3MTkuMzE3IDg1LjA1MTEgNzMwLjg3 OF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzQ4Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoyNDggMCBv YmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbMjMzLjUwNSA1MTcuNTQyIDI4MC41MjMgNTI5LjEwMl0K L0JvcmRlciBbMCAwIDBdCi9BPDwvVVJJKGh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvcmZjNDg2 MSkKL1MvVVJJPj4KL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjI0OSAwIG9iago8PC9SNwo3IDAgUj4+ CmVuZG9iagoyNTAgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMjU0IDAgb2JqCjw8L1R5cGUv QW5ub3QKL1JlY3QgWzY5LjU2IDc2OS43NjIgNzguNzQ1NiA3ODEuMzIyXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QvNDkKL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjI1NSAwIG9iago8PC9UeXBlL0Fubm90 Ci9SZWN0IFs2OS41NiA3MTkuMzE3IDg1LjA1MTEgNzMwLjg3OF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0LzUwCi9TdWJ0eXBlL0xpbms+PmVuZG9iagoyNTYgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVj dCBbNjkuNTYgNjk0LjA5NSA5Ny42NjIyIDcwNS42NTZdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC81 MQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjU3IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzI5 MC4yNTUgNDc5LjcwOCAzMzAuOTY4IDQ5MS4yNjhdCi9Cb3JkZXIgWzAgMCAwXQovQTw8L1VSSSho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL2JjcDE0KQovUy9VUkk+PgovU3VidHlwZS9MaW5rPj5l bmRvYmoKMjU4IDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzM0MC42OTkgNDc5LjcwOCAzOTQu MDIzIDQ5MS4yNjhdCi9Cb3JkZXIgWzAgMCAwXQovQTw8L1VSSShodHRwOi8vdG9vbHMuaWV0Zi5v cmcvcGRmL3JmYzIxMTkpCi9TL1VSST4+Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoyNTkgMCBvYmoK PDwvVHlwZS9Bbm5vdAovUmVjdCBbMzM0LjM5MyA0NDEuODc1IDM4MS40MTMgNDUzLjQzNV0KL0Jv cmRlciBbMCAwIDBdCi9BPDwvVVJJKGh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvYmNwMTA2KQov Uy9VUkk+PgovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjYwIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1Jl Y3QgWzM5MS4xNDQgNDQxLjg3NSA0NDQuNDY4IDQ1My40MzVdCi9Cb3JkZXIgWzAgMCAwXQovQTw8 L1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL3JmYzQwODYpCi9TL1VSST4+Ci9TdWJ0eXBl L0xpbms+PmVuZG9iagoyNjEgMCBvYmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNjkuNTYgNDE2LjY1 MiA5Ny42NjIyIDQyOC4yMTNdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdC81NwovU3VidHlwZS9MaW5r Pj5lbmRvYmoKMjYyIDAgb2JqCjw8L1R5cGUvQW5ub3QKL1JlY3QgWzI1OC43MjcgMzY2LjIwOCAz MTIuMDUxIDM3Ny43NjhdCi9Cb3JkZXIgWzAgMCAwXQovQTw8L1VSSShodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvcGRmL3JmYzMzMTUpCi9TL1VSST4+Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoyNjMgMCBv YmoKPDwvVHlwZS9Bbm5vdAovUmVjdCBbNDQ3Ljg5NCAzMjguMzc1IDUwMS4yMTggMzM5LjkzNV0K L0JvcmRlciBbMCAwIDBdCi9BPDwvVVJJKGh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvcmZjNDg2 MSkKL1MvVVJJPj4KL1N1YnR5cGUvTGluaz4+ZW5kb2JqCjI2NCAwIG9iago8PC9UeXBlL0Fubm90 Ci9SZWN0IFsxNTcuODM4IDI2NS4zMiAyMTEuMTYyIDI3Ni44OF0KL0JvcmRlciBbMCAwIDBdCi9B PDwvVVJJKGh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvcmZjNjEzMCkKL1MvVVJJPj4KL1N1YnR5 cGUvTGluaz4+ZW5kb2JqCjI2NSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFszNTMuMzEgMjE0 Ljg3NiA0MDYuNjM0IDIyNi40MzZdCi9Cb3JkZXIgWzAgMCAwXQovQTw8L1VSSShodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcGRmL3JmYzY1NTEpCi9TL1VSST4+Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagoy NjYgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjY3IDAgb2JqCjw8L1I5CjkgMCBSPj4KZW5k b2JqCjI3MSAwIG9iago8PC9UeXBlL0Fubm90Ci9SZWN0IFs2OS41NiA3NjkuNzYyIDc4Ljc0NTYg NzgxLjMyMl0KL0JvcmRlciBbMCAwIDBdCi9EZXN0LzYyCi9TdWJ0eXBlL0xpbms+PmVuZG9iagoy NzIgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjczIDAgb2JqCjw8L1I5CjkgMCBSPj4KZW5k b2JqCjkgMCBvYmoKPDwvQmFzZUZvbnQvQ291cmllci9UeXBlL0ZvbnQKL0VuY29kaW5nIDI3NCAw IFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoyNzQgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9EaWZm ZXJlbmNlc1sKMTI5L3BhcmVubGVmdC9wYXJlbnJpZ2h0XT4+CmVuZG9iago4IDAgb2JqCjw8LzAg WzQgMCBSIC9YWVogLTQgODQyIG51bGxdCi8xIFs0IDAgUiAvWFlaIC00IDg0MiBudWxsXQovMiBb MTYgMCBSIC9YWVogLTQgNzg1LjAgbnVsbF0KLzMgWzg1IDAgUiAvWFlaIC00IDc4NS4wIG51bGxd Ci80IFs4NSAwIFIgL1hZWiAtNCA3MzQuNTU2IG51bGxdCi81IFs4NSAwIFIgL1hZWiAtNCAyMDQu ODk0NzE0IG51bGxdCi82IFs5NiAwIFIgL1hZWiAtNCA3ODUuMCBudWxsXQovNyBbOTYgMCBSIC9Y WVogLTQgNzM0LjU1NiBudWxsXQovOCBbMTA0IDAgUiAvWFlaIC00IDc4NS4wIG51bGxdCi85IFsx MDQgMCBSIC9YWVogLTQgNzM0LjU1NiBudWxsXQovMTAgWzExMSAwIFIgL1hZWiAtNCA3ODUuMCBu dWxsXQovMTEgWzExMSAwIFIgL1hZWiAtNCA3MzQuNTU2IG51bGxdCi8xMiBbMTI3IDAgUiAvWFla IC00IDc4NS4wIG51bGxdCi8xMyBbMTI3IDAgUiAvWFlaIC00IDczNC41NTYgbnVsbF0KLzE0IFsx MzYgMCBSIC9YWVogLTQgNzg1LjAgbnVsbF0KLzE1IFsxMzYgMCBSIC9YWVogLTQgNzM0LjU1NiBu dWxsXQovMTYgWzEzNiAwIFIgL1hZWiAtNCA0NDQuNTAyMTM2IG51bGxdCi8xNyBbMTM2IDAgUiAv WFlaIC00IDM0My42MTM4MzEgbnVsbF0KLzE4IFsxMzYgMCBSIC9YWVogLTQgMjMwLjExNDYyNCBu dWxsXQovMTkgWzE0NiAwIFIgL1hZWiAtNCA3ODUuMCBudWxsXQovMjAgWzE0NiAwIFIgL1hZWiAt NCA3MzQuNTU2IG51bGxdCi8yMSBbMTQ2IDAgUiAvWFlaIC00IDU4My4yMjQgbnVsbF0KLzIyIFsx NDYgMCBSIC9YWVogLTQgNTIwLjE2ODU3OSBudWxsXQovMjMgWzE0NiAwIFIgL1hZWiAtNCA0MzEu ODkxMjA1IG51bGxdCi8yNCBbMTQ2IDAgUiAvWFlaIC00IDM0My42MTM4MzEgbnVsbF0KLzI1IFsx NTggMCBSIC9YWVogLTQgNzg1LjAgbnVsbF0KLzI2IFsxNjQgMCBSIC9YWVogLTQgNzg1LjAgbnVs bF0KLzI3IFsxNjQgMCBSIC9YWVogLTQgNTU4LjAwMTM0MyBudWxsXQovMjggWzE3MSAwIFIgL1hZ WiAtNCA3ODUuMCBudWxsXQovMjkgWzE3MSAwIFIgL1hZWiAtNCA1NTguMDAwMTgzIG51bGxdCi8z MCBbMTc4IDAgUiAvWFlaIC00IDc4NS4wIG51bGxdCi8zMSBbMTc4IDAgUiAvWFlaIC00IDczNC41 NTYgbnVsbF0KLzMyIFsxOTAgMCBSIC9YWVogLTQgNzg1LjAgbnVsbF0KLzMzIFsxOTYgMCBSIC9Y WVogLTQgNzg1LjAgbnVsbF0KLzM0IFsxOTYgMCBSIC9YWVogLTQgNzM0LjU1NiBudWxsXQovMzUg WzIwNiAwIFIgL1hZWiAtNCA3ODUuMCBudWxsXQovMzYgWzIwNiAwIFIgL1hZWiAtNCA3MzQuNTU2 IG51bGxdCi8zNyBbMjEzIDAgUiAvWFlaIC00IDc4NS4wIG51bGxdCi8zOCBbMjE5IDAgUiAvWFla IC00IDc4NS4wIG51bGxdCi8zOSBbMjE5IDAgUiAvWFlaIC00IDczNC41NTYgbnVsbF0KLzQwIFsy MjYgMCBSIC9YWVogLTQgNzg1LjAgbnVsbF0KLzQxIFsyMjYgMCBSIC9YWVogLTQgNzM0LjU1NiBu dWxsXQovNDIgWzIyNiAwIFIgL1hZWiAtNCA1OTUuODM0MTY3IG51bGxdCi80MyBbMjI2IDAgUiAv WFlaIC00IDQzMS44OTA0MTEgbnVsbF0KLzQ0IFsyMjYgMCBSIC9YWVogLTQgMjE3LjUwMjkzIG51 bGxdCi80NSBbMjM2IDAgUiAvWFlaIC00IDc4NS4wIG51bGxdCi80NiBbMjM2IDAgUiAvWFlaIC00 IDU0NS4zOTEyMzUgbnVsbF0KLzQ3IFsyNDMgMCBSIC9YWVogLTQgNzg1LjAgbnVsbF0KLzQ4IFsy NDMgMCBSIC9YWVogLTQgNzM0LjU1NiBudWxsXQovNDkgWzI1MSAwIFIgL1hZWiAtNCA3ODUuMCBu dWxsXQovNTAgWzI1MSAwIFIgL1hZWiAtNCA3MzQuNTU2IG51bGxdCi81MSBbMjUxIDAgUiAvWFla IC00IDcwOS4zMzM3NCBudWxsXQovNTIgWzI1MSAwIFIgL1hZWiAtNCA2ODQuMTExNTExIG51bGxd Ci81MyBbMjUxIDAgUiAvWFlaIC00IDYzMy42NjczNTggbnVsbF0KLzU0IFsyNTEgMCBSIC9YWVog LTQgNTcwLjYxMjMwNSBudWxsXQovNTUgWzI1MSAwIFIgL1hZWiAtNCA1MDcuNTU3MjIgbnVsbF0K LzU2IFsyNTEgMCBSIC9YWVogLTQgNDY5LjcyNCBudWxsXQovNTcgWzI1MSAwIFIgL1hZWiAtNCA0 MzEuODkwODA4IG51bGxdCi81OCBbMjUxIDAgUiAvWFlaIC00IDQwNi42Njg1NDkgbnVsbF0KLzU5 IFsyNTEgMCBSIC9YWVogLTQgMzU2LjIyNDM5NiBudWxsXQovNjAgWzI1MSAwIFIgL1hZWiAtNCAz MDUuNzgwMjczIG51bGxdCi82MSBbMjUxIDAgUiAvWFlaIC00IDI1NS4zMzYxMjEgbnVsbF0KLzYy IFsyNjggMCBSIC9YWVogLTQgNzg1LjAgbnVsbF0+PmVuZG9iagoyNzUgMCBvYmoKPDwvVHlwZS9N ZXRhZGF0YQovU3VidHlwZS9YTUwvTGVuZ3RoIDE1ODg+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49 J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJz IGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRr PSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJk Zj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9 J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSc5N2IwZDhiOS1mOTZiLTExZWMtMDAwMC0yN2E4MjAwMjEwOGYnIHhtbG5zOnBkZj0naHR0cDov L25zLmFkb2JlLmNvbS9wZGYvMS4zLyc+PHBkZjpQcm9kdWNlcj5HUEwgR2hvc3RzY3JpcHQgOS4w MjwvcGRmOlByb2R1Y2VyPgo8cGRmOktleXdvcmRzPigpPC9wZGY6S2V5d29yZHM+CjwvcmRmOkRl c2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nOTdiMGQ4YjktZjk2Yi0xMWVj LTAwMDAtMjdhODIwMDIxMDhmJyB4bWxuczp4bXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC8nPjx4bXA6TW9kaWZ5RGF0ZT4yMDEyLTA2LTI4VDIwOjI4OjIzKzAyOjAwPC94bXA6TW9kaWZ5 RGF0ZT4KPHhtcDpDcmVhdGVEYXRlPjIwMTItMDYtMjhUMjA6Mjg6MjMrMDI6MDA8L3htcDpDcmVh dGVEYXRlPgo8eG1wOkNyZWF0b3JUb29sPmh0bWwycHMgdmVyc2lvbiAxLjAgYmV0YTc8L3htcDpD cmVhdG9yVG9vbD48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9 Jzk3YjBkOGI5LWY5NmItMTFlYy0wMDAwLTI3YTgyMDAyMTA4ZicgeG1sbnM6eGFwTU09J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9Jzk3YjBkOGI5LWY5 NmItMTFlYy0wMDAwLTI3YTgyMDAyMTA4ZicvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0n OTdiMGQ4YjktZjk2Yi0xMWVjLTAwMDAtMjdhODIwMDIxMDhmJyB4bWxuczpkYz0naHR0cDovL3B1 cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6 dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5kcmFmdC1rZWxzZXkt aW50YXJlYS1tZXNoLWxpbmstZXN0YWJsaXNobWVudC0wNCAtIE1lc2ggTGluayBFc3RhYmxpc2ht ZW50PC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJk ZjpsaT4oKTwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmNyZWF0b3I+PGRjOmRlc2NyaXB0aW9uPjxy ZGY6U2VxPjxyZGY6bGk+KCk8L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpkZXNjcmlwdGlvbj48L3Jk ZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9i ago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOS4wMikKL0NyZWF0aW9uRGF0ZShEOjIwMTIw NjI4MjAyODIzKzAyJzAwJykKL01vZERhdGUoRDoyMDEyMDYyODIwMjgyMyswMicwMCcpCi9DcmVh dG9yKGh0bWwycHMgdmVyc2lvbiAxLjAgYmV0YTcpCi9BdXRob3IoKQovS2V5d29yZHMoKQovU3Vi amVjdCgpCi9UaXRsZShkcmFmdC1rZWxzZXktaW50YXJlYS1tZXNoLWxpbmstZXN0YWJsaXNobWVu dC0wNCAtIE1lc2ggTGluayBFc3RhYmxpc2htZW50KT4+ZW5kb2JqCnhyZWYKMCAyNzYKMDAwMDAw MDAwMCA2NTUzNSBmIAowMDAwMDI5NzE3IDAwMDAwIG4gCjAwMDAwNTI4MzMgMDAwMDAgbiAKMDAw MDAyOTQ4NCAwMDAwMCBuIAowMDAwMDI0MzU3IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAK MDAwMDAwMTM5MCAwMDAwMCBuIAowMDAwMDI5Nzk2IDAwMDAwIG4gCjAwMDAwNDg5NTAgMDAwMDAg biAKMDAwMDA0ODc5NiAwMDAwMCBuIAowMDAwMDI5ODM3IDAwMDAwIG4gCjAwMDAwMjk5ODkgMDAw MDAgbiAKMDAwMDAzMDE0MSAwMDAwMCBuIAowMDAwMDMwMzA1IDAwMDAwIG4gCjAwMDAwMzA0NTcg MDAwMDAgbiAKMDAwMDAzMDQ4NyAwMDAwMCBuIAowMDAwMDI0NTUzIDAwMDAwIG4gCjAwMDAwMDE0 MTAgMDAwMDAgbiAKMDAwMDAwMzIwNCAwMDAwMCBuIAowMDAwMDMwNTE3IDAwMDAwIG4gCjAwMDAw MzA2MjQgMDAwMDAgbiAKMDAwMDAzMDc4MSAwMDAwMCBuIAowMDAwMDMwODkxIDAwMDAwIG4gCjAw MDAwMzEwMDAgMDAwMDAgbiAKMDAwMDAzMTEwOCAwMDAwMCBuIAowMDAwMDMxMjE3IDAwMDAwIG4g CjAwMDAwMzEzMjUgMDAwMDAgbiAKMDAwMDAzMTQzNCAwMDAwMCBuIAowMDAwMDMxNTQyIDAwMDAw IG4gCjAwMDAwMzE2NTEgMDAwMDAgbiAKMDAwMDAzMTc1OSAwMDAwMCBuIAowMDAwMDMxODY5IDAw MDAwIG4gCjAwMDAwMzE5NzggMDAwMDAgbiAKMDAwMDAzMjA4OCAwMDAwMCBuIAowMDAwMDMyMTk3 IDAwMDAwIG4gCjAwMDAwMzIzMDcgMDAwMDAgbiAKMDAwMDAzMjQxNiAwMDAwMCBuIAowMDAwMDMy NTI0IDAwMDAwIG4gCjAwMDAwMzI2MzEgMDAwMDAgbiAKMDAwMDAzMjc0MSAwMDAwMCBuIAowMDAw MDMyODUwIDAwMDAwIG4gCjAwMDAwMzI5NjAgMDAwMDAgbiAKMDAwMDAzMzA2OSAwMDAwMCBuIAow MDAwMDMzMTc5IDAwMDAwIG4gCjAwMDAwMzMyODggMDAwMDAgbiAKMDAwMDAzMzM5OCAwMDAwMCBu IAowMDAwMDMzNTA3IDAwMDAwIG4gCjAwMDAwMzM2MTcgMDAwMDAgbiAKMDAwMDAzMzcyNiAwMDAw MCBuIAowMDAwMDMzODM2IDAwMDAwIG4gCjAwMDAwMzM5NDUgMDAwMDAgbiAKMDAwMDAzNDA1NSAw MDAwMCBuIAowMDAwMDM0MTY0IDAwMDAwIG4gCjAwMDAwMzQyNzQgMDAwMDAgbiAKMDAwMDAzNDM4 MyAwMDAwMCBuIAowMDAwMDM0NDkyIDAwMDAwIG4gCjAwMDAwMzQ2MDEgMDAwMDAgbiAKMDAwMDAz NDcxMSAwMDAwMCBuIAowMDAwMDM0ODIwIDAwMDAwIG4gCjAwMDAwMzQ5MjcgMDAwMDAgbiAKMDAw MDAzNTAzMyAwMDAwMCBuIAowMDAwMDM1MTQzIDAwMDAwIG4gCjAwMDAwMzUyNTIgMDAwMDAgbiAK MDAwMDAzNTM2MiAwMDAwMCBuIAowMDAwMDM1NDcxIDAwMDAwIG4gCjAwMDAwMzU1ODEgMDAwMDAg biAKMDAwMDAzNTY5MCAwMDAwMCBuIAowMDAwMDM1Nzk5IDAwMDAwIG4gCjAwMDAwMzU5MDggMDAw MDAgbiAKMDAwMDAzNjAxNyAwMDAwMCBuIAowMDAwMDM2MTI2IDAwMDAwIG4gCjAwMDAwMzYyMzUg MDAwMDAgbiAKMDAwMDAzNjM0NCAwMDAwMCBuIAowMDAwMDM2NDUzIDAwMDAwIG4gCjAwMDAwMzY1 NjIgMDAwMDAgbiAKMDAwMDAzNjY3MiAwMDAwMCBuIAowMDAwMDM2NzgxIDAwMDAwIG4gCjAwMDAw MzY4OTEgMDAwMDAgbiAKMDAwMDAzNzAwMCAwMDAwMCBuIAowMDAwMDM3MTA3IDAwMDAwIG4gCjAw MDAwMzcyMTQgMDAwMDAgbiAKMDAwMDAzNzMyMiAwMDAwMCBuIAowMDAwMDM3NDMwIDAwMDAwIG4g CjAwMDAwMzc1MzkgMDAwMDAgbiAKMDAwMDAzNzU2OSAwMDAwMCBuIAowMDAwMDI1MTcxIDAwMDAw IG4gCjAwMDAwMDMyMjUgMDAwMDAgbiAKMDAwMDAwNDk1MCAwMDAwMCBuIAowMDAwMDM3NTk5IDAw MDAwIG4gCjAwMDAwMzc3MDYgMDAwMDAgbiAKMDAwMDAzNzgxMyAwMDAwMCBuIAowMDAwMDM3OTY3 IDAwMDAwIG4gCjAwMDAwMzgxMjEgMDAwMDAgbiAKMDAwMDAzODIyOCAwMDAwMCBuIAowMDAwMDM4 MzgyIDAwMDAwIG4gCjAwMDAwMzg0MTIgMDAwMDAgbiAKMDAwMDAyNTM4MyAwMDAwMCBuIAowMDAw MDA0OTcxIDAwMDAwIG4gCjAwMDAwMDU3MTQgMDAwMDAgbiAKMDAwMDAzODQ0MiAwMDAwMCBuIAow MDAwMDM4NTQ5IDAwMDAwIG4gCjAwMDAwMzg2NTcgMDAwMDAgbiAKMDAwMDAzODgxMiAwMDAwMCBu IAowMDAwMDM4ODQzIDAwMDAwIG4gCjAwMDAwMjU1NzggMDAwMDAgbiAKMDAwMDAwNTczNCAwMDAw MCBuIAowMDAwMDA3MDA2IDAwMDAwIG4gCjAwMDAwMzg4NzQgMDAwMDAgbiAKMDAwMDAzODk4MiAw MDAwMCBuIAowMDAwMDM5MDkwIDAwMDAwIG4gCjAwMDAwMzkxMjEgMDAwMDAgbiAKMDAwMDAyNTc2 OCAwMDAwMCBuIAowMDAwMDA3MDI4IDAwMDAwIG4gCjAwMDAwMDg0MjcgMDAwMDAgbiAKMDAwMDAz OTE1MiAwMDAwMCBuIAowMDAwMDM5MjYxIDAwMDAwIG4gCjAwMDAwMzkzNzAgMDAwMDAgbiAKMDAw MDAzOTQ4MSAwMDAwMCBuIAowMDAwMDM5NTg5IDAwMDAwIG4gCjAwMDAwMzk2OTggMDAwMDAgbiAK MDAwMDAzOTgwOSAwMDAwMCBuIAowMDAwMDM5OTIwIDAwMDAwIG4gCjAwMDAwNDAwMzEgMDAwMDAg biAKMDAwMDA0MDE0MSAwMDAwMCBuIAowMDAwMDQwMjUyIDAwMDAwIG4gCjAwMDAwNDAzNjMgMDAw MDAgbiAKMDAwMDA0MDM5NCAwMDAwMCBuIAowMDAwMDI2MDMwIDAwMDAwIG4gCjAwMDAwMDg0NDkg MDAwMDAgbiAKMDAwMDAwOTQyMyAwMDAwMCBuIAowMDAwMDQwNDI1IDAwMDAwIG4gCjAwMDAwNDA1 MzQgMDAwMDAgbiAKMDAwMDA0MDY0MyAwMDAwMCBuIAowMDAwMDQwNzU0IDAwMDAwIG4gCjAwMDAw NDA4NjUgMDAwMDAgbiAKMDAwMDA0MDg5NiAwMDAwMCBuIAowMDAwMDI2MjM2IDAwMDAwIG4gCjAw MDAwMDk0NDQgMDAwMDAgbiAKMDAwMDAxMDY0MSAwMDAwMCBuIAowMDAwMDQwOTI3IDAwMDAwIG4g CjAwMDAwNDEwMzYgMDAwMDAgbiAKMDAwMDA0MTE0NSAwMDAwMCBuIAowMDAwMDQxMjU0IDAwMDAw IG4gCjAwMDAwNDEzNjMgMDAwMDAgbiAKMDAwMDA0MTQ3MiAwMDAwMCBuIAowMDAwMDQxNTAzIDAw MDAwIG4gCjAwMDAwMjY0NTAgMDAwMDAgbiAKMDAwMDAxMDY2MyAwMDAwMCBuIAowMDAwMDExODAy IDAwMDAwIG4gCjAwMDAwNDE1MzQgMDAwMDAgbiAKMDAwMDA0MTY0MyAwMDAwMCBuIAowMDAwMDQx NzUyIDAwMDAwIG4gCjAwMDAwNDE5MDcgMDAwMDAgbiAKMDAwMDA0MjAxNiAwMDAwMCBuIAowMDAw MDQyMTIzIDAwMDAwIG4gCjAwMDAwNDIyMzIgMDAwMDAgbiAKMDAwMDA0MjM0MSAwMDAwMCBuIAow MDAwMDQyMzcyIDAwMDAwIG4gCjAwMDAwMjY2ODAgMDAwMDAgbiAKMDAwMDAxMTgyNCAwMDAwMCBu IAowMDAwMDEzMDEwIDAwMDAwIG4gCjAwMDAwNDI0MDMgMDAwMDAgbiAKMDAwMDA0MjUxMiAwMDAw MCBuIAowMDAwMDQyNTQzIDAwMDAwIG4gCjAwMDAwMjY4NjIgMDAwMDAgbiAKMDAwMDAxMzAzMiAw MDAwMCBuIAowMDAwMDE0MjcxIDAwMDAwIG4gCjAwMDAwNDI1NzQgMDAwMDAgbiAKMDAwMDA0MjY4 MyAwMDAwMCBuIAowMDAwMDQyNzkyIDAwMDAwIG4gCjAwMDAwNDI4MjMgMDAwMDAgbiAKMDAwMDAy NzA1MiAwMDAwMCBuIAowMDAwMDE0MjkzIDAwMDAwIG4gCjAwMDAwMTQ5MDggMDAwMDAgbiAKMDAw MDA0Mjg1NCAwMDAwMCBuIAowMDAwMDQyOTYzIDAwMDAwIG4gCjAwMDAwNDMwNzIgMDAwMDAgbiAK MDAwMDA0MzEwMyAwMDAwMCBuIAowMDAwMDI3MjQyIDAwMDAwIG4gCjAwMDAwMTQ5MjkgMDAwMDAg biAKMDAwMDAxNjMyMSAwMDAwMCBuIAowMDAwMDQzMTM0IDAwMDAwIG4gCjAwMDAwNDMyNDMgMDAw MDAgbiAKMDAwMDA0MzM1MiAwMDAwMCBuIAowMDAwMDQzNDYzIDAwMDAwIG4gCjAwMDAwNDM1NzQg MDAwMDAgbiAKMDAwMDA0MzY4NSAwMDAwMCBuIAowMDAwMDQzODQwIDAwMDAwIG4gCjAwMDAwNDM5 OTUgMDAwMDAgbiAKMDAwMDA0NDAyNiAwMDAwMCBuIAowMDAwMDI3NDcyIDAwMDAwIG4gCjAwMDAw MTYzNDMgMDAwMDAgbiAKMDAwMDAxNjgyMSAwMDAwMCBuIAowMDAwMDQ0MDU3IDAwMDAwIG4gCjAw MDAwNDQxNjYgMDAwMDAgbiAKMDAwMDA0NDE5NyAwMDAwMCBuIAowMDAwMDI3NjU0IDAwMDAwIG4g CjAwMDAwMTY4NDIgMDAwMDAgbiAKMDAwMDAxNzg0NyAwMDAwMCBuIAowMDAwMDQ0MjI4IDAwMDAw IG4gCjAwMDAwNDQzMzcgMDAwMDAgbiAKMDAwMDA0NDQ0NiAwMDAwMCBuIAowMDAwMDQ0NTU3IDAw MDAwIG4gCjAwMDAwNDQ2NjcgMDAwMDAgbiAKMDAwMDA0NDc3OCAwMDAwMCBuIAowMDAwMDQ0ODA5 IDAwMDAwIG4gCjAwMDAwMjc4NjggMDAwMDAgbiAKMDAwMDAxNzg2OCAwMDAwMCBuIAowMDAwMDE5 MTU0IDAwMDAwIG4gCjAwMDAwNDQ4NDAgMDAwMDAgbiAKMDAwMDA0NDk0OSAwMDAwMCBuIAowMDAw MDQ1MDU4IDAwMDAwIG4gCjAwMDAwNDUwODkgMDAwMDAgbiAKMDAwMDAyODA1OCAwMDAwMCBuIAow MDAwMDE5MTc2IDAwMDAwIG4gCjAwMDAwMTk1NzIgMDAwMDAgbiAKMDAwMDA0NTEyMCAwMDAwMCBu IAowMDAwMDQ1MjI5IDAwMDAwIG4gCjAwMDAwNDUyNjAgMDAwMDAgbiAKMDAwMDAyODI0MCAwMDAw MCBuIAowMDAwMDE5NTkzIDAwMDAwIG4gCjAwMDAwMTk5NTggMDAwMDAgbiAKMDAwMDA0NTI5MSAw MDAwMCBuIAowMDAwMDQ1NDAwIDAwMDAwIG4gCjAwMDAwNDU1MDkgMDAwMDAgbiAKMDAwMDA0NTU0 MCAwMDAwMCBuIAowMDAwMDI4NDMwIDAwMDAwIG4gCjAwMDAwMTk5NzkgMDAwMDAgbiAKMDAwMDAy MDgyNSAwMDAwMCBuIAowMDAwMDQ1NTcxIDAwMDAwIG4gCjAwMDAwNDU2ODAgMDAwMDAgbiAKMDAw MDA0NTc4OSAwMDAwMCBuIAowMDAwMDQ1ODk4IDAwMDAwIG4gCjAwMDAwNDYwMDcgMDAwMDAgbiAK MDAwMDA0NjExNiAwMDAwMCBuIAowMDAwMDQ2MTQ3IDAwMDAwIG4gCjAwMDAwMjg2NDQgMDAwMDAg biAKMDAwMDAyMDg0NiAwMDAwMCBuIAowMDAwMDIxNTIyIDAwMDAwIG4gCjAwMDAwNDYxNzggMDAw MDAgbiAKMDAwMDA0NjI4NyAwMDAwMCBuIAowMDAwMDQ2Mzk2IDAwMDAwIG4gCjAwMDAwNDY0Mjcg MDAwMDAgbiAKMDAwMDAyODgzNCAwMDAwMCBuIAowMDAwMDIxNTQzIDAwMDAwIG4gCjAwMDAwMjI0 MTggMDAwMDAgbiAKMDAwMDA0NjQ1OCAwMDAwMCBuIAowMDAwMDQ2NTY3IDAwMDAwIG4gCjAwMDAw NDY2NzYgMDAwMDAgbiAKMDAwMDA0NjgzMSAwMDAwMCBuIAowMDAwMDQ2ODYyIDAwMDAwIG4gCjAw MDAwMjkwMzIgMDAwMDAgbiAKMDAwMDAyMjQzOSAwMDAwMCBuIAowMDAwMDIzODY4IDAwMDAwIG4g CjAwMDAwNDY4OTMgMDAwMDAgbiAKMDAwMDA0NzAwMiAwMDAwMCBuIAowMDAwMDQ3MTExIDAwMDAw IG4gCjAwMDAwNDcyMjAgMDAwMDAgbiAKMDAwMDA0NzM3MyAwMDAwMCBuIAowMDAwMDQ3NTI4IDAw MDAwIG4gCjAwMDAwNDc2ODIgMDAwMDAgbiAKMDAwMDA0NzgzNyAwMDAwMCBuIAowMDAwMDQ3OTQ2 IDAwMDAwIG4gCjAwMDAwNDgxMDEgMDAwMDAgbiAKMDAwMDA0ODI1NiAwMDAwMCBuIAowMDAwMDQ4 NDA5IDAwMDAwIG4gCjAwMDAwNDg1NjMgMDAwMDAgbiAKMDAwMDA0ODU5NCAwMDAwMCBuIAowMDAw MDI5MzAyIDAwMDAwIG4gCjAwMDAwMjM4OTAgMDAwMDAgbiAKMDAwMDAyNDMzNiAwMDAwMCBuIAow MDAwMDQ4NjI1IDAwMDAwIG4gCjAwMDAwNDg3MzQgMDAwMDAgbiAKMDAwMDA0ODc2NSAwMDAwMCBu IAowMDAwMDQ4ODc1IDAwMDAwIG4gCjAwMDAwNTExNjcgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6 ZSAyNzYgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lEIFs8OENGN0FBQUI1MjUwM0I0MDZCNjI4 MkM4MjJBQzA3NDE+PDhDRjdBQUFCNTI1MDNCNDA2QjYyODJDODIyQUMwNzQxPl0KPj4Kc3RhcnR4 cmVmCjUzMTA3CiUlRU9GCgoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA5LjAy KQovQ3JlYXRpb25EYXRlKEQ6MjAxMjA2MjgyMDI4MjMrMDInMDAnKS9DcmVhdG9yKGh0bWwycHMg dmVyc2lvbiAxLjAgYmV0YTcpCi9BdXRob3IoKQovS2V5d29yZHMoKQovU3ViamVjdCgpCi9UaXRs ZShkcmFmdC1rZWxzZXktaW50YXJlYS1tZXNoLWxpbmstZXN0YWJsaXNobWVudC0wNCAtIE1lc2gg TGluayBFc3RhYmxpc2htZW50KS9Nb2REYXRlKEQ6MjAxMjEwMTgyMDMwNTMrMDknMDAnKT4+CmVu ZG9iagoyNzYgMCBvYmoKWzMxNzEgMyA1ODc4MyA1ODc3NyA1MzEwNyA1ODc3MSA1ODc4MyA1ODc3 NyA1MzEwNyA1ODc3MSA1MzEwNyA8NzYwNzIzQ0FGRkEwMzZFQTA0MjVFNjE3MkFDMjBBQTc+IDEg MCAwIDAgMF0KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL0Rl c3RzIDggMCBSCi9NZXRhZGF0YSAyNzUgMCBSCi9QaWVjZUluZm8gMjc3IDAgUj4+CmVuZG9iagoy NzcgMCBvYmoKPDwKL2dyZF9Hb29kUmVhZGVyX0luY3JlbWVudGFsVXBkYXRlPDwvTGFzdE1vZGlm aWVkKEQ6MjAxMjEwMTgyMDMwNTMrMDknMDAnKS9Qcml2YXRlIDI3NiAwIFI+Pgo+PgplbmRvYmoK Mjc5IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzE5 MC44MDYgNTgwLjU5NyAzMTAuNjEyIDU5MS42ODRdL01hdHJpeFsxIDAgMCAxIC0xOTAuODA2IC01 ODAuNTk3XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwv UjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEw Nj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjE5MC44MDYgNTgwLjU5NyBt CjMxMC42MTIgNTgwLjU5NyBsCjMxMC42MTIgNTkxLjY4NCBsCjE5MC44MDYgNTkxLjY4NCBsCmYK UQoKZW5kc3RyZWFtCmVuZG9iagoyODAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hs aWdodC9GIDQvUmVjdFsxOTAuODA2IDU4MC41OTcgMzEwLjYxMiA1OTEuNjg0XS9DWzEuMDAwIDEu MDAwIDAuMDAwXS9RdWFkUG9pbnRzWzE5MC44MDYgNTkxLjY4NCAzMTAuNjEyIDU5MS42ODQgMTkw LjgwNiA1ODAuNTk3IDMxMC42MTIgNTgwLjU5N10vQVA8PC9OIDI3OSAwIFIgPj4vVChUQ2xhdXNl bikvTShEOjIwMTIxMDE4MjAzMDUzKzA5JzAwJykvUCA0IDAgUj4+CmVuZG9iagoyODEgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDI4MiAwIFIvUmVjdFsxODIuMTEy IDU4Ni42ODQgMjEyLjExMiA2MTYuNjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAw MF0vQ29udGVudHMoSSdtIGJlaW5nIGEgbml0cGlja2VyIGhlcmUsIGJ1dDogYWQgaG9jIG1lc2gg bmV0d29yaz8gSXMgdGhhdCB0aGUgc2FtZSBhcyBhIG1vYmlsZSBhZCBob2MgbmV0d29yaz8gT3Ig aXMgaXQgc29tZXRoaW5nIGVsc2U/IE9yLCBpcyBpdCAtIGxpa2UgTExOcyAtIGEgc3Vic2V0IG9m IGEgbW9iaWxlIGFkIGhvYyBuZXR3b3JrP1xuXG5JIGd1ZXNzIHRoYXQgdGhpcyB0aWVzIGluIHdp dGggdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hlcmUgdGhpcyBmaXRzIGludG8gdGhlIElFVEYgcGlj dHVyZS4gSSBhbSByZXBlYXRpbmcgbXlzZWxmIGhlcmUgZnJvbSBteSBsYXN0IHJldmlldywgYnV0 IHNvIGZhciB0aGlzIHNvdW5kcyBsaWtlIHNvbWV0aGluZyB0aGF0IGJlbG9uZ3MgaW4gW01BTkVU XS4gVGhpcyBjb21tZW50LCBwcm9iYWJseSwgaXMgdG8gdGhlIHNwb25zb3JpbmcgQUQgbW9yZSB0 aGFuIHRvIGFueXRoaW5nIGVsc2UsIGJ1dCB0aGlzIGRvY3VtZW50IGRvZXMgc2VlbSBsaWtlIHNv bWV0aGluZyB0aGF0IHdvdWxkIGJlbG9uZyBpbiBhIHdvcmtpbmcgZ3JvdXAsIGFuZCBpdCBkb2Vz IHNlZW0gbGlrZSB0aGVyZSBzaG91bGQgYmUgYXQgbGVhc3Qgb25lIHdvcmtpbmcgZ3JvdXAsIGlu IHdoaWNoIHRoaXMgd291bGQgYmUgImluIHNjb3BlIi5cblxuSSB1bmRlcnN0YW5kIHRoYXQgdGhl IFtNQU5FVF0gYW5kIFtST0xMXSB3ZyBjaGFpcnMgaGF2ZSByZWZ1c2VkIHRvIGFjY2VwdCB0aGlz IGRvY3VtZW50LCBldmVuIGRpc2N1c3MgaXQgaW4gbWVldGluZ3MuIEkgd291bGQgYXNzdW1lIHRo YXQgdGhleSBoYXZlIGdvb2QgcmVhc29ucz8gSWYgbm90LCB0aGVuIEkgd291bGQgcmVjb21tZW5k IHRoYXQgdGhleSBiZSAiZW5jb3VyYWdlZCIuICkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjAz MDUzKzA5JzAwJykvUCA0IDAgUj4+CmVuZG9iagoyODIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL1BvcHVwL0YgMjgvUmVjdFsyMTcuMTEyIDUwNC42ODQgNDY3LjExMiA2MTYuNjg0XS9QYXJl bnQgMjgxIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjI4MyAwIG9iago8PC9UeXBlL1hPYmplY3Qv U3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs3MS4wMDAgNzY5Ljc2MiAxNzEuODg5IDc4MC44 NDldL01hdHJpeFsxIDAgMCAxIC03MS4wMDAgLTc2OS43NjJdL0dyb3VwPDwvUy9UcmFuc3BhcmVu Y3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9U eXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA0Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4w MDAgMC4wMDAgcmcKNzEuMDAwIDc2OS43NjIgbQoxNzEuODg5IDc2OS43NjIgbAoxNzEuODg5IDc4 MC44NDkgbAo3MS4wMDAgNzgwLjg0OSBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoyODQgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs3MS4wMDAgNzY5Ljc2MiAx NzEuODg5IDc4MC44NDldL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbNzEuMDAwIDc4 MC44NDkgMTcxLjg4OSA3ODAuODQ5IDcxLjAwMCA3NjkuNzYyIDE3MS44ODkgNzY5Ljc2Ml0vQVA8 PC9OIDI4MyAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjAzMDUzKzA5JzAwJykvUCA0 IDAgUj4+CmVuZG9iagoyODUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1Jl Y3RbODEuMjIyIDc3NS44NDkgMTExLjIyMiA4MDUuODQ5XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAx LjAwMCAwLjAwMF0vUG9wdXAgMjg2IDAgUi9Db250ZW50cygxXCkgSXMgdGhhdCB0cnVlP1xuMlwp IElzbid0IHRyYWRpdGlvbiB0aGF0IGFsbCBJLURzIGFyZSBwdWJsaXNoZWQgaW4gdGhlICJOZXR3 b3JraW5nIFdvcmtpbmcgR3JvdXAiPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjAzMDUzKzA5 JzAwJykvUCA0IDAgUj4+CmVuZG9iagoyODYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1Bv cHVwL0YgMjgvUmVjdFsxMTYuMjIyIDY5My44NDkgMzY2LjIyMiA4MDUuODQ5XS9QYXJlbnQgMjg1 IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjI4NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv VGV4dC9GIDQvUmVjdFszMDkuNzk1IDQ3NS40ODEgMzM5Ljc5NSA1MDUuNDgxXS9OYW1lL0NvbW1l bnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMjg4IDAgUi9Db250ZW50cyhJIGFtIG1ha2lu ZyB0aGUgc2FtZSBjb21tZW50IGFzIEkgZGlkIGluIG15IHByZXZpb3VzIHJldmlldzogZnJvbSBy ZWFkaW5nIHRoZSBhYnN0cmFjdCwgdGhpcyBsb29rcyB2ZXJ5IHZlcnkgbXVjaCBsaWtlIFJGQzYx MzAgZXhjZXB0IGZvciB0aGUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIC0tIHdoaWNoLCBhcyBJ IHRoaW5rIEkgaGF2ZSBpbmRpY2F0ZWQsIGlzIHNvbWV0aGluZyB0aGF0IGNvdWxkIHNpbXBseSBi ZSBhZGRpdGlvbmFsIFRMVnMgZm9yIFJGQzYxMzAuXG5cbkkgdGhpbmsgdGhhdCwgYXQgdGhlIHZl cnkgdmVyeSBsZWFzdCwgd2h5IGEgZGlmZmVyZW50IFwoZnJvbSBSRkM2MTMwXCkgYXBwcm9hY2gg aXMgdGFrZW4gc2hvdWxkIGJlIGNsZWFyIGV2ZW4gZnJvbSB0aGUgYWJzdHJhY3QuXG4pL1QoVENs YXVzZW4pL00oRDoyMDEyMTAxODIwMzA1MyswOScwMCcpL1AgNCAwIFI+PgplbmRvYmoKMjg4IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzQ0Ljc5NSAzOTMuNDgx IDU5NC43OTUgNTA1LjQ4MV0vUGFyZW50IDI4NyAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago0IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNCAwIFIK L0ZvbnQgMTUgMCBSCj4+L0Fubm90cyAyNzggMCBSIC9Db250ZW50cyA1IDAgUj4+CmVuZG9iagoy NzggMCBvYmoKWzEwIDAgUgoxMSAwIFIKMTIgMCBSCjEzIDAgUiAyODAgMCBSIDI4MSAwIFIgMjgy IDAgUiAyODQgMCBSIDI4NSAwIFIgMjg2IDAgUiAyODcgMCBSIDI4OCAwIFJdCmVuZG9iagoyOTAg MCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbODkuOTE3 IDUxNy41NDIgNDg3LjE2OCA1MjguNjI5XS9NYXRyaXhbMSAwIDAgMSAtODkuOTE3IC01MTcuNTQy XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9B SVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3Ry ZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjg5LjkxNyA1MTcuNTQyIG0KNDg3LjE2 OCA1MTcuNTQyIGwKNDg3LjE2OCA1MjguNjI5IGwKODkuOTE3IDUyOC42MjkgbApmClEKCmVuZHN0 cmVhbQplbmRvYmoKMjkxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0 L1JlY3RbODkuOTE3IDUxNy41NDIgNDg3LjE2OCA1MjguNjI5XS9DWzEuMDAwIDEuMDAwIDAuMDAw XS9RdWFkUG9pbnRzWzg5LjkxNyA1MjguNjI5IDQ4Ny4xNjggNTI4LjYyOSA4OS45MTcgNTE3LjU0 MiA0ODcuMTY4IDUxNy41NDJdL0FQPDwvTiAyOTAgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEy MTAxODIwMzA1MyswOScwMCcpL1AgODUgMCBSPj4KZW5kb2JqCjI5MiAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs0NTYuNDA0IDUyMy42MjkgNDg2LjQwNCA1NTMuNjI5 XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMjkzIDAgUi9Db250ZW50 cyhBcyBvbmUgb2YgdGhlIGF1dGhvcnMgb2YgUkZDNjEzMCwgdGhpcyBpcyBxdWl0ZSBzaW1wbHkg bm90IHRydWUuXG5cbklmIHlvdSBoYXZlIHNlY3VyZWQgbGlua3MsIHRoZW4gc3VyZSwgUkZDNjEz MCBjYW4gdXNlIHRoYXQuIFxuXG5BYnNlbnQgc2VjdXJlZCBsaW5rcywgUkZDNjEzMCBzdWdnZXN0 cyBhZGRpbmcgVExWcyBjb250YWluaW5nIGF1dGhlbnRpY2F0aW9uIFwodXNpbmcgUkZDNjYyMiAt IHRoZSBhY3R1YWwgc3BlYyBmb3IgdXNpbmcgUkZDNjYyMitSRkM2MTMwIGlzIGJlaW5nIGRldmVs b3BlZCBieSBbbWFuZXRdIGN1cnJlbnRseV1cKS5cblxuU28sIHRoaXMgaXMgbm90IGEgZGlzdGlu Z3Vpc2hpbmcgZmVhdHVyZSBmb3IgTUxFLXZzLTYxMzAsIGFuZCB0aHVzIG5vdCBhIHZhbGlkIG1v dGl2YXRpb24gZm9yIE1MRS5cbikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjAzMDUzKzA5JzAw JykvUCA4NSAwIFI+PgplbmRvYmoKMjkzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1 cC9GIDI4L1JlY3RbNDkxLjQwNCA0NDEuNjI5IDc0MS40MDQgNTUzLjYyOV0vUGFyZW50IDI5MiAw IFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyOTQgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv Rm9ybS9Gb3JtVHlwZSAxL0JCb3hbODkuOTE3IDQ2Ny4wOTggMjQxLjI1MSA0NzguMTg1XS9NYXRy aXhbMSAwIDAgMSAtODkuOTE3IC00NjcuMDk4XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVz b3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRH U3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAw IHJnCjg5LjkxNyA0NjcuMDk4IG0KMjQxLjI1MSA0NjcuMDk4IGwKMjQxLjI1MSA0NzguMTg1IGwK ODkuOTE3IDQ3OC4xODUgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMjk1IDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbODkuOTE3IDQ2Ny4wOTggMjQxLjI1MSA0 NzguMTg1XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzg5LjkxNyA0NzguMTg1IDI0 MS4yNTEgNDc4LjE4NSA4OS45MTcgNDY3LjA5OCAyNDEuMjUxIDQ2Ny4wOThdL0FQPDwvTiAyOTQg MCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIwMzA1MyswOScwMCcpL1AgODUgMCBSPj4K ZW5kb2JqCjI5NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMjk3 IDAgUi9SZWN0Wzk2Ljk4NiA0NzMuMTg1IDEyNi45ODYgNTAzLjE4NV0vTmFtZS9Db21tZW50L0Nb MS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKEkgYW0gYWN0dWFsbHkgbm90IHN1cmUgd2hhdCB0 aGlzIG1lYW5zLlxuXG5OSERQIG1ha2VzIGZldyBhc3N1bXB0aW9ucyBhcyB0byB3aGF0IHRoZSB1 bmRlcmx5aW5nIGxpbmsgbGF5ZXIgZG9lcywgb3RoZXIgdGhhbiBzdXBwb3J0IGJyb2FkY2FzdCB0 cmFuc21pc3Npb25zLiAgVGhlIEwyIG1heSBkbyAic3R1ZmYiIFwobmVnb3RpYXRlIGludGVyZmFj ZSBzcGVlZHMsIG9yIHNvbWUgc3VjaCB0aGluZ1wpLlxuXG5BbGxvdyBtZSBhbHNvIHRvIGFzazog d2hlbiB5b3Ugc2F5ICJsaW5rIiwgd2hhdCBleGFjdGx5IGlzIG1lYW50PyBJbiBOSERQLCBpdCAg aXMgc2ltcGx5ICJhbnkgdHdvIGludGVyZmFjZXMsIGFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCBl YWNoIG90aGVyIi4gTkQgaGFzIGEgdmVyeSBkaWZmZXJlbnQgdW5kZXJzdGFuZGluZyBvZiBsaW5r LlxuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMDMwNTMrMDknMDAnKS9QIDg1IDAgUj4+CmVu ZG9iagoyOTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxMzEu OTg2IDM5MS4xODUgMzgxLjk4NiA1MDMuMTg1XS9QYXJlbnQgMjk2IDAgUi9PcGVuIGZhbHNlPj4K ZW5kb2JqCjI5OCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEv QkJveFszMjMuMjIzIDQ2Ny4wOTggNDA1LjE5NSA0NzguMTg1XS9NYXRyaXhbMSAwIDAgMSAtMzIz LjIyMyAtNDY3LjA5OF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdT dGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xl bmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwozMjMuMjIzIDQ2 Ny4wOTggbQo0MDUuMTk1IDQ2Ny4wOTggbAo0MDUuMTk1IDQ3OC4xODUgbAozMjMuMjIzIDQ3OC4x ODUgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMjk5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9IaWdobGlnaHQvRiA0L1JlY3RbMzIzLjIyMyA0NjcuMDk4IDQwNS4xOTUgNDc4LjE4NV0vQ1sx LjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1szMjMuMjIzIDQ3OC4xODUgNDA1LjE5NSA0Nzgu MTg1IDMyMy4yMjMgNDY3LjA5OCA0MDUuMTk1IDQ2Ny4wOThdL0FQPDwvTiAyOTggMCBSID4+L1Qo VENsYXVzZW4pL00oRDoyMDEyMTAxODIwMzA1MyswOScwMCcpL1AgODUgMCBSPj4KZW5kb2JqCjMw MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFszMTQuNTI5IDQ3My4x ODUgMzQ0LjUyOSA1MDMuMTg1XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9w dXAgMzAxIDAgUi9Db250ZW50cyhORCwgeWVzIC0gTkhEUCwgbm90IHNvIG11Y2guICkvVChUQ2xh dXNlbikvTShEOjIwMTIxMDE4MjAzMDUzKzA5JzAwJykvUCA4NSAwIFI+PgplbmRvYmoKMzAxIDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzQ5LjUyOSAzOTEuMTg1 IDU5OS41MjkgNTAzLjE4NV0vUGFyZW50IDMwMCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMDIg MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDMwMyAwIFIvUmVjdFs0 MDkuNzAwIDE5MC45NzggNDM5LjcwMCAyMjAuOTc4XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAw MCAwLjAwMF0vQ29udGVudHMoU28gdGhpcyBzb3VuZHMgbGlrZSBhIGNoYW5uZWwtZXN0aW1hdGlv biBwcm90b2NvbCBvZiBzb3J0cy4gSXMgdGhhdCByZWxhdGVkIHRvIHRoZSBFVHggZXN0aW1hdGlv bnM/IFxuXG5JIHJlbWVtYmVyIG9uIG1hbmV0QGlldGYgdGhhdCB0aGVyZSBoYXMgYmVlbiBzb21l IGNvbnRlbnRpb24gYXMgdG8gd2hhdCB0aGUgcHJvcGVyIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGlz IGZvciBldmFsdWF0aW5nIHN1Y2gsIGhhcyB0aGlzIGJlZW4gcmVmbGVjdGVkP1xuKS9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMTgyMDMwNTMrMDknMDAnKS9QIDg1IDAgUj4+CmVuZG9iagozMDMgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0NDQuNzAwIDEwOC45Nzgg Njk0LjcwMCAyMjAuOTc4XS9QYXJlbnQgMzAyIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjMwNCAw IG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsyMjIuMzM0 IDI0MC4xMDEgMjc5LjA4NCAyNTEuMTg4XS9NYXRyaXhbMSAwIDAgMSAtMjIyLjMzNCAtMjQwLjEw MV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwv QUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0 cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoyMjIuMzM0IDI0MC4xMDEgbQoyNzku MDg0IDI0MC4xMDEgbAoyNzkuMDg0IDI1MS4xODggbAoyMjIuMzM0IDI1MS4xODggbApmClEKCmVu ZHN0cmVhbQplbmRvYmoKMzA1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQv RiA0L1JlY3RbMjIyLjMzNCAyNDAuMTAxIDI3OS4wODQgMjUxLjE4OF0vQ1sxLjAwMCAxLjAwMCAw LjAwMF0vUXVhZFBvaW50c1syMjIuMzM0IDI1MS4xODggMjc5LjA4NCAyNTEuMTg4IDIyMi4zMzQg MjQwLjEwMSAyNzkuMDg0IDI0MC4xMDFdL0FQPDwvTiAzMDQgMCBSID4+L1QoVENsYXVzZW4pL00o RDoyMDEyMTAxODIwMzA1MyswOScwMCcpL1AgODUgMCBSPj4KZW5kb2JqCjMwNyAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyMzUuNzA5IDI0Ni4xODggMjY1LjcwOSAy NzYuMTg4XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzA4IDAgUi9D b250ZW50cyhPYnNlcnZpbmcgYWxzbywgdGhhdCBkaWZmZXJlbnQgTDIncykvVChUQ2xhdXNlbikv TShEOjIwMTIxMDE4MjAzMDUzKzA5JzAwJykvUCA4NSAwIFI+PgplbmRvYmoKMzA4IDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjcwLjcwOSAxNjQuMTg4IDUyMC43 MDkgMjc2LjE4OF0vUGFyZW50IDMwNyAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMTAgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMjM1LjcwOSAyNDYuMTg4IDI2NS43 MDkgMjc2LjE4OF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDMxMSAw IFIvQ29udGVudHMoT2JzZXJ2aW5nIGFsc28sIHRoYXQgZGlmZmVyZW50IEwyJ3MgdHJlYXQgdW5p Y2FzdCBhbmQgYnJvYWRjYXN0IGRpZmZlcmVudGx5OiB0cmFuc21pc3Npb24gcmF0ZXMsIHJldHJh bnNtaXNzaW9ucywgLi4uLikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjAzMDUzKzA5JzAwJykv UCA4NSAwIFI+PgplbmRvYmoKMzExIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9G IDI4L1JlY3RbMjcwLjcwOSAxNjQuMTg4IDUyMC43MDkgMjc2LjE4OF0vUGFyZW50IDMxMCAwIFIv T3BlbiBmYWxzZT4+CmVuZG9iago4NSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgOTQgMCBSCi9Gb250IDk1IDAgUgo+Pi9Bbm5vdHMgMjg5IDAgUiAv Q29udGVudHMgODYgMCBSPj4KZW5kb2JqCjI4OSAwIG9iagpbODggMCBSCjg5IDAgUgo5MCAwIFIK OTEgMCBSCjkyIDAgUgo5MyAwIFIgMjkxIDAgUiAyOTIgMCBSIDI5MyAwIFIgMjk1IDAgUiAyOTYg MCBSIDI5NyAwIFIgMjk5IDAgUiAzMDAgMCBSIDMwMSAwIFIgMzAyIDAgUiAzMDMgMCBSIDMwNSAw IFIgMzA3IDAgUiAzMDggMCBSIDMxMCAwIFIgMzExIDAgUl0KZW5kb2JqCjMxMyAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMzA2IDAgUi9SZWN0WzI3My41NDIgNDM1 LjM1MSAzMDMuNTQyIDQ2NS4zNTFdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9D b250ZW50cyhTbywgYXQgdGhpcyBwb2ludCwgeW91IGFyZSB3aXRoIE1MRSBhdCB0aGUgc2FtZSBw b2ludCBhcyBOSERQOiBpZiBhIGRldmljZSBoYXMgYW4gSVAgYWRkcmVzcywgaXQgY2FuIHBhcnRp Y2lwYXRlIGluIE5IRFAuIEZvciBNTEUgdG8gdXNlIFVEUCwgdGhpcyB3b3VsZCBiZSB0aGUgc2Ft ZS5cblxuVGhlIG1lc3NhZ2UgZXhjaGFuZ2UgaW4gTkhEUCBzZXJ2ZXMgdG8gZXN0YWJsaXNoLCBm b3IgYSByb3V0ZXIgYW5kIG92ZXIgZWFjaCBpbnRlcmZhY2UsIHRoZSAibGlua3MiIHRvIG5laWdo Ym9ycy4gVGhlIG1pbmltdW0gcHJvcGVydHkgdGhhdCBpcyBlc3RhYmxpc2hlZCBieSBOSERQIGlz IGJpZGlyZWN0aW9uYWwgY29ubmVjdGl2aXR5LCBidXQgdGhpcyBpcyBieSBkZXNpZ24gLSBhbmQg Zm9yIGZ1cnRoZXIgcHJvcGVydGllcyBcKHN1Y2ggYXMgRVRYLCBpZiBuZWVkZWRcKSBjYW4gYmUg ZG9uZSBieSBUTFZzLlxuXG5BZ2FpbiwgbXkgcG9pbnQgaXMgbm90IHNheWluZyAidGhvdSBzaGFs dCB1c2UiIGFub3RoZXIgcHJvdG9jb2wsIGJ1dCBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIGZvciBp dCB0byBiZSBjbGVhcmx5IHNwZWxsZWQgb3V0IGluIHdoaWNoIHdheSB0aGlzIGlzIG5vdCAib2xk IHdpbmUgaW4gc21hbGxlciBib3R0bGVzIi5cblxuVGhpcyB2ZXJ5IG11Y2ggbGlua3MgaW4gd2l0 aCB0aGUgbGFjayBvZiBhbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBpbiB0aGlzIGRvY3VtZW50 LCB3aGljaCBpcyBhbiBhYnNvbHV0ZSBtdXN0IGdpdmVuIHdoYXQgYXBwZWFycyB0byBiZSBhIHN0 cm9uZyBvdmVybGFwIHdpdGggd2hhdCBvdGhlciBwcm90b2NvbHMgZG8uKS9UKFRDbGF1c2VuKS9N KEQ6MjAxMjEwMTgyMDMwNTMrMDknMDAnKS9QIDEwNCAwIFI+PgplbmRvYmoKMzA2IDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzA4LjU0MiAzNTMuMzUxIDU1OC41 NDIgNDY1LjM1MV0vUGFyZW50IDMwNSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxMDQgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEwOSAwIFIKL0Zv bnQgMTEwIDAgUgo+Pi9Bbm5vdHMgMzEyIDAgUiAvQ29udGVudHMgMTA1IDAgUj4+CmVuZG9iagoz MTIgMCBvYmoKWzEwNyAwIFIKMTA4IDAgUiAzMTMgMCBSIDMwNiAwIFJdCmVuZG9iagozMTUgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDMwOSAwIFIvUmVjdFs1OS4x NTMgNjM3LjEyOCA4OS4xNTMgNjY3LjEyOF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4w MDBdL0NvbnRlbnRzKElzIHRoaXMgbm90IHNvbWV0aGluZyB0aGF0IHNob3VsZCBiZSBwYXJhbWV0 cml6ZWQgYW5kIHNldCB1cCBJQU5BIHJlZ2lzdHJpZXM/IEkgc2VlIHRoYXQgeW91IGFncmVlLCB0 aGVyZSBpcyBhIHJlZ2lzdHJ5LiBJbiB0aGF0IGNhc2UsIEkgd291bGQgcmVjb21tZW5kIHRvIG5v dCBzcGVjaWZ5IHRoZXNlIHNlY3VyaXR5IHN1aXRlcyBpbiB0aGUgbWFpbiBwYXJ0IG9mIHRoZSBk b2N1bWVudCwgYnV0IHNpbXBseSBoaXZlIHRob3NlIHNwZWNpZmljcyBvZmYgdG8gdGhlIElBTkEg cmVnaXN0cnksIGFuZCBkZWZpbmUgdGhlIGludGVyZmFjZSBiZXR3ZWVuIE1MRSBhbmQgdGhlc2Ug c3VpdGVzP1xuXG5JbiBvdGhlciB3b3JkcywgSSB3b3VsZCBhdm9pZCAidGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgdHdvIHNlY3VyaXR5IHN1aXRlcyIpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIw MzA1MyswOScwMCcpL1AgMTExIDAgUj4+CmVuZG9iagozMDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs5NC4xNTMgNTU1LjEyOCAzNDQuMTUzIDY2Ny4xMjhdL1Bh cmVudCAzMTUgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMzE2IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9UZXh0L0YgNC9SZWN0WzE1MS45MjAgNTIxLjUyOCAxODEuOTIwIDU1MS41MjhdL05h bWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzMTcgMCBSL0NvbnRlbnRzKFNv IGlzIHRoaXMgc3BlY2lmaWMgdG8gODAyLjE1LjQsIG9yIGlzIGl0IGdlbmVyYWw/XG5cbkFnYWlu LCB0aGlzIGlzIG9uZSBiaXQgdGhhdCB3b3VsZCBiZW5lZml0IGZyb20gaGF2aW5nIGEgcHJvcGVy IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50LiBTbyBmYXIgaW4gdGhpcyBJLUQsIG9uZSBjb3VsZCBn ZXQgYXdheSB3aXRoIHRoZSBpbXByZXNzaW9uIHRoYXQgaXQgd2FzIGZvciAiZ2VuZXJhbCBMMnMi LCBidXQgdGhpcyBzZWVtcyB0byBpbmRpY2F0ZSBvdGhlcndpc2U/XG4pL1QoVENsYXVzZW4pL00o RDoyMDEyMTAxODIwMzA1MyswOScwMCcpL1AgMTExIDAgUj4+CmVuZG9iagozMTcgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxODYuOTIwIDQzOS41MjggNDM2Ljky MCA1NTEuNTI4XS9QYXJlbnQgMzE2IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjMxOSAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMzIxIDAgUi9SZWN0WzU5LjE1MyAz OTcuNTE5IDg5LjE1MyA0MjcuNTE5XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0v Q29udGVudHMoSXMgdGhlIGxlbmd0aCBvZiB0aGF0IGNvbnN0YW50PyBGb3IgYWxsIHNlY3VyaXR5 IHN1aXRlcz8gV2hlbiBub3QgcnVubmluZyBvdmVyIDgwMi4xNS40PykvVChUQ2xhdXNlbikvTShE OjIwMTIxMDE4MjAzMDUzKzA5JzAwJykvUCAxMTEgMCBSPj4KZW5kb2JqCjMyMSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0Wzk0LjE1MyAzMTUuNTE5IDM0NC4xNTMg NDI3LjUxOV0vUGFyZW50IDMxOSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMjMgMCBvYmoKPDwv VHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMTcxLjg4OSAyNjUuMzIw IDIyMi4zMzQgMjc2LjQwOF0vTWF0cml4WzEgMCAwIDEgLTE3MS44ODkgLTI2NS4zMjBdL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxz ZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQov UjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMTcxLjg4OSAyNjUuMzIwIG0KMjIyLjMzNCAyNjUu MzIwIGwKMjIyLjMzNCAyNzYuNDA4IGwKMTcxLjg4OSAyNzYuNDA4IGwKZgpRCgplbmRzdHJlYW0K ZW5kb2JqCjMyNSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0 WzE3MS44ODkgMjY1LjMyMCAyMjIuMzM0IDI3Ni40MDhdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1 YWRQb2ludHNbMTcxLjg4OSAyNzYuNDA4IDIyMi4zMzQgMjc2LjQwOCAxNzEuODg5IDI2NS4zMjAg MjIyLjMzNCAyNjUuMzIwXS9BUDw8L04gMzIzIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEw MTgyMDMwNTMrMDknMDAnKS9QIDExMSAwIFI+PgplbmRvYmoKMzI2IDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzE2OS41MDAgMjcxLjQwOCAxOTkuNTAwIDMwMS40MDhd L05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzMjcgMCBSL0NvbnRlbnRz KFdoeSBpcyB0aGF0PyBBIGJpdCBvZiBlZHVjYXRpb24gaGVyZSwgcGxlYXNlLi4uKS9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMTgyMDMwNTMrMDknMDAnKS9QIDExMSAwIFI+PgplbmRvYmoKMzI3IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjA0LjUwMCAxODkuNDA4 IDQ1NC41MDAgMzAxLjQwOF0vUGFyZW50IDMyNiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxMTEg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEyNSAw IFIKL0ZvbnQgMTI2IDAgUgo+Pi9Bbm5vdHMgMzE0IDAgUiAvQ29udGVudHMgMTEyIDAgUj4+CmVu ZG9iagozMTQgMCBvYmoKWzExNCAwIFIKMTE1IDAgUgoxMTYgMCBSCjExNyAwIFIKMTE4IDAgUgox MTkgMCBSCjEyMCAwIFIKMTIxIDAgUgoxMjIgMCBSCjEyMyAwIFIKMTI0IDAgUiAzMTUgMCBSIDMw OSAwIFIgMzE2IDAgUiAzMTcgMCBSIDMxOSAwIFIgMzIxIDAgUiAzMjUgMCBSIDMyNiAwIFIgMzI3 IDAgUl0KZW5kb2JqCjMyOSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVj dFsxNjMuMTk1IDcyNS40MDUgMTkzLjE5NSA3NTUuNDA1XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAx LjAwMCAwLjAwMF0vUG9wdXAgMzE4IDAgUi9Db250ZW50cyhSZWNvbW1lbmRlZCByZWFkaW5nOiBS RkM1OCkvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjAzMDUzKzA5JzAwJykvUCAyMjYgMCBSPj4K ZW5kb2JqCjMxOCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzE5 OC4xOTUgNjQzLjQwNSA0NDguMTk1IDc1NS40MDVdL1BhcmVudCAzMjkgMCBSL09wZW4gZmFsc2U+ PgplbmRvYmoKMzMwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzE2 My4xOTUgNzI1LjQwNSAxOTMuMTk1IDc1NS40MDVdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAw IDAuMDAwXS9Qb3B1cCAzMjAgMCBSL0NvbnRlbnRzKFJlY29tbWVuZGVkIHJlYWRpbmc6IFJGQzUy MjYuXG5cbkFsc28sIHRoZXIpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIwMzA1MyswOScwMCcp L1AgMjI2IDAgUj4+CmVuZG9iagozMjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVw L0YgMjgvUmVjdFsxOTguMTk1IDY0My40MDUgNDQ4LjE5NSA3NTUuNDA1XS9QYXJlbnQgMzMwIDAg Ui9PcGVuIGZhbHNlPj4KZW5kb2JqCjMzMSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4 dC9GIDQvUmVjdFsxNjMuMTk1IDcyNS40MDUgMTkzLjE5NSA3NTUuNDA1XS9OYW1lL0NvbW1lbnQv Q1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzIyIDAgUi9Db250ZW50cyhSZWNvbW1lbmRlZCBy ZWFkaW5nOiBSRkM1MjI2LlxuXG5BbHNvLCBBcmUgeW91IHN1cmUgdGhhdCBJRVRGIHJldmlldyBp cyB3aGF0IHlvdSB3YW50LCBpdCBzZWVtcyBmYWlybHkgcmVzdHJpY3RpdmUgdG8gbWUgLS0gd291 bGQgYWxsb2NhdGluZyBhIGZldyBjb2RlLXBvaW50cyBhcyAiZXhwZXJpbWVudGFsIiBhbmQgYSBn b29kIGxvdCBmb3IgImV4cGVydCByZXZpZXciIFwod2l0aCBwcm9wZXIgZ3VpZGVsaW5lc1wpIG5v dCBiZSBhIGdvb2QgaWRlYT9cblxuR2VuZXJhbGx5LCBhIGNvdXBsZSBvZiBjb2RlLXBvaW50cyBm b3IgZXhwZXJpbWVudGFsIHVzZSBpcyBhIGdvb2QgdGhpbmcuIFxuXG5JIGFtIG5vdCBhIHNlY3Vy aXR5IHdvbmssIHNvIEkgZG8gbm90IGtub3cgLSBidXQgYXJlIGFsbCBzZWN1cml0eSByZWxhdGVk IHN1aXRlcyB0cmFuc2xhdGVkIGludG8gUkZDcyBcKHdoaWNoIGFyZSBhIG5lY2Vzc2FyeSBwcmVj b25kaXRpb24gZm9yIElFVEYgUmV2aWV3XCk/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMDMw NTMrMDknMDAnKS9QIDIyNiAwIFI+PgplbmRvYmoKMzIyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTk4LjE5NSA2NDMuNDA1IDQ0OC4xOTUgNzU1LjQwNV0vUGFy ZW50IDMzMSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMzIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL1RleHQvRiA0L1JlY3RbMTYzLjE5NSA3MjUuNDA1IDE5My4xOTUgNzU1LjQwNV0vTmFt ZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDMyNCAwIFIvQ29udGVudHMoUmVj b21tZW5kZWQgcmVhZGluZzogUkZDNTIyNi5cblxuQWxzbywgQXJlIHlvdSBzdXJlIHRoYXQgSUVU RiByZXZpZXcgaXMgd2hhdCB5b3Ugd2FudCwgaXQgc2VlbXMgZmFpcmx5IHJlc3RyaWN0aXZlIHRv IG1lIC0tIHdvdWxkIGFsbG9jYXRpbmcgYSBmZXcgY29kZS1wb2ludHMgYXMgImV4cGVyaW1lbnRh bCIgYW5kIGEgZ29vZCBsb3QgZm9yICJleHBlcnQgcmV2aWV3IiBcKHdpdGggcHJvcGVyIGd1aWRl bGluZXNcKSBub3QgYmUgYSBnb29kIGlkZWE/XG5cbkdlbmVyYWxseSwgYSBjb3VwbGUgb2YgY29k ZS1wb2ludHMgZm9yIGV4cGVyaW1lbnRhbCB1c2UgaXMgYSBnb29kIHRoaW5nLiBcblxuSSBhbSBu b3QgYSBzZWN1cml0eSB3b25rLCBzbyBJIGRvIG5vdCBrbm93IC0gYnV0IGFyZSBhbGwgc2VjdXJp dHkgcmVsYXRlZCBzdWl0ZXMgdHJhbnNsYXRlZCBpbnRvIFJGQ3MgXCh3aGljaCBhcmUgYSBuZWNl c3NhcnkgcHJlY29uZGl0aW9uIGZvciBJRVRGIFJldmlld1wpP1xuKS9UKFRDbGF1c2VuKS9NKEQ6 MjAxMjEwMTgyMDMwNTMrMDknMDAnKS9QIDIyNiAwIFI+PgplbmRvYmoKMzI0IDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTk4LjE5NSA2NDMuNDA1IDQ0OC4xOTUg NzU1LjQwNV0vUGFyZW50IDMzMiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyMjYgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIzNCAwIFIKL0ZvbnQg MjM1IDAgUgo+Pi9Bbm5vdHMgMzI4IDAgUiAvQ29udGVudHMgMjI3IDAgUj4+CmVuZG9iagozMjgg MCBvYmoKWzIyOSAwIFIKMjMwIDAgUgoyMzEgMCBSCjIzMiAwIFIKMjMzIDAgUiAzMjkgMCBSIDMx OCAwIFIgMzMwIDAgUiAzMjAgMCBSIDMzMSAwIFIgMzIyIDAgUiAzMzIgMCBSIDMyNCAwIFJdCmVu ZG9iagp4cmVmCjAgMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNTkxODIgMDAwMDAgbiAKMDAw MDA1ODc4NCAwMDAwMCBuIAo0IDEKMDAwMDA2MjkyNCAwMDAwMCBuIAo4NSAxCjAwMDAwNjg4MTkg MDAwMDAgbiAKMTA0IDEKMDAwMDA3MDMyOCAwMDAwMCBuIAoxMTEgMQowMDAwMDczMjQxIDAwMDAw IG4gCjIyNiAxCjAwMDAwNzU5MTEgMDAwMDAgbiAKMjc2IDU3CjAwMDAwNTkwNTcgMDAwMDAgbiAK MDAwMDA1OTI3OSAwMDAwMCBuIAowMDAwMDYzMDk4IDAwMDAwIG4gCjAwMDAwNTkzOTQgMDAwMDAg biAKMDAwMDA1OTc1NiAwMDAwMCBuIAowMDAwMDYwMDExIDAwMDAwIG4gCjAwMDAwNjEwNzYgMDAw MDAgbiAKMDAwMDA2MTE5MiAwMDAwMCBuIAowMDAwMDYxNTUwIDAwMDAwIG4gCjAwMDAwNjE4MDIg MDAwMDAgbiAKMDAwMDA2MjA5NiAwMDAwMCBuIAowMDAwMDYyMjEyIDAwMDAwIG4gCjAwMDAwNjI4 MDggMDAwMDAgbiAKMDAwMDA2ODk5NSAwMDAwMCBuIAowMDAwMDYzMjA5IDAwMDAwIG4gCjAwMDAw NjM1NjcgMDAwMDAgbiAKMDAwMDA2MzgyMCAwMDAwMCBuIAowMDAwMDY0NDMxIDAwMDAwIG4gCjAw MDAwNjQ1NDcgMDAwMDAgbiAKMDAwMDA2NDkwNSAwMDAwMCBuIAowMDAwMDY1MTU4IDAwMDAwIG4g CjAwMDAwNjU3ODMgMDAwMDAgbiAKMDAwMDA2NTg5OSAwMDAwMCBuIAowMDAwMDY2MjYxIDAwMDAw IG4gCjAwMDAwNjY1MTcgMDAwMDAgbiAKMDAwMDA2Njc0MSAwMDAwMCBuIAowMDAwMDY2ODU3IDAw MDAwIG4gCjAwMDAwNjczMTAgMDAwMDAgbiAKMDAwMDA2NzQyNiAwMDAwMCBuIAowMDAwMDY3Nzg4 IDAwMDAwIG4gCjAwMDAwNzAyMTIgMDAwMDAgbiAKMDAwMDA2ODA0NCAwMDAwMCBuIAowMDAwMDY4 Mjc0IDAwMDAwIG4gCjAwMDAwNzExNjggMDAwMDAgbiAKMDAwMDA2ODM5MCAwMDAwMCBuIAowMDAw MDY4NzAzIDAwMDAwIG4gCjAwMDAwNzA1MDggMDAwMDAgbiAKMDAwMDA2OTE4NCAwMDAwMCBuIAow MDAwMDczNDIxIDAwMDAwIG4gCjAwMDAwNzA1NTkgMDAwMDAgbiAKMDAwMDA3MTI4MyAwMDAwMCBu IAowMDAwMDcxNzUwIDAwMDAwIG4gCjAwMDAwNzM4MjIgMDAwMDAgbiAKMDAwMDA3MTg2NiAwMDAw MCBuIAowMDAwMDc0MTc3IDAwMDAwIG4gCjAwMDAwNzIxNDggMDAwMDAgbiAKMDAwMDA3NDk4NSAw MDAwMCBuIAowMDAwMDcyMjYzIDAwMDAwIG4gCjAwMDAwNzU3OTUgMDAwMDAgbiAKMDAwMDA3MjYy NSAwMDAwMCBuIAowMDAwMDcyODgyIDAwMDAwIG4gCjAwMDAwNzMxMjUgMDAwMDAgbiAKMDAwMDA3 NjA5MSAwMDAwMCBuIAowMDAwMDczNjAwIDAwMDAwIG4gCjAwMDAwNzM5MzggMDAwMDAgbiAKMDAw MDA3NDI5MyAwMDAwMCBuIAowMDAwMDc1MTAxIDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSAzMzMv UHJldiA1MzEwNy9Sb290IDEgMCBSL0luZm8gMiAwIFIvSURbPDhDRjdBQUFCNTI1MDNCNDA2QjYy ODJDODIyQUMwNzQxPjw0NjQ4OEQ0OTMzMDRDQkZBQURDMTk3NjczNzI4MjBCMz5dPj4Kc3RhcnR4 cmVmCjc2MjE0CiUlRU9GCgoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA5LjAy KQovQ3JlYXRpb25EYXRlKEQ6MjAxMjA2MjgyMDI4MjMrMDInMDAnKS9DcmVhdG9yKGh0bWwycHMg dmVyc2lvbiAxLjAgYmV0YTcpCi9BdXRob3IoKQovS2V5d29yZHMoKQovU3ViamVjdCgpCi9UaXRs ZShkcmFmdC1rZWxzZXktaW50YXJlYS1tZXNoLWxpbmstZXN0YWJsaXNobWVudC0wNCAtIE1lc2gg TGluayBFc3RhYmxpc2htZW50KS9Nb2REYXRlKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKT4+CmVu ZG9iagoyNzYgMCBvYmoKWzMxNzEgMyA1ODc4MyA1ODc3NyA1MzEwNyA1ODc3MSA1ODc4MyA1ODc3 NyA1MzEwNyA1ODc3MSA3NjIxNCA8QjU3MTAwNzQyN0I1OTA3QkNENzFCMTVEQUMzRTJCQTQ+IDEg MCAwIDAgMF0KZW5kb2JqCjMzMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQv UG9wdXAgMzM0IDAgUi9SZWN0WzEwOS41OTcgNzAwLjE4MyAxMzkuNTk3IDczMC4xODNdL05hbWUv Q29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhJIGhhdmUgYSBjb3VwbGUgb2Yg b3ZlcmFsbCBjb21tZW50czpcblxuCW8JVGhpcyBkb2N1bWVudCBzb3JlbHkgbmVlZHMgYW5cbgkJ YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQuIFRoZXJlIGFyZSBiaXRzIGFuZFxuCQlwaWVjZXMgc2Nh dHRlcmVkIHRocm91Z2ggdGhlIGRvY3VtZW50LCBcbgkJdGhhdCBjYW4gY29uc3RpdHV0ZSBwYXJ0 cyBvZiBhbiBhcHBsaWNhYmlsaXR5XG4JCXN0YXRlbWVudCwgYnV0IGV2ZW4gdGhhdCBpcyBub3Qg XG4JCXN1ZmZpY2llbnRcblxuCW8JVGhlIGRvY3VtZW50IHNlZW1zIHRvIGNsYWltIHRvIGJlXG4J CXN1cHBvcnRpbmcgbXVsdGlwbGUgTDJzLCBidXQgaW4gbWFueSBwbGFjZXNcbgkJbG9va3MgYXMg aWYgZGVzaWduZWQgZm9yIG9uZSBzcGVjaWZpYyBMMlxuCQlcKFBBTiBJRCwgU2VjdXJpdHksIC4u LlwpLiBUaGlzIGlzIG5vdCBhdCBhbGxcbgkJYXBwcm9wcmlhdGUuXG5cbglvCUkgYW0gYWxzbyBt aXNzaW5nIHNvbWUgc29ydCBvZiBvdmVydmlldy1cbgkJYW5kLWZ1bmN0aW9uaW5nIHNlY3Rpb24u IFRoZXJlIHNlZW1zIHRvXG4JCWJlIGEgbnVtYmVyIG9mIGRpZmZlcmVudCBzaWduYWxpbmcgXG4J CWNvbXBvbmVudHMgXChyZXF1ZXN0IG5ldHdvcmsgcGFyYW1ldGVycy8gXG4JCXJlcGx5IDsgcGVy aW9kaWMgYmVhY29uaW5nIG9mIEVUWCBcbgkJcGFyYW1ldGVycywgc2VjdXJpdHkgbmVnb3RpYXRp b24uLi4uXCkgZWFjaCBcbgkJb2Ygd2hpY2ggaGF2aW5nIGRpZmZlcmVudCBzaWduYWxpbmcgXG4J CXNlbWFudGljcy4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgNCAw IFI+PgplbmRvYmoKMzM0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1Jl Y3RbMTQ0LjU5NyA2MTguMTgzIDM5NC41OTcgNzMwLjE4M10vUGFyZW50IDMzMyAwIFIvT3BlbiBm YWxzZT4+CmVuZG9iagoyNzggMCBvYmoKWzEwIDAgUgoxMSAwIFIKMTIgMCBSCjEzIDAgUiAyODAg MCBSIDI4MSAwIFIgMjgyIDAgUiAyODQgMCBSIDI4NSAwIFIgMjg2IDAgUiAyODcgMCBSIDI4OCAw IFIgMzMzIDAgUiAzMzQgMCBSXQplbmRvYmoKMzM3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9UZXh0L0YgNC9SZWN0WzEwOS41OTcgNTIzLjYyOSAxMzkuNTk3IDU1My42MjldL05hbWUvQ29t bWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzMzUgMCBSL0NvbnRlbnRzKFRoaXMgcmVh ZHMgbGlrZSBhICJtaW5pLUlBTkEgc2VjdGlvbiIsIGVtYmVkZGVkIGludG8gdGhlIG1pZGRsZSBv ZiB0aGUgZG9jdW1lbnQuXG5cbkkgdml2aWRseSByZWNvbW1lbmQsIGluIHRoZSBJQU5BIHNlY3Rp b24sIHRvIGRlZmluZSB2YWx1ZXMsIG1uZW1vbmljcywgYW5kIGRlc2NyaXB0aW9ucywgYW5kIHVz ZSB0aGUgbW5lbW9uaWNzIGluIHRoZSBkb2N1bWVudC4gXG5cblRoYXQgd2F5LCB3aGVuIElBTkEg YXNzaWduIG51bWJlcnMsIHRoZXJlIGlzIGxlc3Mgc3BhY2UgZm9yIGNvbmZ1c2lvbiBpbiBlZGl0 aW5nLlxuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDEyNyAwIFI+ PgplbmRvYmoKMzM1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3Rb MTQ0LjU5NyA0NDEuNjI5IDM5NC41OTcgNTUzLjYyOV0vUGFyZW50IDMzNyAwIFIvT3BlbiBmYWxz ZT4+CmVuZG9iagoxMjcgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K L1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov RXh0R1N0YXRlIDEzNCAwIFIKL0ZvbnQgMTM1IDAgUgo+Pi9Bbm5vdHMgMzM2IDAgUiAvQ29udGVu dHMgMTI4IDAgUj4+CmVuZG9iagozMzYgMCBvYmoKWzEzMCAwIFIKMTMxIDAgUgoxMzIgMCBSCjEz MyAwIFIgMzM3IDAgUiAzMzUgMCBSXQplbmRvYmoKMzQxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9UZXh0L0YgNC9SZWN0WzEwMC4xMzkgNzI1LjQwNSAxMzAuMTM5IDc1NS40MDVdL05hbWUv Q29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzMzggMCBSL0NvbnRlbnRzKFRoaXMg aXMgaW5jb2hlcmVudC4gVGhlIHNlY3Rpb24gaXMgZW50aXRsZWQgInZhbHVlcyIsIHlldCB0aGUg Y29udGVudCBpcyB0aGUgVExWIGZvcm1hdC4gU3VnZ2VzdCBjaGFuZ2luZyB0byAiVExWIEZvcm1h dDopL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTM2IDAgUj4+CmVu ZG9iagozMzggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxMzUu MTM5IDY0My40MDUgMzg1LjEzOSA3NTUuNDA1XS9QYXJlbnQgMzQxIDAgUi9PcGVuIGZhbHNlPj4K ZW5kb2JqCjM0NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs4Ny41 MjggNTQ4Ljg1MSAxMTcuNTI4IDU3OC44NTFdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAu MDAwXS9Qb3B1cCAzNDAgMCBSL0NvbnRlbnRzKFJlZmVyZW5jZSB0byBJQU5BIHJlZ2lzdHJ5LCB3 aGVyZWluIHRoZXNlIFRMVnMgYXJlIGRlZmluZWQuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgy MTM3MzIrMDknMDAnKS9QIDEzNiAwIFI+PgplbmRvYmoKMzQwIDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTIyLjUyOCA0NjYuODUxIDM3Mi41MjggNTc4Ljg1MV0v UGFyZW50IDM0NCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozNDYgMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDM0MyAwIFIvUmVjdFsxMDMuMjkyIDQ2MC41NzQgMTMz LjI5MiA0OTAuNTc0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29udGVudHMo QSBxdWVzdGlvbjogaXMgbXVsdGlwbGUgVExWcyB3aXRoIHRoZSBzYW1lIHR5cGUgcGVybWl0dGVk IG9yIG5vdD8gT3IsIG11c3QgdGhhdCBiZSBzcGVjaWZpZWQgZm9yIGVhY2ggVExWIHR5cGU/XG5c bkkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBnZW5lcmFsIHJ1bGUgYmUgZ2l2ZW4gaGVyZSwgaWYg aXQgaXMgIm11c3QgYmUgc3BlY2lmaWVkIGZvciBlYWNoIFRMViB0eXBlIiwgdGhlbiB0aGlzIHNo b3VsZCBiZSBjYWxsZWQgb3V0IC0tIGFuZCwgdGhlIGRvY3VtZW50IE1VU1QgaW4gdGhhdCBjYXNl IHNheSB0aGF0ICJlYWNoIFRMViB0eXBlIGRlZmluZWQgTVVTdCBzcGVjaWZ5IGlmIGl0IGlzIHBl cm1pdHRlZCB0byBoYXZlIG1vcmUgVExWcyBvZiB0aGF0IHR5cGUgaW4gYSBnaXZlbiBtZXNzYWdl IiAtIG9yIHNvbWV0aGluZy5cblxuRm9yIGFsbCBvZiB0aGUgYmVsb3csIHJlZmVyZW5jZXMgdG8g SUFOQSBzZWN0aW9uLCBieSB3YXkgb2YgbW5lbW9uaWNzLCBub3QgbnVtYmVyLXZhbHVlcywgYXJl IHJlcXVpcmVkLikvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjEzNzMyKzA5JzAwJykvUCAxMzYg MCBSPj4KZW5kb2JqCjM0MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9S ZWN0WzEzOC4yOTIgMzc4LjU3NCAzODguMjkyIDQ5MC41NzRdL1BhcmVudCAzNDEgMCBSL09wZW4g ZmFsc2U+PgplbmRvYmoKMzQ4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9S ZWN0WzE0MS4xMjUgMzcyLjI5NiAxNzEuMTI1IDQwMi4yOTZdL05hbWUvQ29tbWVudC9DWzEuMDAw IDEuMDAwIDAuMDAwXS9Qb3B1cCAzNDUgMCBSL0NvbnRlbnRzKElzIHRoaXMgcmVwcmVzZW50ZWQg aW4gdGhlIHNhbWUgVExWIFwoYW5kIGhvd1wpLCBvciBieSB3YXkgb2YgaW5jbHVkaW5nIG11bHRp cGxlIFRMVnMgb2YgdGhhdCB0eXBlPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjEzNzMyKzA5 JzAwJykvUCAxMzYgMCBSPj4KZW5kb2JqCjM0NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv UG9wdXAvRiAyOC9SZWN0WzE3Ni4xMjUgMjkwLjI5NiA0MjYuMTI1IDQwMi4yOTZdL1BhcmVudCAz NDggMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMzQ5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9UZXh0L0YgNC9Qb3B1cCAzNDcgMCBSL1JlY3RbMTM1LjQ3NSAzMjAuNDg0IDE2NS40NzUgMzUw LjQ4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKDFcKSBwcmVz dW1hYmx5LCBvbmx5IG9uZSBUTFYgb2YgdGhhdCB0eXBlIG1heSBleGlzdCBpbiBhIG1lc3NhZ2U/ XG4yXCkgaG93IGFyZSBhbGwgdGhvc2UgZGlmZmVyZW50IGtpbmRzIG9mIGluZm9ybWF0aW9uIGVu Y29kZWQgaW4gdGhpcyBUTFY/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAn KS9QIDEzNiAwIFI+PgplbmRvYmoKMzQ3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1 cC9GIDI4L1JlY3RbMzA2LjE0OCAxMzEuNTkwIDU1Ni4xNDggMjQzLjU5MF0vUGFyZW50IDM0NiAw IFIvT3BlbiBmYWxzZT4+CmVuZG9iagozNTAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv Rm9ybS9Gb3JtVHlwZSAxL0JCb3hbODkuOTE3IDI2NS4zMjEgMjk4LjAwMSAyNzYuNDA4XS9NYXRy aXhbMSAwIDAgMSAtODkuOTE3IC0yNjUuMzIxXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVz b3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRH U3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwND4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAw IHJnCjg5LjkxNyAyNjUuMzIxIG0KMjk4LjAwMSAyNjUuMzIxIGwKMjk4LjAwMSAyNzYuNDA4IGwK ODkuOTE3IDI3Ni40MDggbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzUyIDAgb2JqCjw8L1R5cGUv QW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbODkuOTE3IDI2NS4zMjEgMjk4LjAwMSAy NzYuNDA4XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzg5LjkxNyAyNzYuNDA4IDI5 OC4wMDEgMjc2LjQwOCA4OS45MTcgMjY1LjMyMSAyOTguMDAxIDI2NS4zMjFdL0FQPDwvTiAzNTAg MCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTM2IDAgUj4+ CmVuZG9iagozNTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDM1 MSAwIFIvUmVjdFsyNjAuOTMxIDI3MS40MDggMjkwLjkzMSAzMDEuNDA4XS9OYW1lL0NvbW1lbnQv Q1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29udGVudHMoVGhpcyBpcyBhIG5vLWdvLlxuXG5XaGlsZSBp dCBtYXkgYmUgc3BlY2lmaWMgdG8gdGhlIGxpbmstbGF5ZXIsIHlvdSBuZWVkIHRoaXMgc3BlY2lm aWVkIHNvbWV3aGVyZTsgYXMgaXQgaXMsIEkgY291bGRuJ3QgaW1wbGVtZW50IGl0LlxuXG5BbHNv LCB5b3UgcHJldmlvdXNseSAtIHdpdGggcmVzcGVjdCB0byBzZWN1cml0eSAtIHNlZW1lZCB0byBs aW5rIHRoZSBwcm90b2NvbCB2ZXJ5IHRpZ2h0bHkgdG8gODAyLjE1LjQsIHNvIHRoaXMgc2VlbXMg dG8gYmUgYW4gaW50ZXJuYWwgY29udHJhZGljdGlvbj9cblxuRmluYWxseSwgeW91IHByZXN1bWFi bHkgd2lsbCBvbmx5IHdhbnQgb25lIG9mIHRoZXNlIHBlciBtZXNzYWdlPykvVChUQ2xhdXNlbikv TShEOjIwMTIxMDE4MjEzNzMyKzA5JzAwJykvUCAxMzYgMCBSPj4KZW5kb2JqCjM1MSAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzI5NS45MzEgMTg5LjQwOCA1NDUu OTMxIDMwMS40MDhdL1BhcmVudCAzNTAgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMzU1IDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzExNS45MDMgMjIwLjk2NCAxNDUu OTAzIDI1MC45NjRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzNTMg MCBSL0NvbnRlbnRzKFlvdSBwcmVzdW1hYmx5IHdpbGwgb25seSB3YW50IG9uZSBvZiB0aGVzZSBw ZXIgbWVzc2FnZT8pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTM2 IDAgUj4+CmVuZG9iagozNTMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgv UmVjdFsxNTAuOTAzIDEzOC45NjQgNDAwLjkwMyAyNTAuOTY0XS9QYXJlbnQgMzU1IDAgUi9PcGVu IGZhbHNlPj4KZW5kb2JqCjEzNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTQ0IDAgUgovRm9udCAxNDUgMCBSCj4+L0Fubm90cyAzMzkgMCBSIC9D b250ZW50cyAxMzcgMCBSPj4KZW5kb2JqCjMzOSAwIG9iagpbMTM5IDAgUgoxNDAgMCBSCjE0MSAw IFIKMTQyIDAgUgoxNDMgMCBSIDM0MSAwIFIgMzM4IDAgUiAzNDQgMCBSIDM0MCAwIFIgMzQ2IDAg UiAzNDMgMCBSIDM0OCAwIFIgMzQ1IDAgUiAzNDkgMCBSIDM0NyAwIFIgMzUyIDAgUiAzNTQgMCBS IDM1MSAwIFIgMzU1IDAgUiAzNTMgMCBSXQplbmRvYmoKMzU4IDAgb2JqCjw8L1R5cGUvQW5ub3Qv U3VidHlwZS9UZXh0L0YgNC9SZWN0WzEyMi4yMDkgNzI1LjQwNSAxNTIuMjA5IDc1NS40MDVdL05h bWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAzNTYgMCBSL0NvbnRlbnRzKEkg Y2Fubm90IGZpZ3VyZSBvdXQgaWYgeW91IHdhbnQgb25seSBvbmUsIG9yIG1vcmUsIG9mIHRoZXNl IFRMVnMgaW4gYSBnaXZlbiBtZXNzYWdlLi4uLkkgd291bGQgaW1hZ2luZSB0aGF0IHlvdSB3b3Vs ZCBuZWVkIG1vcmUgdGhhbiBvbmUgaW4gc29tZSBjaXJjdW1zdGFuY2VzPykvVChUQ2xhdXNlbikv TShEOjIwMTIxMDE4MjEzNzMyKzA5JzAwJykvUCAxNDYgMCBSPj4KZW5kb2JqCjM1NiAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzE1Ny4yMDkgNjQzLjQwNSA0MDcu MjA5IDc1NS40MDVdL1BhcmVudCAzNTggMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMzU5IDAgb2Jq Cjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzE1Mi45NzMgNjQz LjY1MiAxNzguMTk1IDY1NC43MzldL01hdHJpeFsxIDAgMCAxIC0xNTIuOTczIC02NDMuNjUyXS9H cm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMg ZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFt CnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjE1Mi45NzMgNjQzLjY1MiBtCjE3OC4xOTUg NjQzLjY1MiBsCjE3OC4xOTUgNjU0LjczOSBsCjE1Mi45NzMgNjU0LjczOSBsCmYKUQoKZW5kc3Ry ZWFtCmVuZG9iagozNjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQv UmVjdFsxNTIuOTczIDY0My42NTIgMTc4LjE5NSA2NTQuNzM5XS9DWzEuMDAwIDEuMDAwIDAuMDAw XS9RdWFkUG9pbnRzWzE1Mi45NzMgNjU0LjczOSAxNzguMTk1IDY1NC43MzkgMTUyLjk3MyA2NDMu NjUyIDE3OC4xOTUgNjQzLjY1Ml0vQVA8PC9OIDM1OSAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIw MTIxMDE4MjEzNzMyKzA5JzAwJykvUCAxNDYgMCBSPj4KZW5kb2JqCjM2MyAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsxNTAuNTg0IDY0OS43MzkgMTgwLjU4NCA2Nzku NzM5XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzYwIDAgUi9Db250 ZW50cyhFYWNoIFRMViBpbiB0aGUgc2FtZSwgb3IgaW4gZGlmZmVyZW50LCBtZXNzYWdlcz8pL1Qo VENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTQ2IDAgUj4+CmVuZG9iagoz NjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxODUuNTg0IDU2 Ny43MzkgNDM1LjU4NCA2NzkuNzM5XS9QYXJlbnQgMzYzIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2Jq CjM2NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFszNTIuMzYyIDY0 OS43MzkgMzgyLjM2MiA2NzkuNzM5XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0v UG9wdXAgMzYyIDAgUi9Db250ZW50cyhQcmVzdW1hYmx5LCB5b3Ugc2hvdWxkIHdhbnQgdGhpcyBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbj8pL1QoVENsYXVzZW4pL00oRDoy MDEyMTAxODIxMzczMiswOScwMCcpL1AgMTQ2IDAgUj4+CmVuZG9iagozNjIgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszODcuMzYyIDU2Ny43MzkgNjM3LjM2MiA2 NzkuNzM5XS9QYXJlbnQgMzY1IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjM2NyAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyNjcuODU5IDUwNy4xMzkgMjk3Ljg1OSA1 MzcuMTM5XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzY0IDAgUi9D b250ZW50cyhJbiB0aGF0IGNhc2UsIHNhbWUgY29tbWVudCBhcyBhYm92ZSByZWdhcmRpbmcgaG93 IG1hbnkgVExWcywgYXMgd2VsbCBhcyBkaXNjdXNzaW9uIGluIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBzZWN0aW9uIGFwcGx5IGhlcmUgYXMgd2VsbC4pL1QoVENsYXVzZW4pL00oRDoyMDEy MTAxODIxMzczMiswOScwMCcpL1AgMTQ2IDAgUj4+CmVuZG9iagozNjQgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszMDIuODU5IDQyNS4xMzkgNTUyLjg1OSA1Mzcu MTM5XS9QYXJlbnQgMzY3IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjM2OSAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyMTUuMjM0IDQwMS44ODkgMjQ1LjIzNCA0MzEu ODg5XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzY2IDAgUi9Db250 ZW50cyhQcmVzdW1hYmx5LCB5b3Ugd2FudCBvbmx5IG9uZSBvZiB0aGVzZSBpbiBhIG1lc3NhZ2U/ KS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDE0NiAwIFI+PgplbmRv YmoKMzY2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjUwLjIz NCAzMTkuODg5IDUwMC4yMzQgNDMxLjg4OV0vUGFyZW50IDM2OSAwIFIvT3BlbiBmYWxzZT4+CmVu ZG9iagozNzAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMTQ3LjQz MSAzMzQuNDYzIDE3Ny40MzEgMzY0LjQ2M10vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4w MDBdL1BvcHVwIDM2OCAwIFIvQ29udGVudHMoUHJlc3VtYWJseSwgeW91IHdhbnQgb25seSBvbmUg b2YgdGhlc2UgaW4gYSBtZXNzYWdlPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjEzNzMyKzA5 JzAwJykvUCAxNDYgMCBSPj4KZW5kb2JqCjM2OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv UG9wdXAvRiAyOC9SZWN0WzE4Mi40MzEgMjUyLjQ2MyA0MzIuNDMxIDM2NC40NjNdL1BhcmVudCAz NzAgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTQ2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNTYgMCBSCi9Gb250IDE1NyAwIFIKPj4vQW5ub3Rz IDM1NyAwIFIgL0NvbnRlbnRzIDE0NyAwIFI+PgplbmRvYmoKMzU3IDAgb2JqClsxNDkgMCBSCjE1 MCAwIFIKMTUxIDAgUgoxNTIgMCBSCjE1MyAwIFIKMTU0IDAgUgoxNTUgMCBSIDM1OCAwIFIgMzU2 IDAgUiAzNjEgMCBSIDM2MyAwIFIgMzYwIDAgUiAzNjUgMCBSIDM2MiAwIFIgMzY3IDAgUiAzNjQg MCBSIDM2OSAwIFIgMzY2IDAgUiAzNzAgMCBSIDM2OCAwIFJdCmVuZG9iagozNzQgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMjI2LjI1MSA2MjQuNTE3IDI1Ni4yNTEg NjU0LjUxN10vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDM3MSAwIFIv Q29udGVudHMoSG93IHNob3VsZCB0aGlzIGJlIHNldCB3aGVuIHRyYW5zbWl0dGluZywgb3IgaW50 ZXJwcmV0ZWQgd2hlbiByZWNlaXZlZD9cblxuVXN1YWxseSAiUmVzZXJ2ZWQsIGFuZCBNVVNUIGJl IHNldCB0byAwMDAgb24gdHJhbnNtaXNzaW9uIGFuZCBTSE9VTEQgYmUgaWdub3JlZCBvbiByZWNl aXB0IHRvIGJlIGluIGNvbXBsaWFuY2Ugd2l0aCB0aGlzIHZlcnNpb24gb2YgdGhlIHNwZWNpZmlj YXRpb24iIGlzIHRoZSB1c2VkIHBocmFzZS4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzcz MiswOScwMCcpL1AgMTU4IDAgUj4+CmVuZG9iagozNzEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL1BvcHVwL0YgMjgvUmVjdFsyNjEuMjUxIDU0Mi41MTcgNTExLjI1MSA2NTQuNTE3XS9QYXJl bnQgMzc0IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjM3NiAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvVGV4dC9GIDQvUmVjdFszODAuNzM3IDU3NC4wNzMgNDEwLjczNyA2MDQuMDczXS9OYW1l L0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzczIDAgUi9Db250ZW50cygxIHRv IDE2IHdoYXQ/IE9jdGV0cz8gR2lnYWJ5dGVzPyA7XCkpL1QoVENsYXVzZW4pL00oRDoyMDEyMTAx ODIxMzczMiswOScwMCcpL1AgMTU4IDAgUj4+CmVuZG9iagozNzMgMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0MTUuNzM3IDQ5Mi4wNzMgNjY1LjczNyA2MDQuMDcz XS9QYXJlbnQgMzc2IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjM3NyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMzc1IDAgUi9SZWN0WzE4OC40MTcgNDg1Ljc5NiAy MTguNDE3IDUxNS43OTZdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50 cyhPSywgc28gaGVyZSB5b3UgZ2l2ZSBndWlkYW5jZSBhcyB0byB3aGF0IGlzIHRoZSBleHBlY3Rl ZCBiZWhhdmlvciwgYW5kIHRoYXQgaXMgZ29vZC5cblxuT24gdGhlIG90aGVyIGhhbmQsIHdoeSAi U0hPVUxEIE5PVCIgYW5kIG5vdCAiTVVTVCBOT1QiPyBcblxuSSBhbSBvZiB0aGUgbWluZCB0aGF0 IHVubGVzcyB0aGVyZSBhcmUgcmVhbGx5IGNvbXBlbGxpbmcgcmVhc29ucyBcKGluIHdoaWNoIGNh c2UsIHRoZXNlIHJlYXNvbnMgc2hvdWxkIGJlIHNwZWxsZWQgb3V0LCBhcyB3ZWxsIGFzIHRoZWly IGNvbnNlcXVlbmNlc1wpLCBpdCBzaG91bGQgYmUgTVVTVC9NVVNUIE5PVC4gQXMgaXQgaXMsIEkg aGF2ZSBub3QgbWFuYWdlZCB0byBjb21lIHVwIHdpdGggYSBjb21wZWxsaW5nIHJlYXNvbiBhcyB0 byB3aHkgb25lIHdvdWxkIHdhbnQgdG8gbm90IHdyaXRlIE1VU1QgTk9UIGhlcmUuXG5cblVOTEVT UywgdGhhdCBpcywgdGhhdCB0aGVzZSBhcmUgYnJvYWQvbXVsdGljYXN0LCBpbiB3aGljaCBjYXNl IEkgd291bGQgaW1hZ2luZSB0aGF0IG9uZSB3b3VsZCBuZWVkIG9uZSBzdWNoIFRMViBwZXIgbmVp Z2hib3IgXChhbmQgaXQgc2hvdWxkIGJlIHNwZWNpZmllZCB0byBiZSBleGFjdGx5IG9uZSBwZXIg bmVpZ2hib3JcKT8pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTU4 IDAgUj4+CmVuZG9iagozNzUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgv UmVjdFsyMjMuNDE3IDQwMy43OTYgNDczLjQxNyA1MTUuNzk2XS9QYXJlbnQgMzc0IDAgUi9PcGVu IGZhbHNlPj4KZW5kb2JqCjE1OCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTYyIDAgUgovRm9udCAxNjMgMCBSCj4+L0Fubm90cyAzNzIgMCBSIC9D b250ZW50cyAxNTkgMCBSPj4KZW5kb2JqCjM3MiAwIG9iagpbMTYxIDAgUiAzNzQgMCBSIDM3MSAw IFIgMzc2IDAgUiAzNzMgMCBSIDM3NyAwIFIgMzc1IDAgUl0KZW5kb2JqCjM4MCAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs0ODcuOTMyIDI0Ni4xODYgNTE3LjkzMiAy NzYuMTg2XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzc4IDAgUi9D b250ZW50cyhUaGlzIGJpdCBhcHBlYXJzIHVuZGVyc3BlY2lmaWVkLCB0byBzYXkgdGhlIGxlYXN0 LiBFaXRoZXIgeW91IGRlc2NyaWJlIGhvdyB0byBkbyB0aGF0IHByZWNpc2VseSBsYXRlciwgb3Ig aXQgaGFzIHRvIGJlIGRlc2NyaWJlZCBoZXJlLlxuXG5BbHNvLCBJIGluZmVyIHRoYXQgdGhlcmUg Y2FuIGJlIG11bHRpcGxlIG9mIHRoaXMgVExWIHR5cGUgaW4gYSBnaXZlbiBtZXNzYWdlPykvVChU Q2xhdXNlbikvTShEOjIwMTIxMDE4MjEzNzMyKzA5JzAwJykvUCAxNjQgMCBSPj4KZW5kb2JqCjM3 OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzUyMi45MzIgMTY0 LjE4NiA3NzIuOTMyIDI3Ni4xODZdL1BhcmVudCAzODAgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoK MzgyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzE5NC43MjMgMTcw LjUyMCAyMjQuNzIzIDIwMC41MjBdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Q b3B1cCAzODMgMCBSL0NvbnRlbnRzKEFnYWluLCB3aHkgbm90IG11c3Q/KS9UKFRDbGF1c2VuKS9N KEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDE2NCAwIFI+PgplbmRvYmoKMzgzIDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjI5LjcyMyA4OC41MjAgNDc5Ljcy MyAyMDAuNTIwXS9QYXJlbnQgMzgyIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjM4NCAwIG9iago8 PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs3MS4wMDAgMTM5LjIx MSA0ODcuMTY4IDE2Mi45MDldL01hdHJpeFsxIDAgMCAxIC03MS4wMDAgLTEzOS4yMTFdL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxz ZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTc4Pj5zdHJlYW0KcQov UjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzIzLjIyMyAxNTEuODIyIG0KNDg3LjE2OCAxNTEu ODIyIGwKNDg3LjE2OCAxNjIuOTA5IGwKMzIzLjIyMyAxNjIuOTA5IGwKZgo3MS4wMDAgMTM5LjIx MSBtCjMyMy4yMjMgMTM5LjIxMSBsCjMyMy4yMjMgMTUwLjI5OCBsCjcxLjAwMCAxNTAuMjk4IGwK ZgpRCgplbmRzdHJlYW0KZW5kb2JqCjM4NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGln aGxpZ2h0L0YgNC9SZWN0WzcxLjAwMCAxMzkuMjExIDQ4Ny4xNjggMTYyLjkwOV0vQ1sxLjAwMCAx LjAwMCAwLjAwMF0vUXVhZFBvaW50c1szMjMuMjIzIDE2Mi45MDkgNDg3LjE2OCAxNjIuOTA5IDMy My4yMjMgMTUxLjgyMiA0ODcuMTY4IDE1MS44MjIgNzEuMDAwIDE1MC4yOTggMzIzLjIyMyAxNTAu Mjk4IDcxLjAwMCAxMzkuMjExIDMyMy4yMjMgMTM5LjIxMV0vQVA8PC9OIDM4NCAwIFIgPj4vVChU Q2xhdXNlbikvTShEOjIwMTIxMDE4MjEzNzMyKzA5JzAwJykvUCAxNjQgMCBSPj4KZW5kb2JqCjM4 NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFszMjcuMTQwIDE1Ny45 MDkgMzU3LjE0MCAxODcuOTA5XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9w dXAgMzg4IDAgUi9Db250ZW50cyhTdWdnZXN0OlxuXG4iU0hPVUxEIGJlIG11bHRpY2FzdCB0byB0 aGUgZW50aXJlIE1MRSBkb21haW4sIGV4Y2VwdCBmb3Igd2hlbiBhIG5vZGUgdGhhdCBoYXMganVz dCBqb2luZWQgdGhlIG5ldHdvcmssIGluIHdoaWNoIGNhc2UgYSBOZXR3b3JrIFBhcmFtZXRlciBU TFYgTUFZIGJlIHVuaWNhc3QgdG8gdGhhdCBub2RlIi4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAx ODIxMzczMiswOScwMCcpL1AgMTY0IDAgUj4+CmVuZG9iagozODggMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszNjIuMTQwIDc1LjkwOSA2MTIuMTQwIDE4Ny45MDld L1BhcmVudCAzODcgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTY0IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNjkgMCBSCi9Gb250IDE3MCAwIFIK Pj4vQW5ub3RzIDM3OSAwIFIgL0NvbnRlbnRzIDE2NSAwIFI+PgplbmRvYmoKMzc5IDAgb2JqClsx NjcgMCBSCjE2OCAwIFIgMzgwIDAgUiAzNzggMCBSIDM4MiAwIFIgMzgzIDAgUiAzODYgMCBSIDM4 NyAwIFIgMzg4IDAgUl0KZW5kb2JqCjM5MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4 dC9GIDQvUmVjdFsyNzkuODQ4IDcwMC4xODIgMzA5Ljg0OCA3MzAuMTgyXS9OYW1lL0NvbW1lbnQv Q1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzgxIDAgUi9Db250ZW50cyhBbm90aGVyIElBTkEg cmVnaXN0cnkgdG8gc2V0IHVwLCBhcyB3ZWxsIGFzIG1uZW1vbmljcywgcmVmZXJlbmNlLCAuLi4p L1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTcxIDAgUj4+CmVuZG9i agozODEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszMTQuODQ4 IDYxOC4xODIgNTY0Ljg0OCA3MzAuMTgyXS9QYXJlbnQgMzkwIDAgUi9PcGVuIGZhbHNlPj4KZW5k b2JqCjM5MSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJv eFsxMjEuNDQ1IDY0My42NTEgMTQwLjM2MSA2NTQuNzM4XS9NYXRyaXhbMSAwIDAgMSAtMTIxLjQ0 NSAtNjQzLjY1MV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0 ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0 aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoxMjEuNDQ1IDY0My42 NTEgbQoxNDAuMzYxIDY0My42NTEgbAoxNDAuMzYxIDY1NC43MzggbAoxMjEuNDQ1IDY1NC43Mzgg bApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzkyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9I aWdobGlnaHQvRiA0L1JlY3RbMTIxLjQ0NSA2NDMuNjUxIDE0MC4zNjEgNjU0LjczOF0vQ1sxLjAw MCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxMjEuNDQ1IDY1NC43MzggMTQwLjM2MSA2NTQuNzM4 IDEyMS40NDUgNjQzLjY1MSAxNDAuMzYxIDY0My42NTFdL0FQPDwvTiAzOTEgMCBSID4+L1QoVENs YXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTcxIDAgUj4+CmVuZG9iagozOTMg MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMTE1LjkwMyA2NDkuNzM4 IDE0NS45MDMgNjc5LjczOF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVw IDM4NSAwIFIvQ29udGVudHMoVGhpcyByZWFkcyBhcyBpZiBsaW5rZWQgdG8gYSBzcGVjaWZpYyBM Mj8pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAxODIxMzczMiswOScwMCcpL1AgMTcxIDAgUj4+CmVu ZG9iagozODUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxNTAu OTAzIDU2Ny43MzggNDAwLjkwMyA2NzkuNzM4XS9QYXJlbnQgMzkzIDAgUi9PcGVuIGZhbHNlPj4K ZW5kb2JqCjM5NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs1OS4x NTMgNTQ4Ljg0OSA4OS4xNTMgNTc4Ljg0OV0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4w MDBdL1BvcHVwIDM5NSAwIFIvQ29udGVudHMoQWdhaW4sIHByZXN1bWFibHkganVzdCBvbmUgcGVy bWl0dGVkIHBlciBtZXNzYWdlP1xuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDkn MDAnKS9QIDE3MSAwIFI+PgplbmRvYmoKMzk1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Q b3B1cC9GIDI4L1JlY3RbOTQuMTUzIDQ2Ni44NDkgMzQ0LjE1MyA1NzguODQ5XS9QYXJlbnQgMzk0 IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjE3MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTc2IDAgUgovRm9udCAxNzcgMCBSCj4+L0Fubm90cyAz ODkgMCBSIC9Db250ZW50cyAxNzIgMCBSPj4KZW5kb2JqCjM4OSAwIG9iagpbMTc0IDAgUgoxNzUg MCBSIDM5MCAwIFIgMzgxIDAgUiAzOTIgMCBSIDM5MyAwIFIgMzg1IDAgUiAzOTQgMCBSIDM5NSAw IFJdCmVuZG9iagozOTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3Rb MjA3LjMzNCA1OTkuMjk1IDIzNy4zMzQgNjI5LjI5NV0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4w MDAgMC4wMDBdL1BvcHVwIDM5OSAwIFIvQ29udGVudHMoVW5kZXIgd2hpY2ggY29uZGl0aW9ucyBp cyBpcyBhY2NlcHRhYmxlIHRvIG5vdCBkbyB0aHVzPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4 MjEzNzMyKzA5JzAwJykvUCAxNzggMCBSPj4KZW5kb2JqCjM5OSAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzI0Mi4zMzQgNTE3LjI5NSA0OTIuMzM0IDYyOS4yOTVd L1BhcmVudCAzOTcgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNDAwIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzE1MC41ODQgNzAwLjE4MyAxODAuNTg0IDczMC4xODNd L05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA0MDEgMCBSL0NvbnRlbnRz KE5vLCB0aGlzIGlzIGEgTVVTVCAtIG90aGVyd2lzZSwgaW50ZXJvcGVyYWJpbGl0eSBjYW4ndCBi ZSBlbnN1cmVkLlxuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDE3 OCAwIFI+PgplbmRvYmoKNDAxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4 L1JlY3RbMTg1LjU4NCA2MTguMTgzIDQzNS41ODQgNzMwLjE4M10vUGFyZW50IDQwMCAwIFIvT3Bl biBmYWxzZT4+CmVuZG9iago0MDIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0 L1JlY3RbMjcwLjM5MCA3MDAuMTgzIDMwMC4zOTAgNzMwLjE4M10vTmFtZS9Db21tZW50L0NbMS4w MDAgMS4wMDAgMC4wMDBdL1BvcHVwIDQwMyAwIFIvQ29udGVudHMoU3VnZ2VzdCAic2VudCB1c2lu ZyB0aGUgTUxFLXBvcnQsIGFuZCB0aGVuIGRlZmluZSBNTEUgcG9ydCBpbiBJQU5BIGFuZCByZXF1 ZXN0IHRoZSBhc3NpZ25tZW50IHRoZXJlPykvVChUQ2xhdXNlbikvTShEOjIwMTIxMDE4MjEzNzMy KzA5JzAwJykvUCAxNzggMCBSPj4KZW5kb2JqCjQwMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvUG9wdXAvRiAyOC9SZWN0WzMwNS4zOTAgNjE4LjE4MyA1NTUuMzkwIDczMC4xODNdL1BhcmVu dCA0MDIgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNDA0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9UZXh0L0YgNC9SZWN0WzE5Ny44NzUgNjQ5LjczOSAyMjcuODc1IDY3OS43MzldL05hbWUv Q29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCA0MDUgMCBSL0NvbnRlbnRzKFN1Z2dl c3Qgc3RpY2tpbmcgYSByZWZlcmVuY2UgaW50byB0aGUgZG9jdW1lbnQsIHRvIHRoZSBSRkMgZGVm aW5pbmcgdGhvc2UuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDE3 OCAwIFI+PgplbmRvYmoKNDA1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4 L1JlY3RbMjMyLjg3NSA1NjcuNzM5IDQ4Mi44NzUgNjc5LjczOV0vUGFyZW50IDQwNCAwIFIvT3Bl biBmYWxzZT4+CmVuZG9iago0MDYgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9G b3JtVHlwZSAxL0JCb3hbNDI0LjExMiAzMTUuNzY0IDQ0My4wMjkgMzI2Ljg1Ml0vTWF0cml4WzEg MCAwIDEgLTQyNC4xMTIgLTMxNS43NjRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJj ZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0 ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcK NDI0LjExMiAzMTUuNzY0IG0KNDQzLjAyOSAzMTUuNzY0IGwKNDQzLjAyOSAzMjYuODUyIGwKNDI0 LjExMiAzMjYuODUyIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjQwNyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzQyNC4xMTIgMzE1Ljc2NCA0NDMuMDI5IDMy Ni44NTJdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbNDI0LjExMiAzMjYuODUyIDQ0 My4wMjkgMzI2Ljg1MiA0MjQuMTEyIDMxNS43NjQgNDQzLjAyOSAzMTUuNzY0XS9BUDw8L04gNDA2 IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDE3OCAwIFI+ PgplbmRvYmoKNDA4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCA0 MDkgMCBSL1JlY3RbNDE4LjU3MSAzMjEuODUyIDQ0OC41NzEgMzUxLjg1Ml0vTmFtZS9Db21tZW50 L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKEhvdyBtYW55IHRpbWVzPyBNaW5pbXVtIGFu ZCBtYXhpbXVtIGludGVydmFscz8gVGhpcyBNVVNUIGJlIGRlZmluZWQuIEkgZG8gbm90IHRoaW5r IHRoYXQgdGhlIHJlZmVyZW5jZSBzdHVjayBpbiBzdWZmaWNlcy4pL1QoVENsYXVzZW4pL00oRDoy MDEyMTAxODIxMzczMiswOScwMCcpL1AgMTc4IDAgUj4+CmVuZG9iago0MDkgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0NTMuNTcxIDIzOS44NTIgNzAzLjU3MSAz NTEuODUyXS9QYXJlbnQgNDA4IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjE3OCAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTg4IDAgUgovRm9udCAx ODkgMCBSCj4+L0Fubm90cyAzOTYgMCBSIC9Db250ZW50cyAxNzkgMCBSPj4KZW5kb2JqCjM5NiAw IG9iagpbMTgxIDAgUgoxODIgMCBSCjE4MyAwIFIKMTg0IDAgUgoxODUgMCBSCjE4NiAwIFIKMTg3 IDAgUiAzOTcgMCBSIDM5OSAwIFIgNDAwIDAgUiA0MDEgMCBSIDQwMiAwIFIgNDAzIDAgUiA0MDQg MCBSIDQwNSAwIFIgNDA3IDAgUiA0MDggMCBSIDQwOSAwIFJdCmVuZG9iago0MTEgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbODUuNzI4IDM4OC4zMjEgMTE1LjcyOCA0 MTguMzIxXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzk4IDAgUi9D b250ZW50cyhTbywgYSBjb3VwbGUgb2YgZGlmZmVyZW50IHRoaW5ncy4uLlxuXG5XaGF0IGlzIHRo ZSBhcHByb3ByaWF0ZSBiZWhhdmlvciBpZiBvbmUgcmVjZWl2ZXMgdHdvIGlkZW50aWNhbCBUTFZz PyBXaXRoIGNvbmZsaWN0aW5nIHZhbHVlcz8gQ2FuIHN1Y2ggYmUgZGlzY2FyZGVkP1xuXG5UaGlz IHNlY3Rpb24gZG9lcyBub3Qgc3BlY2lmeSB3aGF0IG9uZSBkb2VzIHdpdGggYW4gaW5jb21pbmcg bWVzc2FnZSBvdGhlciB0aGFuIHNlY3VyaXR5IFwoYW5kLCBldmVuIHRoYXQgaXMgdmVyeSB3ZWFr bHkgZGVmaW5lZFwpLiBJIHdvdWxkLCBhdCB0aGUgdmVyeSBsZWFzdCwgZXhwZWN0IGEgcHJvdG9j b2wgc2V0IC8gaW5mb3JtYXRpb24gc2V0IGRlZmluZWQsIHRoYXQgcmVwcmVzZW50cyB0aGUgdmFs dWVzIHJlY2VpdmVkLCBhbmQgd2hpY2ggaXMgdXBkYXRlZCBhY2NvcmRpbmcgdG8gdGhlIG1lc3Nh Z2UgZXhjaGFuZ2UuXG5cbkkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgbWF5IGJlIHNvbWV0aGluZyB0 aGF0IGEgInNtYXJ0IGltcGxlbWVudGVyIGNhbiB0aGluayBvdXQgaGVyc2VsZiIsIGFsYXMsIHdo aWxlIHRoYXQgbWF5IHdlbGwgYmUgdHJ1ZSwgSSBkbyBub3QgZmluZCBpdCBzdWZmaWNpZW50LiBJ biBwYXJ0LCBhbiBpbmZvcm1hdGlvbiBzZXQgZGVmaW5lZCB3b3VsZCBnaXZlIHRoZSBpbnRlcmZh Y2UgdG8gdGhlIHJlc3Qgb2YgdGhlIHN5c3RlbSBcKGluIHdoaWNoIEkgYmVsaWV2ZSB0aGF0IHRo aXMgaW50ZWdyYXRlcz9cKS4gQXMgaXQgaXMsIGl0J3MgaW5zdWZmaWNpZW50LlxuKS9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDE5NiAwIFI+PgplbmRvYmoKMzk4IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTIwLjcyOCAzMDYuMzIx IDM3MC43MjggNDE4LjMyMV0vUGFyZW50IDQxMSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxOTYg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIwNCAw IFIKL0ZvbnQgMjA1IDAgUgo+Pi9Bbm5vdHMgNDEwIDAgUiAvQ29udGVudHMgMTk3IDAgUj4+CmVu ZG9iago0MTAgMCBvYmoKWzE5OSAwIFIKMjAwIDAgUgoyMDEgMCBSCjIwMiAwIFIKMjAzIDAgUiA0 MTEgMCBSIDM5OCAwIFJdCmVuZG9iago0MTMgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv Rm9ybS9Gb3JtVHlwZSAxL0JCb3hbMTQ2LjY2NyA2ODEuNDg0IDMyOS41MjkgNjkyLjU3Ml0vTWF0 cml4WzEgMCAwIDEgLTE0Ni42NjcgLTY4MS40ODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9S ZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4 dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4w MDAgcmcKMTQ2LjY2NyA2ODEuNDg0IG0KMzI5LjUyOSA2ODEuNDg0IGwKMzI5LjUyOSA2OTIuNTcy IGwKMTQ2LjY2NyA2OTIuNTcyIGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjQxNCAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzE0Ni42NjcgNjgxLjQ4NCAzMjku NTI5IDY5Mi41NzJdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMTQ2LjY2NyA2OTIu NTcyIDMyOS41MjkgNjkyLjU3MiAxNDYuNjY3IDY4MS40ODQgMzI5LjUyOSA2ODEuNDg0XS9BUDw8 L04gNDEzIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDIw NiAwIFI+PgplbmRvYmoKNDE1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9S ZWN0WzE0NC4yNzggNjg3LjU3MiAxNzQuMjc4IDcxNy41NzJdL05hbWUvQ29tbWVudC9DWzEuMDAw IDEuMDAwIDAuMDAwXS9Qb3B1cCA0MTYgMCBSL0NvbnRlbnRzKEluIHRoYXQgY2FzZSwgSSB3b3Vs ZCBzdWdnZXN0IHRoYXQgaXQgYmUgc3R1Y2sgaW50byBhbiBhcHBlbmRpeC4uLi4uKS9UKFRDbGF1 c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9QIDIwNiAwIFI+PgplbmRvYmoKNDE2IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTc5LjI3OCA2MDUuNTcy IDQyOS4yNzggNzE3LjU3Ml0vUGFyZW50IDQxNSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyMDYg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIxMSAw IFIKL0ZvbnQgMjEyIDAgUgo+Pi9Bbm5vdHMgNDEyIDAgUiAvQ29udGVudHMgMjA3IDAgUj4+CmVu ZG9iago0MTIgMCBvYmoKWzIwOSAwIFIKMjEwIDAgUiA0MTQgMCBSIDQxNSAwIFIgNDE2IDAgUl0K ZW5kb2JqCjQxNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyOTgu NzY1IDE4My4xMzAgMzI4Ljc2NSAyMTMuMTMwXS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAw LjAwMF0vUG9wdXAgMzQyIDAgUi9Db250ZW50cyhTdWJyZWdpc3RyeSBvZiB3aGF0P1xuXG5UaGVy ZSBhcmUsIGFzIEkgc2VlIGl0LCB0d28gZGlzdGluY3Qgb3B0aW9uczpcblxuQSByZWdpc3RyeSB1 bmRlciBNTEVcbkEgcmVnaXN0cnkgdW5kZXIgZWFjaCBjb21tYW5kIGNvZGUuXG5cbkl0IGlzIG5v dCBjbGVhciB0byBtZSB3aGF0IGl0IGlzLCBob3cgeW91IGRlZmluZSB5b3VyIG5hbWVzcGFjZSBo ZXJlLCBzbyB0aGlzIHNob3VsZCBiZSBjbGFyaWZpZWQuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEw MTgyMTM3MzIrMDknMDAnKS9QIDIyNiAwIFI+PgplbmRvYmoKMzQyIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzMzLjc2NSAxMDEuMTMwIDU4My43NjUgMjEzLjEz MF0vUGFyZW50IDQxNyAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMzIgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDMyNCAwIFIvUmVjdFsxNjMuMTk1IDcyNS40MDUg MTkzLjE5NSA3NTUuNDA1XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29udGVu dHMoUmVjb21tZW5kZWQgcmVhZGluZzogUkZDNTIyNi5cblxuQWxzbywgQXJlIHlvdSBzdXJlIHRo YXQgSUVURiByZXZpZXcgaXMgd2hhdCB5b3Ugd2FudCwgaXQgc2VlbXMgZmFpcmx5IHJlc3RyaWN0 aXZlIHRvIG1lIC0tIHdvdWxkIGFsbG9jYXRpbmcgYSBmZXcgY29kZS1wb2ludHMgYXMgImV4cGVy aW1lbnRhbCIgYW5kIGEgZ29vZCBsb3QgZm9yICJleHBlcnQgcmV2aWV3IiBcKHdpdGggcHJvcGVy IGd1aWRlbGluZXNcKSBub3QgYmUgYSBnb29kIGlkZWE/XG5cbkdlbmVyYWxseSwgYSBjb3VwbGUg b2YgY29kZS1wb2ludHMgZm9yIGV4cGVyaW1lbnRhbCB1c2UgaXMgYSBnb29kIHRoaW5nLiBcblxu SSBhbSBub3QgYSBzZWN1cml0eSB3b25rLCBzbyBJIGRvIG5vdCBrbm93IC0gYnV0IGFyZSBhbGwg c2VjdXJpdHkgcmVsYXRlZCBzdWl0ZXMgdHJhbnNsYXRlZCBpbnRvIFJGQ3MgXCh3aGljaCBhcmUg YSBuZWNlc3NhcnkgcHJlY29uZGl0aW9uIGZvciBJRVRGIFJldmlld1wpP1xuXG5GaW5hbGx5LCBJ IGhhdmUgZ2l2ZW4gY29tbWVudHMgdGhyb3VnaCB0aGUgSS1EIHRoYXQgaXQgaXMgZ3JlYXRseSBw cmVmZXJyZWQgdG8gZGVmaW5lIG1uZW1vbmljcyBmb3IgZWFjaCBjb2RlLXBvaW50LCBhbmQgdXNl IHRob3NlIHRocm91Z2ggdGhlIGRvY3VtZW50IC0gbGVhdmluZyBhY3R1YWwgbnVtYmVycyBmb3Ig SUFOQSB0byBtYW5hZ2UuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEwMTgyMTM3MzIrMDknMDAnKS9Q IDIyNiAwIFI+PgplbmRvYmoKMzI4IDAgb2JqClsyMjkgMCBSCjIzMCAwIFIKMjMxIDAgUgoyMzIg MCBSCjIzMyAwIFIgMzI5IDAgUiAzMTggMCBSIDMzMCAwIFIgMzIwIDAgUiAzMzEgMCBSIDMyMiAw IFIgMzMyIDAgUiAzMjQgMCBSIDQxNyAwIFIgMzQyIDAgUl0KZW5kb2JqCnhyZWYKMCAxCjAwMDAw MDAwMDAgNjU1MzUgZiAKMiAxCjAwMDAwNzc3MDggMDAwMDAgbiAKMTI3IDEKMDAwMDA3OTkyNSAw MDAwMCBuIAoxMzYgMQowMDAwMDg0MzE5IDAwMDAwIG4gCjE0NiAxCjAwMDAwODc2OTMgMDAwMDAg biAKMTU4IDEKMDAwMDA4OTkwNSAwMDAwMCBuIAoxNjQgMQowMDAwMDkyMjYyIDAwMDAwIG4gCjE3 MSAxCjAwMDAwOTQyNDYgMDAwMDAgbiAKMTc4IDEKMDAwMDA5NzExNCAwMDAwMCBuIAoxOTYgMQow MDAwMDk4NTQ5IDAwMDAwIG4gCjIwNiAxCjAwMDAwOTk4MDMgMDAwMDAgbiAKMjc2IDEKMDAwMDA3 Nzk4MSAwMDAwMCBuIAoyNzggMQowMDAwMDc5MTg3IDAwMDAwIG4gCjMyOCAxCjAwMDAxMDE0Nzgg MDAwMDAgbiAKMzMyIDg2CjAwMDAxMDA1ODYgMDAwMDAgbiAKMDAwMDA3ODEwNiAwMDAwMCBuIAow MDAwMDc5MDcxIDAwMDAwIG4gCjAwMDAwNzk4MDkgMDAwMDAgbiAKMDAwMDA4MDEwNSAwMDAwMCBu IAowMDAwMDc5MzE0IDAwMDAwIG4gCjAwMDAwODA0ODkgMDAwMDAgbiAKMDAwMDA4NDQ5OSAwMDAw MCBuIAowMDAwMDgwODU5IDAwMDAwIG4gCjAwMDAwODAxNzIgMDAwMDAgbiAKMDAwMDEwMDQ3MCAw MDAwMCBuIAowMDAwMDgxNjk0IDAwMDAwIG4gCjAwMDAwODA2MDUgMDAwMDAgbiAKMDAwMDA4MjEw NSAwMDAwMCBuIAowMDAwMDgwOTc1IDAwMDAwIG4gCjAwMDAwODI1NTcgMDAwMDAgbiAKMDAwMDA4 MTgxMCAwMDAwMCBuIAowMDAwMDgyMjIxIDAwMDAwIG4gCjAwMDAwODI2NzMgMDAwMDAgbiAKMDAw MDA4MzgzNiAwMDAwMCBuIAowMDAwMDgzMDMxIDAwMDAwIG4gCjAwMDAwODQyMDMgMDAwMDAgbiAK MDAwMDA4MzI4NSAwMDAwMCBuIAowMDAwMDgzOTUyIDAwMDAwIG4gCjAwMDAwODUwMzMgMDAwMDAg biAKMDAwMDA4Nzg3MyAwMDAwMCBuIAowMDAwMDg0Njc4IDAwMDAwIG4gCjAwMDAwODUxNDkgMDAw MDAgbiAKMDAwMDA4NjAxMiAwMDAwMCBuIAowMDAwMDg1NTExIDAwMDAwIG4gCjAwMDAwODYzOTYg MDAwMDAgbiAKMDAwMDA4NTc2OCAwMDAwMCBuIAowMDAwMDg2ODQ5IDAwMDAwIG4gCjAwMDAwODYx MjggMDAwMDAgbiAKMDAwMDA4NzIxMyAwMDAwMCBuIAowMDAwMDg2NTEyIDAwMDAwIG4gCjAwMDAw ODc1NzcgMDAwMDAgbiAKMDAwMDA4Njk2NSAwMDAwMCBuIAowMDAwMDg3MzI5IDAwMDAwIG4gCjAw MDAwODg0OTMgMDAwMDAgbiAKMDAwMDA5MDA4NSAwMDAwMCBuIAowMDAwMDg4ODQxIDAwMDAwIG4g CjAwMDAwODgwNTIgMDAwMDAgbiAKMDAwMDA4OTc4OSAwMDAwMCBuIAowMDAwMDg4NjA5IDAwMDAw IG4gCjAwMDAwODg5NTcgMDAwMDAgbiAKMDAwMDA5MDU3MSAwMDAwMCBuIAowMDAwMDkyNDQyIDAw MDAwIG4gCjAwMDAwOTAxNjAgMDAwMDAgbiAKMDAwMDA5Mjc5OCAwMDAwMCBuIAowMDAwMDkwNjg3 IDAwMDAwIG4gCjAwMDAwOTA5MDMgMDAwMDAgbiAKMDAwMDA5MTAxOCAwMDAwMCBuIAowMDAwMDkz NzcwIDAwMDAwIG4gCjAwMDAwOTE0NTAgMDAwMDAgbiAKMDAwMDA5MTc2OCAwMDAwMCBuIAowMDAw MDkyMTQ3IDAwMDAwIG4gCjAwMDAwOTQ0MjYgMDAwMDAgbiAKMDAwMDA5MjUzMyAwMDAwMCBuIAow MDAwMDkyOTE0IDAwMDAwIG4gCjAwMDAwOTMyNzYgMDAwMDAgbiAKMDAwMDA5MzUzMyAwMDAwMCBu IAowMDAwMDkzODg2IDAwMDAwIG4gCjAwMDAwOTQxMzEgMDAwMDAgbiAKMDAwMDA5NzI5NCAwMDAw MCBuIAowMDAwMDk0NTE3IDAwMDAwIG4gCjAwMDAwOTg0MzMgMDAwMDAgbiAKMDAwMDA5NDc2OCAw MDAwMCBuIAowMDAwMDk0ODg0IDAwMDAwIG4gCjAwMDAwOTUxNDggMDAwMDAgbiAKMDAwMDA5NTI2 NCAwMDAwMCBuIAowMDAwMDk1NTYwIDAwMDAwIG4gCjAwMDAwOTU2NzYgMDAwMDAgbiAKMDAwMDA5 NTk0NiAwMDAwMCBuIAowMDAwMDk2MDYyIDAwMDAwIG4gCjAwMDAwOTY0MjQgMDAwMDAgbiAKMDAw MDA5NjY4MSAwMDAwMCBuIAowMDAwMDk2OTk4IDAwMDAwIG4gCjAwMDAwOTg3MjkgMDAwMDAgbiAK MDAwMDA5NzQ1NyAwMDAwMCBuIAowMDAwMDk5OTgzIDAwMDAwIG4gCjAwMDAwOTg4MDQgMDAwMDAg biAKMDAwMDA5OTE2NiAwMDAwMCBuIAowMDAwMDk5NDIzIDAwMDAwIG4gCjAwMDAwOTk2ODcgMDAw MDAgbiAKMDAwMDEwMDA0MiAwMDAwMCBuIAp0cmFpbGVyCjw8L1NpemUgNDE4L1ByZXYgNzYyMTQv Um9vdCAxIDAgUi9JbmZvIDIgMCBSL0lEWzw4Q0Y3QUFBQjUyNTAzQjQwNkI2MjgyQzgyMkFDMDc0 MT48N0Q2Nzc1RkZDOEVBODc5OTYwRDlERjAwRTA1NzUwRjM+XT4+CnN0YXJ0eHJlZgoxMDE2MTcK JSVFT0YKCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDIpCi9DcmVhdGlv bkRhdGUoRDoyMDEyMDYyODIwMjgyMyswMicwMCcpL0NyZWF0b3IoaHRtbDJwcyB2ZXJzaW9uIDEu MCBiZXRhNykKL0F1dGhvcigpCi9LZXl3b3JkcygpCi9TdWJqZWN0KCkKL1RpdGxlKGRyYWZ0LWtl bHNleS1pbnRhcmVhLW1lc2gtbGluay1lc3RhYmxpc2htZW50LTA0IC0gTWVzaCBMaW5rIEVzdGFi bGlzaG1lbnQpL01vZERhdGUoRDoyMDEyMTAyMjIwMDYxNCswMicwMCcpPj4KZW5kb2JqCjI3NiAw IG9iagpbMzE3MSAzIDU4NzgzIDU4Nzc3IDUzMTA3IDU4NzcxIDU4NzgzIDU4Nzc3IDUzMTA3IDU4 NzcxIDEwMTYxNyA8NEM0OUFDMUFEQTEwQzc4MkFFNzc4OUZFN0MwMjBBMEM+IDEgMCAwIDAgMF0K ZW5kb2JqCjMwMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMzAz IDAgUi9SZWN0WzQxMS4zNDQgMjA5Ljg5MCA0NDEuMzQ0IDIzOS44OTBdL05hbWUvQ29tbWVudC9D WzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhTbyB0aGlzIHNvdW5kcyBsaWtlIGEgY2hhbm5l bC1lc3RpbWF0aW9uIHByb3RvY29sIG9mIHNvcnRzLiBJcyB0aGF0IHJlbGF0ZWQgdG8gdGhlIEVU eCBlc3RpbWF0aW9ucz8gXG5cbkkgcmVtZW1iZXIgb24gbWFuZXRAaWV0ZiB0aGF0IHRoZXJlIGhh cyBiZWVuIHNvbWUgY29udGVudGlvbiBhcyB0byB3aGF0IHRoZSBwcm9wZXIgaW5mb3JtYXRpb24g ZXhjaGFuZ2UgaXMgZm9yIGV2YWx1YXRpbmcgc3VjaCwgaGFzIHRoaXMgYmVlbiByZWZsZWN0ZWQ/ XG4pL1QoVENsYXVzZW4pL00oRDoyMDEyMTAyMjIwMDYxNCswMicwMCcpL1AgODUgMCBSPj4KZW5k b2JqCjM0MSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMzM4IDAg Ui9SZWN0WzEwMC4xMzkgNzI1LjQwNSAxMzAuMTM5IDc1NS40MDVdL05hbWUvQ29tbWVudC9DWzEu MDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhUaGlzIGlzIGluY29oZXJlbnQuIFRoZSBzZWN0aW9u IGlzIGVudGl0bGVkICJ2YWx1ZXMiLCB5ZXQgdGhlIGNvbnRlbnQgaXMgdGhlIFRMViBmb3JtYXQu IFN1Z2dlc3QgY2hhbmdpbmcgdG8gIlRMViBGb3JtYXQiKS9UKFRDbGF1c2VuKS9NKEQ6MjAxMjEw MjIyMDA2MTQrMDInMDAnKS9QIDEzNiAwIFI+PgplbmRvYmoKeHJlZgowIDEKMDAwMDAwMDAwMCA2 NTUzNSBmIAoyIDEKMDAwMDEwMzg2MSAwMDAwMCBuIAoyNzYgMQowMDAwMTA0MTM0IDAwMDAwIG4g CjMwMiAxCjAwMDAxMDQyNjAgMDAwMDAgbiAKMzQxIDEKMDAwMDEwNDcxMyAwMDAwMCBuIAp0cmFp bGVyCjw8L1NpemUgNDE4L1ByZXYgMTAxNjE3L1Jvb3QgMSAwIFIvSW5mbyAyIDAgUi9JRFs8OENG N0FBQUI1MjUwM0I0MDZCNjI4MkM4MjJBQzA3NDE+PDQxOTZFQzkwMTc4Q0IyRUY1QjBDNTc3NzFG OEJBQUQwPl0+PgpzdGFydHhyZWYKMTA1MDMwCiUlRU9GCgoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQ TCBHaG9zdHNjcmlwdCA5LjAyKQovQ3JlYXRpb25EYXRlKEQ6MjAxMjA2MjgyMDI4MjMrMDInMDAn KS9DcmVhdG9yKGh0bWwycHMgdmVyc2lvbiAxLjAgYmV0YTcpCi9BdXRob3IoKQovS2V5d29yZHMo KQovU3ViamVjdCgpCi9UaXRsZShkcmFmdC1rZWxzZXktaW50YXJlYS1tZXNoLWxpbmstZXN0YWJs aXNobWVudC0wNCAtIE1lc2ggTGluayBFc3RhYmxpc2htZW50KS9Nb2REYXRlKEQ6MjAxMjEwMjIy MDA3NDcrMDInMDAnKT4+CmVuZG9iagoyNzYgMCBvYmoKWzMxNzEgMyA1ODc4MyA1ODc3NyA1MzEw NyA1ODc3MSA1ODc4MyA1ODc3NyA1MzEwNyA1ODc3MSAxMDUwMzAgPDkyMTQzREIyMDAyQUZDMEI1 QTAzQ0E1OEMyNUY5NzAzPiAyIDAgMTA1MzEzIDEwNTMwNyAxMDUzMDBdCmVuZG9iago0MTggMCBv YmoKPDwvTGVuZ3RoIDI+PnN0cmVhbQpxCgplbmRzdHJlYW0KZW5kb2JqCjQxOSAwIG9iago8PC9M ZW5ndGggMj4+c3RyZWFtClEKCmVuZHN0cmVhbQplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyA0 MjUgMCBSIC9Bbm5vdHMgMjc4IDAgUi9Db250ZW50c1s0MTggMCBSIDUgMCBSIDQxOSAwIFIgNDI0 IDAgUl0+PgplbmRvYmoKMjc4IDAgb2JqClsxMCAwIFIgMTEgMCBSIDEyIDAgUiAxMyAwIFIgNDIw IDAgUiA0MjEgMCBSIDQyMiAwIFIgNDIzIDAgUl0KZW5kb2JqCjg1IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2Vz IDQzMyAwIFIgL0Fubm90cyAyODkgMCBSL0NvbnRlbnRzWzQxOCAwIFIgODYgMCBSIDQxOSAwIFIg NDMyIDAgUl0+PgplbmRvYmoKMjg5IDAgb2JqCls4OCAwIFIgODkgMCBSIDkwIDAgUiA5MSAwIFIg OTIgMCBSIDkzIDAgUiA0MjYgMCBSIDQyNyAwIFIgNDI4IDAgUiA0MjkgMCBSIDQzMCAwIFIgNDMx IDAgUl0KZW5kb2JqCjEwNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyA0MzYgMCBSIC9Bbm5vdHMgMzEyIDAg Ui9Db250ZW50c1s0MTggMCBSIDEwNSAwIFIgNDE5IDAgUiA0MzUgMCBSXT4+CmVuZG9iagozMTIg MCBvYmoKWzEwNyAwIFIgMTA4IDAgUiA0MzQgMCBSXQplbmRvYmoKMTExIDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3Vy Y2VzIDQ0MiAwIFIgL0Fubm90cyAzMTQgMCBSL0NvbnRlbnRzWzQxOCAwIFIgMTEyIDAgUiA0MTkg MCBSIDQ0MSAwIFJdPj4KZW5kb2JqCjMxNCAwIG9iagpbMTE0IDAgUiAxMTUgMCBSIDExNiAwIFIg MTE3IDAgUiAxMTggMCBSIDExOSAwIFIgMTIwIDAgUiAxMjEgMCBSIDEyMiAwIFIgMTIzIDAgUiAx MjQgMCBSIDQzNyAwIFIgNDM4IDAgUiA0MzkgMCBSIDQ0MCAwIFJdCmVuZG9iagoxMjcgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg Ui9SZXNvdXJjZXMgNDQ1IDAgUiAvQW5ub3RzIDMzNiAwIFIvQ29udGVudHNbNDE4IDAgUiAxMjgg MCBSIDQxOSAwIFIgNDQ0IDAgUl0+PgplbmRvYmoKMzM2IDAgb2JqClsxMzAgMCBSIDEzMSAwIFIg MTMyIDAgUiAxMzMgMCBSIDQ0MyAwIFJdCmVuZG9iagoxMzYgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNDU0 IDAgUiAvQW5ub3RzIDMzOSAwIFIvQ29udGVudHNbNDE4IDAgUiAxMzcgMCBSIDQxOSAwIFIgNDUz IDAgUl0+PgplbmRvYmoKMzM5IDAgb2JqClsxMzkgMCBSIDE0MCAwIFIgMTQxIDAgUiAxNDIgMCBS IDE0MyAwIFIgNDQ2IDAgUiA0NDcgMCBSIDQ0OCAwIFIgNDQ5IDAgUiA0NTAgMCBSIDQ1MSAwIFIg NDUyIDAgUl0KZW5kb2JqCjE0NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyA0NjIgMCBSIC9Bbm5vdHMgMzU3 IDAgUi9Db250ZW50c1s0MTggMCBSIDE0NyAwIFIgNDE5IDAgUiA0NjEgMCBSXT4+CmVuZG9iagoz NTcgMCBvYmoKWzE0OSAwIFIgMTUwIDAgUiAxNTEgMCBSIDE1MiAwIFIgMTUzIDAgUiAxNTQgMCBS IDE1NSAwIFIgNDU1IDAgUiA0NTYgMCBSIDQ1NyAwIFIgNDU4IDAgUiA0NTkgMCBSIDQ2MCAwIFJd CmVuZG9iagoxNTggMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgNDY3IDAgUiAvQW5ub3RzIDM3MiAwIFIvQ29u dGVudHNbNDE4IDAgUiAxNTkgMCBSIDQxOSAwIFIgNDY2IDAgUl0+PgplbmRvYmoKMzcyIDAgb2Jq ClsxNjEgMCBSIDQ2MyAwIFIgNDY0IDAgUiA0NjUgMCBSXQplbmRvYmoKMTY0IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVz b3VyY2VzIDQ3MiAwIFIgL0Fubm90cyAzNzkgMCBSL0NvbnRlbnRzWzQxOCAwIFIgMTY1IDAgUiA0 MTkgMCBSIDQ3MSAwIFJdPj4KZW5kb2JqCjM3OSAwIG9iagpbMTY3IDAgUiAxNjggMCBSIDQ2OCAw IFIgNDY5IDAgUiA0NzAgMCBSXQplbmRvYmoKMTcxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDQ3NyAwIFIg L0Fubm90cyAzODkgMCBSL0NvbnRlbnRzWzQxOCAwIFIgMTcyIDAgUiA0MTkgMCBSIDQ3NiAwIFJd Pj4KZW5kb2JqCjM4OSAwIG9iagpbMTc0IDAgUiAxNzUgMCBSIDQ3MyAwIFIgNDc0IDAgUiA0NzUg MCBSXQplbmRvYmoKMTc4IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDQ4NCAwIFIgL0Fubm90cyAzOTYgMCBS L0NvbnRlbnRzWzQxOCAwIFIgMTc5IDAgUiA0MTkgMCBSIDQ4MyAwIFJdPj4KZW5kb2JqCjM5NiAw IG9iagpbMTgxIDAgUiAxODIgMCBSIDE4MyAwIFIgMTg0IDAgUiAxODUgMCBSIDE4NiAwIFIgMTg3 IDAgUiA0NzggMCBSIDQ3OSAwIFIgNDgwIDAgUiA0ODEgMCBSIDQ4MiAwIFJdCmVuZG9iagoxOTYg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUi9SZXNvdXJjZXMgNDg3IDAgUiAvQW5ub3RzIDQxMCAwIFIvQ29udGVudHNbNDE4IDAg UiAxOTcgMCBSIDQxOSAwIFIgNDg2IDAgUl0+PgplbmRvYmoKNDEwIDAgb2JqClsxOTkgMCBSIDIw MCAwIFIgMjAxIDAgUiAyMDIgMCBSIDIwMyAwIFIgNDg1IDAgUl0KZW5kb2JqCjIwNiAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS L1Jlc291cmNlcyA0OTAgMCBSIC9Bbm5vdHMgNDEyIDAgUi9Db250ZW50c1s0MTggMCBSIDIwNyAw IFIgNDE5IDAgUiA0ODkgMCBSXT4+CmVuZG9iago0MTIgMCBvYmoKWzIwOSAwIFIgMjEwIDAgUiA0 ODggMCBSXQplbmRvYmoKMjI2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDQ5NyAwIFIgL0Fubm90cyAzMjgg MCBSL0NvbnRlbnRzWzQxOCAwIFIgMjI3IDAgUiA0MTkgMCBSIDQ5NiAwIFJdPj4KZW5kb2JqCjMy OCAwIG9iagpbMjI5IDAgUiAyMzAgMCBSIDIzMSAwIFIgMjMyIDAgUiAyMzMgMCBSIDQ5MSAwIFIg NDkyIDAgUiA0OTMgMCBSIDQ5NCAwIFIgNDk1IDAgUl0KZW5kb2JqCjQ5OSAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDcwMS4wMDAgODUu MDE1IDcyMi4wMDBdL0Rlc3RbNCAwIFIgL1hZWiAwLjAwMCA2MzIuNzAwIDBdPj4KZW5kb2JqCjQy MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4w MDAgNjExLjcwMCAyNS40NTMgNjMyLjcwMF0vRGVzdFs0OTggMCBSIC9YWVogNjAuNTYyIDcyMi4w MDAgMF0+PgplbmRvYmoKNTAwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl clswIDAgMF0vUmVjdFs2MC41NjIgNTMyLjUwMCA4NS4wMTUgNTUzLjUwMF0vRGVzdFs0IDAgUiAv WFlaIDAuMDAwIDgxNC44MDMgMF0+PgplbmRvYmoKNDIxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA3OTMuODAzIDI1LjQ1MyA4MTQuODAz XS9EZXN0WzQ5OCAwIFIgL1hZWiA2MC41NjIgNTUzLjUwMCAwXT4+CmVuZG9iago1MDEgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA0ODQu MDAwIDg1LjAxNSA1MDUuMDAwXS9EZXN0WzQgMCBSIC9YWVogNTY5LjU0NyA1MjYuNjE0IDBdPj4K ZW5kb2JqCjQyMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbNTY5LjU0NyA1MDUuNjE0IDU5NS4wMDAgNTI2LjYxNF0vRGVzdFs0OTggMCBSIC9YWVog NjAuNTYyIDUwNS4wMDAgMF0+PgplbmRvYmoKNTAyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMzg3LjUwMCA4NS4wMTUgNDA4LjUwMF0v RGVzdFs0IDAgUiAvWFlaIDAuMDAwIDc0MS4xMjMgMF0+PgplbmRvYmoKNDIzIDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA3MjAuMTIzIDI1 LjQ1MyA3NDEuMTIzXS9EZXN0WzQ5OCAwIFIgL1hZWiA2MC41NjIgNDA4LjUwMCAwXT4+CmVuZG9i ago1MDQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzYwLjU2MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0Wzg1IDAgUiAvWFlaIDU2OS41NDcg NTY0LjQ5OSAwXT4+CmVuZG9iago0MjYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzU2OS41NDcgNTQzLjQ5OSA1OTUuMDAwIDU2NC40OTldL0Rlc3Rb NTAzIDAgUiAvWFlaIDYwLjU2MiA3MjIuMDAwIDBdPj4KZW5kb2JqCjUwNSAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDU4MC41MDAgODUu MDE1IDYwMS41MDBdL0Rlc3RbODUgMCBSIC9YWVogMC4wMDAgNTEzLjI0MiAwXT4+CmVuZG9iago0 MjcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAu MDAwIDQ5Mi4yNDIgMjUuNDUzIDUxMy4yNDJdL0Rlc3RbNTAzIDAgUiAvWFlaIDYwLjU2MiA2MDEu NTAwIDBdPj4KZW5kb2JqCjUwNiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk ZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDQ3Mi4wMDAgODUuMDE1IDQ5My4wMDBdL0Rlc3RbODUgMCBS IC9YWVogNTY5LjU0NyA1MjMuOTg2IDBdPj4KZW5kb2JqCjQyOCAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTY5LjU0NyA1MDIuOTg2IDU5NS4wMDAg NTIzLjk4Nl0vRGVzdFs1MDMgMCBSIC9YWVogNjAuNTYyIDQ5My4wMDAgMF0+PgplbmRvYmoKNTA3 IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41 NjIgNDM1LjUwMCA4NS4wMTUgNDU2LjUwMF0vRGVzdFs4NSAwIFIgL1hZWiA1NjkuNTQ3IDI1My45 MTQgMF0+PgplbmRvYmoKNDI5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl clswIDAgMF0vUmVjdFs1NjkuNTQ3IDIzMi45MTQgNTk1LjAwMCAyNTMuOTE0XS9EZXN0WzUwMyAw IFIgL1hZWiA2MC41NjIgNDU2LjUwMCAwXT4+CmVuZG9iago1MDggMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAzNjMuMDAwIDg1LjAxNSAz ODQuMDAwXS9EZXN0Wzg1IDAgUiAvWFlaIDAuMDAwIDI5NS45NTYgMF0+PgplbmRvYmoKNDMwIDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAy NzQuOTU2IDI1LjQ1MyAyOTUuOTU2XS9EZXN0WzUwMyAwIFIgL1hZWiA2MC41NjIgMzg0LjAwMCAw XT4+CmVuZG9iago1MDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzYwLjU2MiAzMjYuNTAwIDg1LjAxNSAzNDcuNTAwXS9EZXN0Wzg1IDAgUiAvWFla IDAuMDAwIDI3NC45NTYgMF0+PgplbmRvYmoKNDMxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAyNTMuOTU2IDI1LjQ1MyAyNzQuOTU2XS9E ZXN0WzUwMyAwIFIgL1hZWiA2MC41NjIgMzQ3LjUwMCAwXT4+CmVuZG9iago1MTAgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAyNzguMDAw IDg1LjAxNSAyOTkuMDAwXS9EZXN0WzEwNCAwIFIgL1hZWiAwLjAwMCA0ODcuNzY3IDBdPj4KZW5k b2JqCjQzNCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1Jl Y3RbMC4wMDAgNDY2Ljc2NyAyNS40NTMgNDg3Ljc2N10vRGVzdFs1MDMgMCBSIC9YWVogNjAuNTYy IDI5OS4wMDAgMF0+PgplbmRvYmoKNTExIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMTA5LjUwMCA4NS4wMTUgMTMwLjUwMF0vRGVzdFsx MTEgMCBSIC9YWVogMC4wMDAgNjc0LjUzNyAwXT4+CmVuZG9iago0MzcgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDY1My41MzcgMjUuNDUz IDY3NC41MzddL0Rlc3RbNTAzIDAgUiAvWFlaIDYwLjU2MiAxMzAuNTAwIDBdPj4KZW5kb2JqCjUx MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAu NTYyIDcwMS4wMDAgODUuMDE1IDcyMi4wMDBdL0Rlc3RbMTExIDAgUiAvWFlaIDAuMDAwIDU2NS40 MzEgMF0+PgplbmRvYmoKNDM4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl clswIDAgMF0vUmVjdFswLjAwMCA1NDQuNDMxIDI1LjQ1MyA1NjUuNDMxXS9EZXN0WzUxMiAwIFIg L1hZWiA2MC41NjIgNzIyLjAwMCAwXT4+CmVuZG9iago1MTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA2MjguNTAwIDg1LjAxNSA2NDku NTAwXS9EZXN0WzExMSAwIFIgL1hZWiAwLjAwMCA0MzQuOTI4IDBdPj4KZW5kb2JqCjQzOSAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNDEz LjkyOCAyNS40NTMgNDM0LjkyOF0vRGVzdFs1MTIgMCBSIC9YWVogNjAuNTYyIDY0OS41MDAgMF0+ PgplbmRvYmoKNTE1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAg MF0vUmVjdFs2MC41NjIgNTkyLjAwMCA4NS4wMTUgNjEzLjAwMF0vRGVzdFsxMTEgMCBSIC9YWVog MC4wMDAgMzE2LjU0MSAwXT4+CmVuZG9iago0NDAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDI5NS41NDEgMjUuNDUzIDMxNi41NDFdL0Rl c3RbNTEyIDAgUiAvWFlaIDYwLjU2MiA2MTMuMDAwIDBdPj4KZW5kb2JqCjUxNiAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDU1NS41MDAg ODUuMDE1IDU3Ni41MDBdL0Rlc3RbMTI3IDAgUiAvWFlaIDAuMDAwIDU2NC41NjkgMF0+PgplbmRv YmoKNDQzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVj dFswLjAwMCA1NDMuNTY5IDI1LjQ1MyA1NjQuNTY5XS9EZXN0WzUxMiAwIFIgL1hZWiA2MC41NjIg NTc2LjUwMCAwXT4+CmVuZG9iago1MTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA0NTkuMDAwIDg1LjAxNSA0ODAuMDAwXS9EZXN0WzEz NiAwIFIgL1hZWiAwLjAwMCA3NjUuNjgzIDBdPj4KZW5kb2JqCjQ0NiAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNzQ0LjY4MyAyNS40NTMg NzY1LjY4M10vRGVzdFs1MTIgMCBSIC9YWVogNjAuNTYyIDQ4MC4wMDAgMF0+PgplbmRvYmoKNTE4 IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41 NjIgNDEwLjUwMCA4NS4wMTUgNDMxLjUwMF0vRGVzdFsxMzYgMCBSIC9YWVogMC4wMDAgNTg4LjI0 NiAwXT4+CmVuZG9iago0NDcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVy WzAgMCAwXS9SZWN0WzAuMDAwIDU2Ny4yNDYgMjUuNDUzIDU4OC4yNDZdL0Rlc3RbNTEyIDAgUiAv WFlaIDYwLjU2MiA0MzEuNTAwIDBdPj4KZW5kb2JqCjUxOSAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDM3NC4wMDAgODUuMDE1IDM5NS4w MDBdL0Rlc3RbMTM2IDAgUiAvWFlaIDAuMDAwIDUwMS4wNzMgMF0+PgplbmRvYmoKNDQ4IDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA0ODAu MDczIDI1LjQ1MyA1MDEuMDczXS9EZXN0WzUxMiAwIFIgL1hZWiA2MC41NjIgMzk1LjAwMCAwXT4+ CmVuZG9iago1MjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzYwLjU2MiAyNTMuNTAwIDg1LjAxNSAyNzQuNTAwXS9EZXN0WzEzNiAwIFIgL1hZWiAw LjAwMCA0MTUuNDQzIDBdPj4KZW5kb2JqCjQ0OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgMzk0LjQ0MyAyNS40NTMgNDE1LjQ0M10vRGVz dFs1MTIgMCBSIC9YWVogNjAuNTYyIDI3NC41MDAgMF0+PgplbmRvYmoKNTIxIDAgb2JqCjw8L1R5 cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMjE3LjAwMCA4 NS4wMTUgMjM4LjAwMF0vRGVzdFsxMzYgMCBSIC9YWVogMC4wMDAgMzYzLjIzNiAwXT4+CmVuZG9i ago0NTAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzAuMDAwIDM0Mi4yMzYgMjUuNDUzIDM2My4yMzZdL0Rlc3RbNTEyIDAgUiAvWFlaIDYwLjU2MiAy MzguMDAwIDBdPj4KZW5kb2JqCjUyMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDE2OC41MDAgODUuMDE1IDE4OS41MDBdL0Rlc3RbMTM2 IDAgUiAvWFlaIDAuMDAwIDMyMi45NDEgMF0+PgplbmRvYmoKNDUxIDAgb2JqCjw8L1R5cGUvQW5u b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAzMDEuOTQxIDI1LjQ1MyAz MjIuOTQxXS9EZXN0WzUxMiAwIFIgL1hZWiA2MC41NjIgMTg5LjUwMCAwXT4+CmVuZG9iago1MjQg MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2 MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzEzNiAwIFIgL1hZWiAwLjAwMCAyNjIuMzQ1 IDBdPj4KZW5kb2JqCjQ1MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJb MCAwIDBdL1JlY3RbMC4wMDAgMjQxLjM0NSAyNS40NTMgMjYyLjM0NV0vRGVzdFs1MjMgMCBSIC9Y WVogNjAuNTYyIDcyMi4wMDAgMF0+PgplbmRvYmoKNTI1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgNjY0LjUwMCA4NS4wMTUgNjg1LjUw MF0vRGVzdFsxNDYgMCBSIC9YWVogMC4wMDAgNzY3LjIyOCAwXT4+CmVuZG9iago0NTUgMCBvYmoK PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDc0Ni4y MjggMjUuNDUzIDc2Ny4yMjhdL0Rlc3RbNTIzIDAgUiAvWFlaIDYwLjU2MiA2ODUuNTAwIDBdPj4K ZW5kb2JqCjUyNiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbNjAuNTYyIDYxNi4wMDAgODUuMDE1IDYzNy4wMDBdL0Rlc3RbMTQ2IDAgUiAvWFlaIDAu MDAwIDY5My41NDggMF0+PgplbmRvYmoKNDU2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M aW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA2NzIuNTQ4IDI1LjQ1MyA2OTMuNTQ4XS9EZXN0 WzUyMyAwIFIgL1hZWiA2MC41NjIgNjM3LjAwMCAwXT4+CmVuZG9iago1MjcgMCBvYmoKPDwvVHlw ZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA1NzkuNTAwIDg1 LjAxNSA2MDAuNTAwXS9EZXN0WzE0NiAwIFIgL1hZWiA1NjkuNTQ3IDY5Ny44OTIgMF0+PgplbmRv YmoKNDU3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVj dFs1NjkuNTQ3IDY3Ni44OTIgNTk1LjAwMCA2OTcuODkyXS9EZXN0WzUyMyAwIFIgL1hZWiA2MC41 NjIgNjAwLjUwMCAwXT4+CmVuZG9iago1MjggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA1NDMuMDAwIDg1LjAxNSA1NjQuMDAwXS9EZXN0 WzE0NiAwIFIgL1hZWiAwLjAwMCA1NTkuMTU3IDBdPj4KZW5kb2JqCjQ1OCAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNTM4LjE1NyAyNS40 NTMgNTU5LjE1N10vRGVzdFs1MjMgMCBSIC9YWVogNjAuNTYyIDU2NC4wMDAgMF0+PgplbmRvYmoK NTI5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2 MC41NjIgNDk0LjUwMCA4NS4wMTUgNTE1LjUwMF0vRGVzdFsxNDYgMCBSIC9YWVogMC4wMDAgNDUw LjIyNCAwXT4+CmVuZG9iago0NTkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9y ZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDQyOS4yMjQgMjUuNDUzIDQ1MC4yMjRdL0Rlc3RbNTIzIDAg UiAvWFlaIDYwLjU2MiA1MTUuNTAwIDBdPj4KZW5kb2JqCjUzMCAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDQ1OC4wMDAgODUuMDE1IDQ3 OS4wMDBdL0Rlc3RbMTQ2IDAgUiAvWFlaIDAuMDAwIDM3OC4wNTEgMF0+PgplbmRvYmoKNDYwIDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAz NTcuMDUxIDI1LjQ1MyAzNzguMDUxXS9EZXN0WzUyMyAwIFIgL1hZWiA2MC41NjIgNDc5LjAwMCAw XT4+CmVuZG9iago1MzEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzU1LjAwMCA0MjEuNTAwIDg1LjAxNSA0NDIuNTAwXS9EZXN0WzE1OCAwIFIgL1hZ WiAwLjAwMCA2NzMuMjM0IDBdPj4KZW5kb2JqCjQ2MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNjUyLjIzNCAzMS4wMTUgNjczLjIzNF0v RGVzdFs1MjMgMCBSIC9YWVogNTUuMDAwIDQ0Mi41MDAgMF0+PgplbmRvYmoKNTMyIDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgMzQ5LjAw MCA4NS4wMTUgMzcwLjAwMF0vRGVzdFsxNTggMCBSIC9YWVogNTYzLjk4NSA2MTkuODUwIDBdPj4K ZW5kb2JqCjQ2NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbNTYzLjk4NSA1OTguODUwIDU5NS4wMDAgNjE5Ljg1MF0vRGVzdFs1MjMgMCBSIC9YWVog NTUuMDAwIDM3MC4wMDAgMF0+PgplbmRvYmoKNTMzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgMzEyLjUwMCA4NS4wMTUgMzMzLjUwMF0v RGVzdFsxNTggMCBSIC9YWVogMC4wMDAgNTMxLjg2NCAwXT4+CmVuZG9iago0NjUgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDUxMC44NjQg MzEuMDE1IDUzMS44NjRdL0Rlc3RbNTIzIDAgUiAvWFlaIDU1LjAwMCAzMzMuNTAwIDBdPj4KZW5k b2JqCjUzNCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1Jl Y3RbNTUuNzM3IDE2OC4wMDAgODUuMDE1IDE4OS4wMDBdL0Rlc3RbMTY0IDAgUiAvWFlaIDU2NC43 MjMgMjg0LjUxMSAwXT4+CmVuZG9iago0NjggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU2NC43MjMgMjYzLjUxMSA1OTUuMDAwIDI4NC41MTFdL0Rl c3RbNTIzIDAgUiAvWFlaIDU1LjczNyAxODkuMDAwIDBdPj4KZW5kb2JqCjUzNSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuNzM3IDk1LjUwMCA4 NS4wMTUgMTE2LjUwMF0vRGVzdFsxNjQgMCBSIC9YWVogMC4wMDAgMjE3LjA4MSAwXT4+CmVuZG9i ago0NjkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzAuMDAwIDE5Ni4wODEgMzAuMjc3IDIxNy4wODFdL0Rlc3RbNTIzIDAgUiAvWFlaIDU1LjczNyAx MTYuNTAwIDBdPj4KZW5kb2JqCjUzNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNTUuNzM3IDcwMS4wMDAgODUuMDE1IDcyMi4wMDBdL0Rlc3RbMTY0 IDAgUiAvWFlaIDU2NC43MjMgMjA3LjQ5MCAwXT4+CmVuZG9iago0NzAgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU2NC43MjMgMTg2LjQ5MCA1OTUu MDAwIDIwNy40OTBdL0Rlc3RbNTM2IDAgUiAvWFlaIDU1LjczNyA3MjIuMDAwIDBdPj4KZW5kb2Jq CjUzOCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb NTUuMDAwIDYyOC41MDAgODUuMDE1IDY0OS41MDBdL0Rlc3RbMTcxIDAgUiAvWFlaIDAuMDAwIDc1 Mi42NTAgMF0+PgplbmRvYmoKNDczIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv cmRlclswIDAgMF0vUmVjdFswLjAwMCA3MzEuNjUwIDMxLjAxNSA3NTIuNjUwXS9EZXN0WzUzNiAw IFIgL1hZWiA1NS4wMDAgNjQ5LjUwMCAwXT4+CmVuZG9iago1MzkgMCBvYmoKPDwvVHlwZS9Bbm5v dC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA1OTIuMDAwIDg1LjAxNSA2 MTMuMDAwXS9EZXN0WzE3MSAwIFIgL1hZWiAwLjAwMCA2OTAuNzMwIDBdPj4KZW5kb2JqCjQ3NCAw IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAg NjY5LjczMCAzMS4wMTUgNjkwLjczMF0vRGVzdFs1MzYgMCBSIC9YWVogNTUuMDAwIDYxMy4wMDAg MF0+PgplbmRvYmoKNTQwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw IDAgMF0vUmVjdFs1NS4wMDAgNTU1LjUwMCA4NS4wMTUgNTc2LjUwMF0vRGVzdFsxNzEgMCBSIC9Y WVogMC4wMDAgNTg1Ljg2OSAwXT4+CmVuZG9iago0NzUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDU2NC44NjkgMzEuMDE1IDU4NS44Njld L0Rlc3RbNTM2IDAgUiAvWFlaIDU1LjAwMCA1NzYuNTAwIDBdPj4KZW5kb2JqCjU0MSAwIG9iago8 PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDUxOS4w MDAgODUuMDE1IDU0MC4wMDBdL0Rlc3RbMTc4IDAgUiAvWFlaIDAuMDAwIDY0Ni42ODcgMF0+Pgpl bmRvYmoKNDc4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFswLjAwMCA2MjUuNjg3IDMxLjAxNSA2NDYuNjg3XS9EZXN0WzUzNiAwIFIgL1hZWiA1NS4w MDAgNTQwLjAwMCAwXT4+CmVuZG9iago1NDIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA0ODIuNTAwIDg1LjAxNSA1MDMuNTAwXS9EZXN0 WzE3OCAwIFIgL1hZWiAwLjAwMCA3MzAuOTg5IDBdPj4KZW5kb2JqCjQ3OSAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNzA5Ljk4OSAzMS4w MTUgNzMwLjk4OV0vRGVzdFs1MzYgMCBSIC9YWVogNTUuMDAwIDUwMy41MDAgMF0+PgplbmRvYmoK NTQzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1 NS4wMDAgNDQ2LjAwMCA4NS4wMTUgNDY3LjAwMF0vRGVzdFsxNzggMCBSIC9YWVogMC4wMDAgNzUx Ljk4OSAwXT4+CmVuZG9iago0ODAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9y ZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDczMC45ODkgMzEuMDE1IDc1MS45ODldL0Rlc3RbNTM2IDAg UiAvWFlaIDU1LjAwMCA0NjcuMDAwIDBdPj4KZW5kb2JqCjU0NCAwIG9iago8PC9UeXBlL0Fubm90 L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDQwOS41MDAgODUuMDE1IDQz MC41MDBdL0Rlc3RbMTc4IDAgUiAvWFlaIDAuMDAwIDY5Ni40NjkgMF0+PgplbmRvYmoKNDgxIDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA2 NzUuNDY5IDMxLjAxNSA2OTYuNDY5XS9EZXN0WzUzNiAwIFIgL1hZWiA1NS4wMDAgNDMwLjUwMCAw XT4+CmVuZG9iago1NDUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzU1LjAwMCAzNzMuMDAwIDg1LjAxNSAzOTQuMDAwXS9EZXN0WzE3OCAwIFIgL1hZ WiA1NjMuOTg1IDM2NC45ODEgMF0+PgplbmRvYmoKNDgyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi dHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NjMuOTg1IDM0My45ODEgNTk1LjAwMCAzNjQu OTgxXS9EZXN0WzUzNiAwIFIgL1hZWiA1NS4wMDAgMzk0LjAwMCAwXT4+CmVuZG9iago1NDYgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAz MjQuNTAwIDg1LjAxNSAzNDUuNTAwXS9EZXN0WzE5NiAwIFIgL1hZWiAwLjAwMCA0MjcuMjAxIDBd Pj4KZW5kb2JqCjQ4NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbMC4wMDAgNDA2LjIwMSAzMS4wMTUgNDI3LjIwMV0vRGVzdFs1MzYgMCBSIC9YWVog NTUuMDAwIDM0NS41MDAgMF0+PgplbmRvYmoKNTQ3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgMTU2LjAwMCA4NS4wMTUgMTc3LjAwMF0v RGVzdFsyMDYgMCBSIC9YWVogMC4wMDAgNzMwLjU1MCAwXT4+CmVuZG9iago0ODggMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDcwOS41NTAg MzEuMDE1IDczMC41NTBdL0Rlc3RbNTM2IDAgUiAvWFlaIDU1LjAwMCAxNzcuMDAwIDBdPj4KZW5k b2JqCjU0OCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1Jl Y3RbNTUuMDAwIDExOS41MDAgODUuMDE1IDE0MC41MDBdL0Rlc3RbMjI2IDAgUiAvWFlaIDAuMDAw IDc2OS43MDggMF0+PgplbmRvYmoKNDkxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA3NDguNzA4IDMxLjAxNSA3NjkuNzA4XS9EZXN0WzUz NiAwIFIgL1hZWiA1NS4wMDAgMTQwLjUwMCAwXT4+CmVuZG9iago1NDkgMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA4My4wMDAgODUuMDE1 IDEwNC4wMDBdL0Rlc3RbMjI2IDAgUiAvWFlaIDAuMDAwIDc0OC43MDggMF0+PgplbmRvYmoKNDky IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAw MCA3MjcuNzA4IDMxLjAxNSA3NDguNzA4XS9EZXN0WzUzNiAwIFIgL1hZWiA1NS4wMDAgMTA0LjAw MCAwXT4+CmVuZG9iago1NTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVy WzAgMCAwXS9SZWN0WzU1LjAwMCA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzIyNiAwIFIg L1hZWiAwLjAwMCA3MjcuNzA4IDBdPj4KZW5kb2JqCjQ5MyAwIG9iago8PC9UeXBlL0Fubm90L1N1 YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNzA2LjcwOCAzMS4wMTUgNzI3Ljcw OF0vRGVzdFs1NTAgMCBSIC9YWVogNTUuMDAwIDcyMi4wMDAgMF0+PgplbmRvYmoKNTUyIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgNTU2 LjUwMCA4NS4wMTUgNTc3LjUwMF0vRGVzdFsyMjYgMCBSIC9YWVogMC4wMDAgNzA2LjcwOCAwXT4+ CmVuZG9iago0OTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzAuMDAwIDY4NS43MDggMzEuMDE1IDcwNi43MDhdL0Rlc3RbNTUwIDAgUiAvWFlaIDU1 LjAwMCA1NzcuNTAwIDBdPj4KZW5kb2JqCjU1MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDM3Ni4wMDAgODUuMDE1IDM5Ny4wMDBdL0Rl c3RbMjI2IDAgUiAvWFlaIDU2My45ODUgMjM0LjY0NSAwXT4+CmVuZG9iago0OTUgMCBvYmoKPDwv VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU2My45ODUgMjEzLjY0 NSA1OTUuMDAwIDIzNC42NDVdL0Rlc3RbNTUwIDAgUiAvWFlaIDU1LjAwMCAzOTcuMDAwIDBdPj4K ZW5kb2JqCjU1NCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VG b250IC9ESUtHWEwrSGVsdmV0aWNhIC9Gb250RGVzY3JpcHRvciA1NTggMCBSIC9FbmNvZGluZyAv TWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMjMgL1dpZHRocyBbIDI3 OAowIDM1NSAwIDAgMCAwIDE5MSAzMzMgMzMzIDAgNTg0IDI3OCAzMzMgMjc4IDI3OCA1NTYgNTU2 IDU1NiA1NTYgNTU2IDU1NiA1NTYKNTU2IDU1NiA1NTYgMjc4IDI3OCAwIDAgMCA1NTYgMTAxNSA2 NjcgMCA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggMCA2NjcKNTU2IDgzMyA3MjIgNzc4IDY2 NyAwIDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgMCAyNzggMCAyNzggMCAwIDAgNTU2 CjU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYg NTU2IDU1NiAzMzMgNTAwIDI3OAo1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMAo1MDAgNTAwIF0gPj4KZW5kb2JqCjU1NSAwIG9iago8PCAvVHlwZSAvRXh0 R1N0YXRlIC9CTSAvTXVsdGlwbHkgPj4KZW5kb2JqCjU1NiAwIG9iago8PCAvVHlwZSAvRXh0R1N0 YXRlIC9CTSAvTm9ybWFsID4+CmVuZG9iago1NTcgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5 cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvR1FHR1JFK0hlbHZldGljYSAvRm9udERlc2NyaXB0b3Ig NTYwIDAgUiAvVG9Vbmljb2RlIDU2MSAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMzMgL1dp ZHRocyBbIDI3OCBdID4+CmVuZG9iago1NTggMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9Gb250TmFtZSAvRElLR1hMK0hlbHZldGljYSAvRmxhZ3MgMzIgL0ZvbnRCQm94IFstOTUxIC00 ODEgMTQ0NSAxMTIyXQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDc3MCAvRGVzY2VudCAtMjMwIC9D YXBIZWlnaHQgNzE3IC9TdGVtViAwIC9YSGVpZ2h0CjUyMyAvQXZnV2lkdGggLTQ0MSAvTWF4V2lk dGggMTUwMCAvRm9udEZpbGUyIDU1OSAwIFIgPj4KZW5kb2JqCjU1OSAwIG9iago8PCAvTGVuZ3Ro MSAyMjc1MiAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMTU1MjU+PnN0cmVhbQp4Ab28eXwU Rfo/XtXHdM+Zua/MZDKZzEwOkpA7IYEMIRenCAIJAnJfigJiOBQ3KreIB3IIeOABCCoBogQRPyzC Aq6roOKBuruu6LJH1t39oKvAdH7v6gkI2f3ub//Y12dmnuqq7p7uqqeeeup53vV0E0oIMZIWwpOh oyfMnkqGBmPY8zkhGnnSrAmzT6c8cwn5c4RQ66TmeakP/aHPU4RIPxDC3zZ19rRZ54UNHxCin0yI zj/ttoVTZw0RA4Q4lhBSOX76lAmTO4+8lULIjfg/KZmOHbo0aQohw3wop0+fNW9BfYXfgjLuSYtu u2PSBM+70bcJGT4Px7fMmrBgtrxHn0/ITWaUU2+fMGvK0Nub70G5J8pps++4c570hrwB5ZtQfmP2 3Cmz33jgdpw/Aufz7xHWNvVDK3H9BlAjaDpoAWgFaCNoB6gddAL0Ceg86AdCOBnkBmWAykANoEbQ dNAC0ArQRtAOUDvoBOgT0HnQD7i/DHKDMkBloAZQI2g6aAFoBWgjaAeoHXQC9AnoPOgHQgQZ5AZl gMpADaBG0HTQAtAK0EbQDlA76AToE9B50A+EiDLIDcoAlYEaQI2g6aAFoBWgjaAdoHbQCdAnoPOg Hzq7Pox9V/OUpHYrp3UrR7uVM7qVM7uVs7uVe3Qr53Qr53Yr53UrM7m4tr6QhevKBd3Khd3KRd3K xd3KJd3Kpd3KZd3K5d3KvbqVK7qVq7qVY93KfbuV+3Ur13Qr13Yr13Ur13crN3Qr9+9WHtitPKhb eXC38pBu5Ru6lYd2Kw/rVh7erczG+bX9O6JbeWS38qhu5cZu5aZu5Zu7lcd2K0/oVp7YrTypWxl6 8br6QvddV57arTytW3l6t/KMbuWZ3cq3divf1q08q1v59m7lO7qVZ3crz+lWntutfGe3MtPj1/bX Xd3Kzd3K87uVF3QrL+xWXnR9+ZKq8X/SV5c4dhwf2jUXGJDVJHb9u5QS9Y+8IBKNJGt1eoPRlGS2 WG12hxP/c7k9xJvs86cEUkkwLZQejpBoRmZWdo+cXJJHmA7KLygsKi4pLSvvVVHZu09VrG91v5ra uvqG/gP+3W3/S8cGqqPy319MPEzM4iGSIbYQr5BHMGd3fgo6y7bKiM5vxOPErMzq/BvPNNQBRpxS VUkOk4fIZrKbaMgO5DPIOLKRnKQzyQE6hrSRj2gKySUtRCDtZBB5h3Z2niZTyfM4fx45QtaRPcSA /8wiDhxdQ8Odi1COIT+RLOl8lqSTMrKMHCLluOoa0tH5Yuc+HB1GRpCdZBf+/0sa4vYIts5XOs8R mdyIay7BkdOdgzp3EyvpQarJUOxdQt6kYf5s53TiJhWo3RbyNNlKfk7+TO+nbZ3TO5s7T3V+ie51 Ex8Zju9i2ka/5HcLyzq3dP6xUwEnMkgW7jqerCXP4fq78T0M8amlt9J5dC1dx8W4+7k2YanoUuLg Qyapx7eB3EFWgAMHyFHyd/Ij/ZZz82Z+Hn+ss7jzf4meDEQrWUumkGZ8l+O7Bm06SDW0J+1Hh9LF 9HG6jn7AZXEjuEZuPreA+4Yfwo/hF/IfCHcKe8XV4kaNXvmu82Dn8c4zxEX85GYyl9yL1h0hp8gF cpHyuJaPhmkFrabj8G2hm7kDdCs9wA2lh+kpbif9Df2KfksvcSJn4BxcNjePW8vt4o5w7/Iz+HX8 E/xv+O+EPiInbhW/1oSlz5SJykrl3c6Kzi87f4B1KJMgeqaaDCG3kAlo7WxSRH6GVryM72702lFy jJxUv19RH+kgP4ALsBmplxbQwfgOoTfQqXQGfYq+ju+bal2+59ARnJazcC7Oxw3nJnKzuBbuDNfC J/NZ/AB+NL8b3xP8R/wl/pIgCjbBIdQL/clqYZawCd9twg5hr/CeWC72EYeII8UWcaW4mp8knhY/ 0tyrWaPZq/lW81cpQxok3SGtRu+chMz+/LpxIdB01L6A3E4m0Ro6kaxHb2ylE8gqSNdkugL8mk0y Osfy9/L1XE9Iw5vkbkjrJrKYrOTHkK2dn/A7yceQFKZnW8h2oZr4xQ3onfuhBbKufGOZWZkZ0Ug4 PZQWTA2k+H3JXo/b5XTYbVaL2WjQ67SypBEFnqOkR22obnxqa2R8qxAJNTTksHJoAnZMuGbH+NZU 7Kq7/pzWVPa/CTh03ZkxnDm125mxxJmxq2dSc2olqczpkVobSm39VU0otZ2OvrER+YdqQk2prR1q frCaf0TNG5EPBvGH1Fr39JrUVjo+tba1rnn6qtrxNTk96IEY2KHL6cEUR4zo2YVbSb8Ji6e7sWFn 1LZ6QzW1rZ4Q8jjGh2snTG4demNjbU1yMNiEfdg1rBH3yOkxoxX1JA8aJocmP9geIxPHs9yEMY2t /ISmVm48u5Ylu9UVqml1Lfra/VPxSq529TUHW7lw3YQpq+paY+MfBHNZcTwrTViN0sDhqbgst7Sp sZUu7aoEq+NM1JRVd0qoltVr/MzUVm2oOjR91czxYC4Z1rjXG/PWhibUNLWSoY17PTGPWsjpccB9 b0UQrT+Q0zenL9tWBN33Jra/fyCx//3DbOu+9+hvsR047CoDKLtTqD/q2Zo6Sb1JCJUtY8mUMrJq Uhn4hE8TRTNnoD79WjnIDB9uFcP9J7S2DL9Sjek1icqNn1mzV+vxsjaMr27C+eNXmXuhp3C+OZS6 6juCLgx1/Pn6PRO69mjC5u8IO8g6+qqstNIJV/LNKmPQ6unu0HTWv81qn6IcctdeswNlxhpW51Z7 a8HAoY3B1tQm7Ggn2T0GthPt0MY9lK5paqedS9tJjf8A0RL+lnE43IOJ2owa3B+FnB7YkRVELrdH ah1aXcdkJXVV6qr+k1el1qVOhzAJYXWLA1NWNeWBg8MbwSdyE+4Ya0q+mp3S1NQL18lj18FfcPqq JlxhZtcVsFV35cVxUs8eA9ErkaGNNza2ttQkt8ZqmtALEN/DQxtbD0Nym5pwVv7VmqLGi2e4u+pc gDrnZ+F4YeIqw3ENXKJp1Sp2zeGNoWDr4VWrklex8ZYot1PSfUesa0c7Yaeg4bXttGUo/otNKJjM doSCoSCq1cR4WgSRviJR7aT433O45Gq98c9S1LZE5XDZf4nD5f8Jh3v9RxyuuFrT6zhciTpXMA73 /r/jcJ/rOFz17zkcu1pvVLIvahtTOVz9X+Jwv/+EwzX/EYdrr9b0Og7Xoc61jMP1/3ccbriOw/3/ PYcHXK03KjkQtR2gcnjQf4nDg/8TDg/5jzh8w9WaXsfhoajzDYzDN/7fcXjYdRwe/u85fNPVeqOS I1Dbm1QOj/wvcXjUf8Lhxv+Iw01Xa3odh0ejzk2Mwzdf5XAsuZVcq4dbuqld8l9XzGOuYTksJRjB 1cDsTsEf44lE+rWT4dntRM5rJwJINrcTcgrEysjznyOPrYQtj632c/I6/kXIyOzXcSUR2575hZag JQqqFta0X/6deOhiv3Zh8KV96r2G8XO4cV33CsfsnOZJgSckkxcyJY+sVYIHG9zZ2UMuDO74KE6q KuOV+T0pH1K/3LiUhYGt/oUB8VC8jRvECH71Fn4OHaZeLxKzcU/yRHS5vLieRxB/fvVi8SG1U2q+ IVWDOxKXo8OC84KJy8AlJ2uUcdwE8Qyxkz4xrd2itTlxDe1BugV+h51uiZlipEUYZPY4nP8I3jbM 3S4VLE3U0fuFt+PDjq6LV+HanKSxmF1OWyiXRiPRSLG5tMTGjXsyr/7GgrULH6vLLHPqx1YcFM8o 7z3ymfKl8uu/Pq788dy9tz2+Y9QNNOP3a2kYPKKkBvVxoT42UhIzyBZic6A+wqAkG6sSIVpUSSt7 7I5/BKvu7uLWhx1fXFMPm7W0xGKORvjCFOpKoQ6zpOHrn86tY7XY1DfSM3NcxevKOFqy5mMapMG/ Pk6d3985ZfGFOcon59cpv1brMAYycYfggPdYGvPxi0QuVdYv0umMqIlmkaBN5XWLiMdQNcydPcR8 YfAF9NSFK0xWC/k9bcVBCyTBEbSELGNo2y7apgzaRV/bQfcr/XcoA+hr6n12KqdoCzlLTCQn5iQh k26yrDPjJlKRbjKRPUmTpiTuUBm/0r7BYHl+T1dJaUlxUSQaKi502DXSzlpfEuVmfTS++bRhRE6W pJfOvj2/zYFbgJ8j6K+5gdwGyHdqTEfyeOoVCeSjnVbvC76uyts58zckj0mHDfUdQb9XdNwGhjtQ +GdErR9PIF80i9cx+aKT2f8nB1nlmLBeK1+lhY7Q7tOnzwLMYP/Hh5upymd2zCVRF90AZ5njfFae JxyvY1gP78lzfwhhr6oUl+dmLzYfpWNpIQ3R9zcquRvZ6GFjNNb5qeATN5IkIAdzYq7lIq2THcVJ oq9YMlrL+DvcZfqUer+5+aj7w454B6nqqEJr+i2MFZFkY4SGvRFtWIw4Te4MSLk1gybLyJk1yLkM jgxq45B4dL4MYhGQZONDWaJ+7iNjictpMUtcMDUasRSVWoPWEksRF0rjLHaXs5CP3TN+1L3K7xTl 3hlVzbR41bYFLz+9Nq/hFXHj13uUd5TP/0f5y28P0ooLu2ndxa9/oMMu0ArljPLFZ0t/meDRUTTw jPgYRltoj0zbaWHMIAiSQZDWi0RXr2WNOnomXk6qqi78islVH1paCKE6+tamyJrD/PerbE3bLt7O f6/yOwa5TRGfJGlkW2xIiVAnjBJv9d+esihlCV3OyVnyaM+tnns89/he9YgkjSYJPpMnKPk8AiVi ICkpzaYrtompgbuCaYbgz6Qy5x1ppmjSfYGytPT6UIK5FzrM33WcU3VTVYfFWp5ndZVTbK3l5RYk ZKzKdp/gMYQtEb3VlEG0dgnMFYxmXQaVHUjAX7NZ5S9YW2KtoglZDqVJGimEfLDA6rBLmiSqwQ4I 5IClPz98X9Gw9YsP1EeE/Xz1XTTj+68W1r26cmLZZC9vupx5gFpn3zGwePiti9euHrj0YPMp5fvn XlpUP2VQSf6omTtVvuRDfrziJpJPjsYC/Q3Dc6ZkTsq5K/OuHM36CB0oZ+vc2XYj/2O+vdgIBzwU s1uKzT8zGvOTi9NFqTjf6F4frbG00wGxJF1Z7h1cIDP1Pj7KFdYXXMOVjgsJwQNTLsS/MXeYGX8Y b1SWlOT19ESIVoz4w2kRDeEziMDLPcEOXyiQQbxhdwYVqAR25SFJCSaDZxEkV4XRXMmk8b77wDM6 VuCKC52QvQKmBEJpGqk4hRYWqCohwcYixkagHOAgFKCdhKjz6zcMGXX717z06lZr2OaLOKf0nbtx SlttRNwbu506PvtrfY+6OT9T/v5DlLpOPFg1Z+OCx5spfZrnUsseuXXegupFz8w+8daBJcMK/YE9 Lb9SFCa7HHAozJPiFuSMZEwsTcvpZCPG95tWjUbiNFSUZGBjko67Sy9+yxskgW+nrlfpeqP8kq6d Nu4Tk+pNKge/g9aEVFUx5WkpV7kGxpVDIQiLzceSMLdYtNQSLKaFFigYC/eCUkzfja/mHtn4wQeA 1VbG5ysiHdfKr7l8y5PKs6xulFR3fg6d0UJSycFYdoN1RYArN9TZRtmm2YRessEoEYMuyWS6y2qz WU1JqVabRGwunasYFUuLeY0/M5n81l5JglCcetxvtEhl3jtIWWpafTDR4991HIWW6aiKo7fPXbjS 02wYqErsGEl0PfreDTWU4Q5QLRfhUwBwUhJIFX0YE1o3EhrAGqMmGYnsSYwNpnrMlay7WV+PxWx8 TT9HmYbmMUgKCwSHnQumpUfj1sWxm57ZtL9l7NK8LbO48/GnexfkDJ1xjFovKR27lf8101mbKlLe uWf98w0xLc+/osyN2ILKW79U3j72jtqHgzs/E0LiUySZRMmLsfL5XuqSw3LU0+hZRpbTFVqpXtYF o8Fik8nOH5eKk8VoMcZKJndfSpnlDpeOq9Sl57sy6zNUxsTL7xk4bMGiPDfURNd46ACLGIMSCjkc 8aUmOYlGjKQmpWTQiCM9g/hsyLExQQU+YA5m0LAzmkH8ViRsTKi6giYGABsB99Gx0MlORwg2BrTw T+wIpRGLWdXPiWHhsEM91x/aaw71XbJhr67PuJEz26hB+dNJ5fO+i+mg+x66d9u83U8/JD7145IR PUcrf1Au35yT8c25t5QPaD7gUv3rdPLFL/7n/tuPb9q8IjEfYg0O8t6CeWh4rETUe7gyfS9DuXGA cQQ3UpjI7Zd09xjbjMeMPKelRlMvkiRoDZxRJuQOk1ymfclkqTerbIIa/ZoJOEQeEg+xoVCcY6lD AxOKqUGrraQ0WCzk1X7dOCrHn3u85vzKDZfPiy1P9lPaDh/cNOlzuomu/8vLr2K5GnL+MXTbFtgq LqCpv4zVj6SjtKOTmmyT6RTtrUkzbPPD2v7muz3NobnhO6P35N9TsMKzPHV5dEXuivyNHmO9XCCH TVy4QF9ssfQQi1NEV3EPI1cGYGPZflNZ5h15clky8q/ay/KK6gsT4q9OAz/pu47EkO3q4+KsXF+q 1ckbnTn2DGLINmVQnVWGmPuRCAEugzpyXRnEmIVE8okZlE9FclXTqVou0cdd6o31o/WaPIFtWYQh kFBwGCAYCqG0dOwr5Z5f1vLA/fPWT13xws6l9z23bovyatYN58+8+8eayNCmwluU86eV39yziI8t HTN02bLRU+bGK5Yve/CRtffPfo57JntoyzPffProsuF5OZnFk585pPz41Sc/O4BlbI707/xEsGD+ YGNkVyzXI2aLGc4GTaM4XVzpWeHd6NXWyVIwGi3W6dzBYrMoFCcfdxslrlJKybe30xExvZFkJt+X Xma8MlAwOszfxcsXJ0aLqkuuHyiBiMert1HeGuYiaUkYJakWjBLeAxUS0aMYMmGgBGxIqBfqI2zA aGFTRJflkhgnNKE9bCaKgVJcZC1MtTlhD0NxRIrJNRylZvnW0tr7XotU7pn63t/+cp6Wz6++4QHl +PtnuYI9T9+9ZPOKdXT0uvKUj2n/WwZT7pdv0Qzlm81/UH78pfLK59to5KHWpzbveXz1C4xXX0H5 tglB1Z8qiHnFLInPwlKeTgvTUaSTBQJPZ3JwwT0J4xHif8WDGIwpEwYOU/Cgr07jIwTPxteqtiSu C1u5HddNgmdQHvOTUBKsZVuWWSPrmIcgFVl1k81Qo3Z2aWaWV+LaV8xmOD/mf7acMdTUW9Ulmyid dSZQdP+ZM6eNQ7MKRMlw9u1bG5pd4o24O4e1HiK4xFPMhiZbYvUZ1gZbo22K8S6jOMOw0MBF5CSz 0ZGk17odVqNeSDWPYrZy6tvJ6RpqTco3B+hkntemusu03rRAfqonmPZBcNIVV2+I+fvBqinVcYFZ eWxS+cbyk1VlVfWm15MiyP6wTwz0JV7J3ZemCMl9qUdGgl5nfZ6wDMLgHLGqQ0MjmagjVFRyvYFF O44fV3ZfOHOsY9SS8eV7a+4cmu7MuGv59li6uPfUKeEklb7cPXNJy9j77n1495wb0sJ96yY+ck/t /eDBl51npArxa+iZAeTtWFNJSVFDXXBEw3TttOjMPtOqF/Q+4flFrd6T7SnP6F3Gl5lKgxq53KGL Vtfp6y2NZATfGJzqPGE8YfrY/rHj474mvc6ji+hG6gRFR3U5ucCBdTwnF8vt9JF93tAADtu9OZkV 2Lxq4+sH1PVDLmYZoNWJObn+3LICsThSEEkqO0QfhuKrQpoEzzQPniD0al5HnrX8i9wvYJFWxT+0 lld1fHi0w/xhZfyoBQbrctF8mI6dA42LCZawOYRpmAJrMbBdTCAlwVQY/DCaMEigUtjYQYaAqa7S Qh5MZSdj8JBgKhxe+ADBgvRSl0YICV8O7z93+8i+yzfEN/zu1c8v0M108jv/o3z74qRxAl/87Mi7 n6Di+qlLhYK1S5NMpaG5rypvKH9Rlpx86fnDdNI2mjK/erSy6WP+4CTlf5dOnEYrfna5kYqnsZBX d05p26n87Zxy6JZ+erfxzlv2rj5OezYPhyNZ2Medk/mXw+ep9teHlN9d3HlyRtPooavZvIDYL7E3 fC+O6NBnZ2NDG2gjnU75FfwGYaPuRV27tl2nyYAPJmk0lJO1WiQ6Iol0NeWFVLtOF7Zin10Uw7Dm qF4v8lqdoBGpnqNw3lIkdFRTTIulM41Wx4so7YhZjcxDFp+iT+k8BuPW4OpxGOSeIRfcg+NxjzrM 62rcpMoFZ29wXDX1qpiBnPAe8lTLaSAQfuFwcqtwtGl5rhv+INvBYwd/tCm769zl5spKCQSzEP03 luqpDR4jH+RDlF/zm46lX3KOs+viB59+h3uEG82MQ37SxX60XWlQuTG686w4B3LsB4f2xCqSxQ10 vcgHYIndT5eLK23icJlf5rdYHJpeft7Qy6FN4VJSPHw+V2HOt3hTtfkeTyB1a3Dm1C7wQR2/F5jy xmwOxxMZpsdg9vUiPlfYFjGFkyN6p7aAGO3mAmq1JJklH0oi4Qso5QRe5zYUkCQrEtmrKYAbgETV 5AkzMJGyHffB9JepC/CKaulgmJeWlBbCYFA9Uya4ISGFFlmOBI/t/VT57m/ffn5n75Qj3sd2Kx93 kle+ful1Wp8hfq2cPbhmm/KeckxRlP95senR808e2vwr+hKtPfU71R6EEhcngVNGrNNPiwWWW9Zb uQJZn5LEkRSXLOfbvF5j2OTxeD8KNq+8ggAwHYahVhVXGx6hTkvYEdFIoiRIvMRJokZnltFaJxKt VV9AJTtsFVVxZbF2hVlLmB9o5kJBC58YgBKXSblTU/rOG1DhTfr0b8rTJ7jhNG/7usbNyrL47p2O 6B1NDw6vpxaae2mjaPv4iHL6j4eUvWobgFsIHWiDHlEOQ2LpUoog6PkUwA1aOUWnlw2cwcARzQyu Qus18XKYeIymdqrfF1x3pUGVrFcvnIPAsV6FqFZVso5F85gFruI62NLdQt7ltXz25TP8PZeOcMDm 2pTqnYppN26Nj4qfCDtR0GLGcrNaaLtqobmVevXqnXX6djoKd/68i5XqnZkv9E83DO3mL11+hzsd zzuu3mh3HCFOHJnU+SmLG4DPHyKnY32SNcvoUo7304C4jK70vZYqxuQkweHkzbOc9zq5JKfFKCxL M1tSbFarQ+qVxjtkYy+vNsSFQnyKtZ0OjJl5IZ+vMIdt3rAuP8WTHm6n0/YFZ86+Tt7jqnubEHlV 5sEjdVf52K4hrUpCj+QgMfjCqQBhDMk6SHgQiYYIBZTjRUHvNxYQbUAqoCKHhNkvsPO7LH3MaJB3 YC8MT0wIPBStLQhgLRSF0IcYHMOEPsp/s+Gz/GPpv3vpHeUP31DhOBV5pYhb2tJzypAH3lYuvfGr E2/S3KD41dA7ld9uXau8q5xWLir7f0+5Fy7/5dAd2QNe/JDOpXPOnuLUPtsK+c9TZacqFpS1KTzH CZTTSbIghTWi10h1YT3AP4PxmWAz44l5yAWmzSAwbKMiWeV54AYzZQADM6wGNd56krt88mRcOAng dSt3y8V+3O74jer9TkJQHsP9eOLCWiyAZIrdudmI42GwM5fXMx/XCZ08iX8CDAPmi/oNUev3emyR RgyLUblBapTmiyv4jXw7QjZ+L+m38dsEThQz5EztDu2PnIiBKIta/kOOiqJGliUtx2XwfNgKgdQw BY9dooBQCBYJIWm0ssgJOgFInU7SyLdq7tac1/Caqy03YuAzxZ5ot2eI+ZuxUOqVGCKVKhrkKpeX D87NFuG5MxUumJmNe8wsV8rgCZk7ZyydMxZNokEt8FfJEtpyhHuH2uJPcvOUeFz50xFwqIh7J956 eS335ZcMaFDbLAxEm0WSH7MBOeRSBFHmvRLlwgAzNVI7Hb7v2kqhTqgRugOwNOsFR3DLce785RvB wr/vxvU2IK7ahevZ4C811dCBmMSolndSD/8xFW3Ux9v1yYZRtJH/kH7Gf6j/zKADP4y13DJOuJHb wHGZugxjma7MWM+N4po5KTzZqON4KximN1h5jawi1gxi3Rwz6gK8XhM3UC5uDGB4bX7NRjx2Jjgw UVHDc54L5eX4uc8xEUoA9Wx+BCcHDlu4x2hopzvbOPQE1MTOvRzHLxcH5y6KC4uPLhcTW/B07Nw5 dO7YOTbGUYhbUUkxAFSYKQ5LaAP10230Oeo9JChjjymjxTfFQ5ciwtmL/fhJOafmX8oUPs4p+aLo 8pPgs2rnilngixY2Q3PMXkrL4JECto3SetoIMQK2wxrlUvEdBu5wMsxvXqejGhm9gmOvioLXwGyD zTGdlnj0hq5Rct0gYfN4QrGioeXlAmb+5YuPsYZQSAZlY4bit+VP3DeHfhNPepPrhUqPFrZd7Ce8 cOlm1I/ZN0M7z4jnofeS4JX5yKpYj+UInDtO3+JOyCd1mn6yo1cSn9xL0vo4n09vzee9Ke58vcef 8km3qfvqxK0qrALiZYhxF15cwPDiAuqV3QUMLy5geHEBw4sLgBcnFwAvRqLO1SxhH2A218LFDI4g 1mIzjElisVuDvLD54GPbjyrrlJePvPz4mwhrS/6T8rc/nVN++w/qMIlfX3xLOaXsP9tJfvsJHUCz PqTmi8/Shd8BNa9UjivvXVD2iOPQT2x++wF80KF+E2LFMwwzrAsNi6xCg73RPt2+yC5IcorFbNZR UxKb9XQyp7EaBK3dni94nUlaTHgO57+Y8OLMOk7Md2awBUpMxSVsKpaowcwcguuNTRDm725u3dG/ fvRrpeA437Kg+k5lHl29bLt46IsTL3XG1woHegUUfu4jTKbaoK8WqDIVJY/HrJKxP20Qm2ijOEOc bF8gys6DCMTzkGTqi1WHgqmR8dY51rvsvDUlYPc5+GCK0y5ErOnhFKLVJkspei7iS5ZTw45A2Mnn J81I9mbKkXBU58nI/Ci4LmGTdanjwRfg8X0IswSqieF0aE55l2PFLM6xkMJsZkJSZsyr7eKDBQxM YKBpgLnOLgemnjzKcCa0na9f/dzc3lMV73Fux45Z782aOHKUKPF6a+4FnUEwSJPLFykVx3nf7Mee LE/BEsrW/HHxJTsKQ3Nbjt2UWWcP2ipHfvdIfnJ8FXgyvvOM8D1kl0WsKrFxmUnRUCRSYioO1kcm RhaZ5qdrb5XdJleYazJNN+1M43WmXmnpaTpe8LmX2fPysn297LzQK1vbk9OZZEt6WiCjZ0+LO+zq L4czvAWBsKU/Ced58gueCc7ssmiAN/xkqFqBsTK6xmBlPZ8bL2ReESzXwRm5lgCRuQgXyQlrsH7C 9yDZJCdX3YhZcjb12wLZJNnhzqYeN80Rsok2qs+mYT3NRV7KRJJi9eGgE4k6QsxmdXJnY+SnCZ6h 2SpEwbDraERldXFROkM3E+iexgH/Su0Lh11gM34ppSlS0aSLs8fsHTjo2eNv3bgaQOfvab+DSfk3 n23dNLri1LvrblytPPkn5S+bN/PcYHp28ZDHUvs8s6CwIJzTo3jM/l8ov/muuerOxyfeVpDaMy+t YtrRC++vfvAvgp7NM0GMK8yzWNMtinmpJoVInCAz4IJc4viwKFzSeGTm1HRf9VPnGsiSutwH4O6k YnlbsYiHdl/8u2jCYGXjYCfsNGZXOIiTVMZCLjEqlpl5HeHEXmatk3c67dqwweumYbvH5X4muO46 e+uKkqoETkjVdScG90NRqutSfMSDqXReZdMH8Zvz3+6/TFmtrF7an+snHro875mZz7w87ml+9eXj yt8eU76nusdoEl+OtgK7F0tQHw15OFbzCH2GcjF6E+WclC4Qv6HcNGG6uELgPRlcGKt1AmFeoAg7 jdfA+xMFWQZXBI5/SiT0KY1HWgOuwBRgrl55OX4Jd4/ZBXD3gG8yi4BZA5jUYpgMKeGx6EQ5jbhc xpqfmrCxSMbOmTNXy7EFQGrGxLX1N/HzH8T/APXvF766iAYxXlISxnNQc1Aw0JGxdbKWLpAWahfo l9NlglhPB3I1fIMwWK7WrZSX605wxwFbn9AbGvXTpOn6ldwyfpm0Uv8Et55fJ23Sv8ht41+QduqT YALpZL1HdupGSRq9LOi4Phm1GWIYKxkA1wx6rUB5PYxWjUEkcJT1vCSbGOwkapbFZF64oOO0F1r0 hC4zeIzXMcObYAjbXGUKZnhwBSAP2NKxPLcDXGnTIhYViw+bYklW5haKvKCRtAiAx1y6KaaDqcZj NzHoly82y8ywErPBuWPLZdXKShQG3rhwH4W+xz9ew+UEXES9oFYrJ67HWI4ryObDKpnFRXG3fNS9 nGUWy0fRA3PHjp0De8KmpYX40ZAWPRGnDjroEzqIOs4q955WXlZ2nVZa0CUjhF2MMCsfudQHvUER dUvEIuT05I3Y7AxawsFA4kcJ0/hpQjO3QF6BDtJH9aVcqVgmTxchTMASmBUqygj1lyBisE61yIat Or0OVg9Pw1Y84saJsh7NlzQsUBdoA5F1GgFSKOvR95LWa+Qp8IZ2atgXZKxnkMNg91HzEM/32CTm NGZTVVayvCqK4ABbblY35ms2CRskiGaz5rPGU+9fOZNi+5HOp/M6FBsn/kOZx/0N9um7XEG8KJ7E jcHYZu2uR7tlWE4Px7JWCNSeIWDccDzGDbpNlDlZAqyCoYPW8VqtQPQQHl5ApGFMq+E4UROmMsxY 8irx6K6IDwILyt2YtHrnmWElqvgJ5iw3c7rUQVWeizXzn8bVfhHjUUYPCxCRo2rChpRN7UiYhbas 8xhR2/4QP3N8KmzsPtyRy2vjrdxQnj2ZQkmLMgshLMeh+4oR8+AjZsEnWROgbSMAIYnhtn8N3lZ4 1fK/cAW5Haz6/XCMGXAbbKEtH30E+Ti+9sd31uK6ecosulu9bp9YKoEJyftEwUy6Lq5J5WgjggDY tSsTmHAlC6i4Ek4RZ843xVylGvIhOH/BvDNnaIvS0kk0RWt/2Ia682QY1vpYdHoSnjuoJF/EyrJ6 Up0ZNrwvWthgnqGdaZbKZatByycXSOlav9ngr8jmcjMr9ldwFQVZYatZEmVfNM3la6eroJr9ASnq z9Vz/mJ9pVRZ6bNLmVk70r19kjN9A5KiZZ7efd6gGzBZHKDricqOwV3T67n40SuaGkgQEAMmcMzQ yO3I7WB+MewPdYLNKCl1pBHqCdOSpCBxp8BNdqbaEY6SRkq5IPH6XUFMJki6fGLVtExAvOlAH0tL elMTVZfIHdetn/fBOjBMGIsKUZY6GHaJUJwuCLOk1EZNc4fc0rQ+OL1g1sT84bStj8PwwKKHKoK6 HeI/njvUfJcrbEixZPWIjM1yakvfvWfdodc3rHpvdI/+2x51+DQmoy9vGr1N7uHOGTN8UNbwX2xu aNgY3+BL4/mlBk11KNYw89UV65630XNsvmvu/LUQFo8QC3C22bHcbdJ238c+Pk1OSuFEPMfjFyWL LsWv19ujsjfVm2vOpZnEAmhtefDQ2Csydu6carSwgA78LIgxULnntjo1OqfGHqFWHRKH5IpQmzYl AmYBOWNsgtPHWGG1sJUhcMARSr+63IEF1ebdFc+PP/Hj92cX3VRQvo2b+uijD919IFJ/RDwS/9Pg G5UO5YKitFaEBq9cfP7NF3/92ukN4/ZAzjiCJzL4U8IQ4oXPsT2Wt91DN7p3yDvd/ADZstnO83aN 3ysZ/fAepeRklzlqpQgTsHj9uqjL4/O3U2lfcO7iLolRAQOsnP0r5LAIgy1scOgixGQzo5UMMwRa zjDDoIoZ6p3GCDBDJFq3JsIww+C/wAyZeYWV0gRiKMGWYsB1aSETBw4+SaHEffSVa7d57r0vDei5 4rHZD3h2p/z14PsXqfVDnzCk9eNJD+yY9czWz1fOP3OMFn6Dx0l6YeojZZ1n+Q70q574yfxYQamp 3jTKtF14MVkMy3YuyY81GL9fsuk4v0sv5tpyzZkWqzegj2IJI7A8OLf62ubHzwHpur5vvW6fVkco devRNh8S4uEiRJcsR9BAtXfRKmsCgWexDw64Wy7mMRazZhG2yPX9Y1sXb922aMWLdNXwnr1ffrbq pTv2KRe//TW95fzHJ3/51qm3udKilIGc/2KfdZMaac7FP9JR0CENnWcFL3SID09DhakhtnCD/IR3 e4AXTVySaHeYrEkOe8wQs8uZXjpQ/xp/nP6CP578ifyp9qPAJ6HzrvMh/XHLcSs3RhaD6UmbnP70 co0kOYN+n6TzO/VhaYNvu28/xoAQdiZhJcejM0gWxNf4o6I3mp4rRT2eSPTD4LaE8AMZUEX/w7iK jqsged7YqwY7lKKKtqnDoY6EML3j8SEqCpoAQDGr2Wa2mwWNIZyWnB4hqcQfoSl+rUuKEL3DFMHS dMgbxC4RieyGXCE6B4xmSkZdZ1cN9KzsrPuA1JA5wNiZL+R0BBNRJkyAsHKmUTE5Uqi6R4hBoVzb R2UlVvPlb8VHNjx0U0/7HumG/GEL+w47ofyRun9HA/qMAS/fs0OkIaH+1hE33jbg2eeOjS2pr3g0 d6jPjIkWixC0WoncVXf/vlX0cww3zB0+DDqX+D4WeAbHsiW/RufnaZK93GnUWHUeTKAmoyXTZZWs SaaAiTNdtnvcnsvBafcmRCw+tvwoc/rMVxYYVUBIXQW0sggKuHe5EBmNg6044ltcWPxqqKrNku7y efTDUve27V23TqwuGsNxz3N0xCtrLk/mt6zZoc43vZUK/jxkJUBy8NTd/tjgEnt/ub+2UW7SrjC8 mLzD/2J0W/aBZD0sQ2dapumoLg1TiqDJ9Ht0Vr8uKVfKzRV9fK4zNydT9PY0mKLGPpGoz5PX85oB cqGjnElA/Nx3mDe61hagBRMgq9rvPUIZ3hS9JT1sjoRSIhGS4UVi0ZuwRmoyGMP+tAiNJmdCTxgA QnRNJD+FUahAhau40IIoIawHRxMRRaUl6myRboF6YEtjXVoDzgbl7hlXWLytcrZy8uU/m/Ybo70f eC8W4Us2Ln5FuUSl12nN8z97sy689p4jN/RQTgvVfUL9ll8ueKf57OYXGqKVj438YtjQfwCMMtJc ZevhvbdsevXQ7klLOPaUOcWTg0TVKU7EVfTAqJFdkkuOClHbXdJdsmwzcjYEM1r8Gslh0BkzdfCS HJnECT+pnWr2BScmdMoVt595/OpsUU5ZRII6GaghM2xiBDrGokY0yC1pixWOuv8Pw3MOpOQvn/1a G5T/5zcGy59reip+I/dcc2njpo/iJ5gccqx+tAL2HYsRLon5pK8FVFrDq2vakNtMiWfW0c6fanI0 Xnn0qtipkbcMxGWLzUv24yNkXfpIPKTG33SeVYbSMvXaFgb4DgcCzFgyEnHIlMUan0rEHGtPARE2 4QRL3uuoB4s57plPIbS0D2WOIHoR65RRWtbWpjy7ML8tUtVq9AeEjlM/FgmhMcJrl0rv6jUR9qh6 8Rbwm+FHesxik5s42kumHg6D2qUZJU4TF2oWSMvFA/xJ/iwiPhOAMc8t4R7HQOC5ciwLCiIemtPM sqKnVNBYTGDG8GYR1qYBaqwDXIxosEyih2G+NzjxAHUmLCXWSZUMM+6CjKtUkxxWEjNk4dD8HGCg O3sswOPDXYgxZrA5cEgAGKv2OADjlpfpu98oU+meb5S9G16Gk7uLHlfuiE/kfKsU9lQ1JSuRsLVP nmTGIDldcatcJgxNQbymm34KPkiYlyvb2hIhpwmZ1ISFehIhS2MVkiyZNEku2WVyJUXlKNR2g2ek fpreEArrvP6QR8cJrnDQ7/Ib4S5qkn1h3qbLgIKyZCL8g+71ZmLypwi/pblhDEhPNKOdGq8V3HPm C1j+75IY+CoAFDoQFHAlDCAhxY4uKXZdsfIgzF2yfI1U740VNc1pGdIjvfLZKZ8MyTp46+CZT+z3 Zs6eur1NyNt4Q3rvqvS6kcO33LQmXsqdv3Xomm3xR7mDswoGPvUek3ZV1vkO6DY8Z03GxfL3a45r OEFj10TtzZp5kmg3cHa3GdYb0bj1Oq/k9RJDptbro7nuTA/xJMOEvm5IJqaxhAZDuzpYeF9iWDLX xHFNU9i4xLyCBXZgv0t2Ddo5/dzQHvv9Pe+NZQ4oy0luo9tR/3HDnh71LBufEysnG53VxXNmxN9D ZdHTFYjxDMI2M2Dd0kMeiRVulNebn3C+IOyQt5lfdLbLJ+SPha9Nf7Abeskav1sy+K16j+TxOLho kjdZG3V4vIhz0sJC65qBE4DZVd2bULnEJUT0Ni1mSwsXoZILOdGInM5uiGC8IpGdMMh4ExJ1PmUJ Q4XTrSrICM0DK8yKQDUE4ZCEEfbbpT0Hvf7C+vXP4SHuy8o/vlAuU+vvNfNo0rb14x6/vHfXOf6s 8meYpHHlFZp9GYZ/jNlhzcoIIYymm7DyNy/W40V5u4vLkFN9FpPG75CSNCa/T59m4qJub7oO1nUw My3JE0r/l9a1aoKx+F21jT5nMhG9ESFCktEw0YmEekwRwrvUNqnNYjY2s6gTfcZAukJamJBPPFjL VBGMbkuI+8X2cN3rB2vDSJXc3SWxm+9+Tdk/b9PCYT0r2hZ+8H7LmD0HJ2+6Z9Q2fs+a/hmVCMGL K8+uv6U4pX/8CyaLlcoIyGI92phKFsUKy9wN7kb3Drpd3OHTZMhWF6/3p0o2De/36p0mCcamM9Nh 9yJq2Y8Ym2vmUtXWVo3NrqZ2tTQ5YDASjka4ZLTPEEBCfDzMoRR9l7XJ4g1hbrIYzAREecXixLwZ sqgWJ8ytwh+itXvfqI9m92+/azt9+OaC3F2v5jw9f5fy9/hJeu+47a0TNjw49ulffsj16Zdet+4i UNWGEdSAwA5KB1zRV9xjaKeF3BCLRPmIsZSvFwSTbOZMWovWEJXZcLPoZK+NMnuaeKy2dloLBZIw daBUMcyw5FU1uOooi3FJxON1aQ02xK7aOpbQyl2O528V3X5zsnnFY1AJB0o2c/ybPLd7bnwj4zni CfnXhIGwa/JobuzhMu1Gcb31CftGx8YsTUZ6OFoSrAvWp9dHR6aPik5NnxZZaFhoXGhqDs1Lnxee F9mWsqOHjYeZKeYIuTbidSS7fG5Hjj03I0k/A0h9SZgLpxl1QrbN/Quf3yYJ/txN2fo8SWsycxLJ C+Z5A26nO+rqkxGRohnefFMgau5Dormenvl7r9rGLFJKtY3Kzcix5pbnMec6gWgzz5upzgSUPYjm cBEHIOygKRAk2ogUpECxgwRxaUHqt2Jfst0dpKlJaUESTDMZ5aguSCNhrQ6odpBoMpGkWHxBhmQn vPFEdK66TK0OhSsDnK1dqVj2tVA2zEyXU/pnLDsxV38rh2t2TN7YO3rnwyv7zvvswN9v7cftFCN9 npg6ozZjyPwj1TM+/fW3xyW6nw4d3XPUqJtr0+FVpGX1v2/jG2tGT+9dUD8kVpflsfnzetQ+/vCp T5/hfsS85er8ltOKo6EFh71qzNUdNuGZgqpYWHCWu3iNSWfxMuCJajKJw+RI4gPAqC47Ec0Bu7nL M+1mN+exyQiRdOb4OXWSZNYyG+/wJFV8IVLMTOcdr+3aFXHkG1PsgX7Re0c/+qg4WjmzNl5bZtNT bo1Wvm8ad2wtZJ0jLZ1f8b+G3nKhhuNivdrtJ+yc1ibbPTaPPUMzn/8YRgURTTqiMepE6Gi35HbD 3c3VZRr0Xi/NZJV9/4qlNZgpaSb+V23kKizyXJlfrkPKQ6Wqz4LYUUuYlnl7PvBGTbhtJxcqmrb2 6+E5LJQjXj6saPyO0U9ypkunn+qdddMTw1Zyn3iZPYHFAf6PQh6BrRfLrabHAMROI9O56fw0zXJh hbid7OBkvImCqxUGiMuEleJx4YQo98+4M4OthGJKUV0SgLztnbPb4KSlAvd7YD/Pz7IC48Qy8QOx FA2sKdxJBMRJu1B2mFg6hrLzu7nXKbNAl+yjuzWeRDzVb3/bFVH1E8SOZlvLJZhR5iHnBkuJTTYg 4ViYy1Qh/MxrIPwrF0f80W5A+Fev+6/Ae1EyZ+MHMBHuIJaZVWCYfk5TaPYx5bbDyl2IgtnIT790 GhyieB8IEbciZ6CpsXvrhZ1adD+tk/rrl/Or5KW6t7mj/C+kk/IvdCf1+qnSTHmKboa+WVooN+sW 6pdKq/Q6di5Xz88nC0R+VIYzA16/UEErhIfpw4LmWhgeS8+A4XVdMPxmoPBHgcIfBQi/GSA84zkM zasrEt3WJa5A8GMZhwwieCPhjSJWIP3icnM2ftdg8g/GbAzFBf4sshOv4vIPxkwMl9cb0Gz1r4ll DvPio26gy24VoFczDJC9uoeBsnPmzIFVm8wVJjOQXQ/39+N3T7/9/mdtysmDZz84qPwSLG3jB10+ wNdfOs33vvwWGNolh18iqyfFzFPoihHh4RVoQFp4BghrgmliLX8db4K5kpO7ciySJJm6gGozYDvl D9//+JmygS78RvleUc7RhUKespwuFOOX4p/Rx5TbOSyysPHqUPqrvi6zqt6O3b7KscK93c0zX6HM 2mBttE6T5vPzpdX2jWSDuNGxwbnBtYPscJobyEBHveukQ6gRfyFyy8VtZBubt11ieobodric8J8c Bn2SXzYxI8yZDEFncuhyuHcbHnbCFvswMWoYln/OfV3nJUwyLDQV4NkxBuuz+Y4tLFkdWFxzzrK6 XG4RAb2QRDdAftYdbCNjq4Z9zmHrTLRQg1gXTlXE6uMzJaV4sgq9wfPB45EHJlZvadkSyUzJyzIX 5JnFPiZl3jtYFBbypimPKn9+RZnappGfN2qCbvnxdGEIxP9+xiusqfFt0G0sfuK2WHWppoGMIo10 lAbagk7TzBe1GOGaTDbSWcwEQBvKlcNjQgxmOZZ6dJLYR/Ia+AEscGLvVUNUNaHVkDAsBqgPDKgh VuUsYlKNm6BjSyniohyUxaQVcXfH2/g+8ZXcqsst9L01PNm6No4R2R82MvAUfoGKpyQDu5gQK0n+ 2kN+wlX8AFYCFl0QfZGckukO/BO8khp8PzitC8G7Ok18BIyly3Nhiyws6gYgS1UHze/5/8JZwnhu UYIF9U94C2drw+efUZfAO+8cv/SRKo+sDfPQBtaaxlg+B1zA7PQbqU9T7tFqiKhLQfVJJvV6fJla jUWT5A14Oe9lCaEf/6ryV5wuVP1KzVHxIHx1msCE1CcNElCRpPHDyg3x89ra4t8CHVp7tzvqAVg0 yJOUcBwBEL05/05e2MrRHp7ypWvYmFU/31Qc3HJLUuV3xIKHQfB5Z2fvq1sgABVYzfwaO7RXzmdb TaaSSaBGf5hyuUP/6NUj6v+QDBatpJorh9h9TIbR5WQLt5OsAdUIL5Ex2L8T+RHY7mbnCHeSGOho 1zYf2yJQNWgwaGBXvj/O/YoRylvkAPlSHElSsHYzGvQC8ruFr8huTTmZhPJWnHcS+7awczU7MfqP Y1tOhrLzkG/DdjzODyK/E/ki6SESxjaLEf7bAsrDf4eBmgVCKrAtAzVgvw/b3qAl9DgjILN4xw/y K3GfJWw/iJ3fDKpEO1fiOOOFC+UW5PW4p5VtQQ5QEcjHCHwrwXccaSEnqA7QyWy6hr5C3+di3FTu 7/xT/J+FFtEpjtdYNTs0H0pW6XH5NvkH7QrtH3W5uvF6WR/TN+rf1180LDN8bhxtbDX1StIkFSXd k3TWvM2SZlliabX8zvqSzWnbaBfs7zq8jiNOqzPmXOT8o8vgWuE65x7jftdTjUdGpnvbk63JO3wj fY/4I/5m/ycpPdUeHkzWQ7JvBc7EETO+Y7HSfV7nhzZnksRm14REaXCM1PQfWN84KLthym3NU+bN mDQBZ7AYRnw6p5ApiVy3lL0lEI+JQz+x2FgTVszM8DqsiISzq5EJzCpjnj+LqWIR0iyqNB0YSBTP nWRinTMbb/tKvGktHxG8hQSPkZBSUob3U/VS1976kBipIbWkTn0zV388K8DevzUY7666QX1H2DC8 9+smvI1rJFOMpImMxtu0xqCVh8nPE8/e9wfuVQUqBmVn93Wj37eRR0DPgHgygz5IFoJWgp4ACVdz L6J0gD64V5Bjr9OFxIunNfVC4Ca7J+DW6QPvA5Zoeyrwqfurgwg2MpIvqWevkWj76ugz9GkymQTo C0D9F+FtYhl0077M2wLjcehFMhvUAuLVlNIX96YUBN6kPUgY4QsBGiEpAn0t8Pv8nMDX+e0c3Rs4 Em0XsPl5CkqxpMBh/1OB//FPC7wJ2pU4tDMTZ7wWeNF/W2BtCpbn9wYeY+DQ3sCjic1dfvz1tcCs zPWByfnq8UHr27ldewPlOD4ypg+UlAUDxf5zgbxou0xRzvEPCmTl/yqQjj/itFRcNByzBHz+tYFe OJTir432Ah2kO+lmkkU37w0PCLyOLJq7r39m2fp2eve+hox8hPkuipU0ZKzPbIiGMwcFwpl10Sjy I09IS6Sbpb5SgZSNF3rBgZKSJbtslc2ySTbIOhkQYDt9aW9VQHOQ7iJVYMuufQgLhF37CnYKB+nL 6s6X98sClsGJbG/v/C2CwigBNLarDWJMCTKvadScpp2+jHclsF0vxwIYshRvXmCpGZKN0AaILwYA R2UOotVKH2rXkKXO5ip3lbWPpbyu5v+VjFePXElVl+1fJ27qb10/EG/42elvwmuSkOn0N105FesK /z+feXfhhCnV2cx63Nc8e+ZU9bVPodop4/H2p9YHm/EarpaJqal7Zs5mB9j7hsZPnDSdbSdMaZ0d mlLTOjNUk7qnWf1ft8NT2eHmUM0eMrX2psY9U2NTavY2x5prQ3j91b6J1XPHXnevlVfvNbf6X9yr ml1sLrvXRPV/3e41lh2eyO41lt1rLLvXxNhE9V6MBbUzhlffOQ/SiVdD4dVMGcNb+984uhFvQGuq aafb2Pui7iL/H4MrgCEKZW5kc3RyZWFtCmVuZG9iago1NjAgMCBvYmoKPDwgL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yIC9Gb250TmFtZSAvR1FHR1JFK0hlbHZldGljYSAvRmxhZ3MgNCAvRm9udEJCb3gg Wy05NTEgLTQ4MSAxNDQ1IDExMjJdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50 IC0yMzAgL0NhcEhlaWdodCA3MTcgL1N0ZW1WIDAgL1hIZWlnaHQKNTIzIC9BdmdXaWR0aCAtNDQx IC9NYXhXaWR0aCAxNTAwIC9Gb250RmlsZTIgNTYyIDAgUiA+PgplbmRvYmoKNTYxIDAgb2JqCjw8 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjI+PnN0cmVhbQp4AV2QvW7EIBCEe55iy0tx Al+NkKKLTnKRH8XJA2BYW0jxgta48NsHiHORUmzBzHwwrLz2Tz2FDPKNoxswwxTIM65xY4cw4hxI dBfwweXj1DS32CRkgYd9zbj0NEXQWgDI94KsmXc4Pfo44kPVXtkjB5rh9HkdmjJsKX3hgpRBCWPA 41Sue7bpxS4IsqHn3hc/5P1cqL/Ex54QSqNCdD+VXPS4JuuQLc0otFJG325GIPl/1gGM05G8dEbX UUr5lv91Klq/eK/kNubSpu2hFa0FAuF9VSmm+mCbb30KcEQKZW5kc3RyZWFtCmVuZG9iago1NjIg MCBvYmoKPDwgL0xlbmd0aDEgNTA1MiAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMjczMD4+ c3RyZWFtCngBvVh7cFTVGf/OfexuEpAEg2wey931snlHCAoND2EJuyEhAfMAuougu0k2JjGBDMQU cKA7CgrLY7QUVHBQ+rCSFLnZMPQGKo0Mjjr1gTraap1R6rMdGfuiY0Vz+zs3yZowyuQPxj1z7vle 5zu/8zvfbu4JMSIaTxESqWpVqL2RGOXA8h56Tn1bqJ1sNJeISdDt9Z0dzj1/m38YeiaR2NrYflfb Z9IjbxJJO4gSHXe1bmr09awqI7ruacS3NoVDDd/sOHeaaEIq9FlNMCTeaE2HXgl9alNbx0ZrBZVA b4dua11XH6JZaDRhI3RLW2hjuy2cVAQ9At25NtQWrly7YQv0J6Hf2L5uQ4fRTGHo56Bnta8Pt//+ /rU8/nPgew17Gf4kQ8g0hj7cOFKGyoZix5GFxkF3cYvcT8nys5QjRyhdmkYKZr2D/i4fB1YYn8gv UPJAm/FPEQxRH+/CwIJ51E976BAdR6anIefQHfQovcRaqI+tphP0NptCN4FviXSqpJeZYbxOjfQr xHfQWdpPPVg/h9poErx7mdvYDN0DuY62Gb+gqVRMD9CzNBtZ99JF46jRC28NraAu6sb8PzJV6JGu N54xPsLJVSPnNnheNyqN4zSRCsB1Fazb6Axzi+8aTWTH6T5Kj9MTdISeo8/ZfeyE0WR0GueNCyTA m0m1aFvYCXZBPC49YDxu/N0YABM5lIdVg7SPfon8x9H6QZiP3c062D62X/AI9wknpO3y5IFvwEMu LUYro3W0Awz00Tn6F/2PfSHYxWSxQ3zemGn8m5KoArvkOwlTJ9qDaHuxp9PMwqazRayKbWE/Z/vZ m0KesELwCz8RNgqfiMvE1eIm8U1pgxSTd8uPWpIGLhmnjReMt2gyOeh2Wk9bsbuzdJ7+Q18xEbky mZvNZSXsDrQIOyT0sSOsT6hi/ey80MXeZx+yL9hlQRbGCZOEfKFD2Cd0C2eFV8Vmcb/4mPi+eEma LwvyEflji9v6l4G6gZ0DrxpzjQvGl/gG2VA3s8HxMrqTQthtO91CP8UujqEdx6mdo+fpJbN9iG/Q RfoSLBCbyNLZDLYUbRm7jTWyZnaYnUI7Y2L5r4CDEBKEFGGykCnUCnVCmxAR3hIiYoaYJy4RV4nH 0V4U3xYvi5clWbpemiQtlsppt9QmHUR7SnpaikmvybPl+fIyeaUckXfKu8V6+XX5bctWy15LzPKF 5R/WHGuldZ11N07nJdTsc6jlbz8Smwr0M2gt1TMvq6MDOI0jLERRVFcD2wG+2inHWCNuFRcL01EN Z+heVOtB2kI7xdV0xPiz2EV/QqW0ImWEfiOVkEN+BKdzH01HFQ01T25ebk52lnuqeqPLqUxxZGak p9kn3zAp9fqJKcnjxyUlJtisFlkSBUYFPrU06NSygpqUpZaVFXJdDcEQGmEIak6YSkfHaE4+LwTX qEgPIhuviPQMRnrikSzZOY/mFRY4fapTe8WrOnW2qtoPeY9XDTi1i6a81JQfMuXxkF0uTHD67E1e p8aCTp9W2tkU9QW9hQWszwM6EgsL+A+Hh5J4Yo0WhbY02THwCJ+Wrnp9WpoKGT7R7Qs1aFXVfp83 w+UKwAZTjR9rFBY0a8BJu8Y1qA27dA/VBbkUWu3XxFBAE4I8V0q+Nln1apM3f2z/Vh2WfLtHODXB XRoKR0s1T3AXyOVqkGuh3dAqap1IK2wP+DW2fQgEx9gCpBxuWPVxXMEWp5aglqhN0ZYgyKUafyzd k+5TQ96ARlX+WJonzVQKC/rsW+e6sPu+woWFC/k412XfOjh+ev+g/Y1+Ptq3nvsAY0VNnADGV1LL gVNz1puLqABbzB/hYorWF4MnfAIM22wGnkWagJoR3ZrsLg9pkdphGE3eQXDBFm8sIS2d7yFYEkB8 MJo8ByeF+GTVGb1EOEL14uejLaEhi8WdfIm4kx90vFY0FhqWO01isOsmu9rEz7fTPFPoqt03wgCd U8Mxa6najIoqv0tzBmDQKb+gQqeEKn8PY3sDOjO26+R19FECiXfeAXcBL7VmL9aHUlgAQ54L0k0F zlLsupTXijPqjJY3RJ2lziYUk+Q2RzjC0cA0MFjrB0+0HCt6AhlxMRwIzEGeaTwPpiA8GkCGlqEM GE3TtG8QNL2gAqeSVeWv9msRb4bm8QZwCijf/iq/1o/KDQQQVRRHCsRbmu1DmGcAc1Ee/DcPZqlF DqQIRKM8Z61fdWn90WhGlH/fBnWd0ZUGz5BBJx6Cjft0FqnCXAyqK4MbVJfqAqwA5/QWlPRwRek0 8+oMz4rjxswfAe0sk+Hia8Tw7LEwPGdMDM+NIx3F8DxgnssZvvWHY3j+KIYXXJ1hTxw3QC4EWo/J cMk1YnjRWBj2jolhXxzpKIZLgdnHGV78wzFcNorh8qszvCSOGyArgHaJyXDlNWJ46VgYXjYmhm+L Ix3FcBUw38YZrv7hGK4ZxXDt1RleHscNkCuAdrnJ8MprxPCPx8Kwf0wMB+JIRzG8CpgDnOHb4wx7 MjQa+TscueJnl675D/PqEZTjTQkvwSW4Z57HfUwkKy3SqTZfJ9s0nSR0W7JOdB6d65DF9yBjtGIU MSa8R6cwi2hl/ilkkjFOL7o5xZWSjV4i7dW//qv87FeLdGnp5V5EDd0bj8qa/84J8y5Rio0joJe7 bv12HEZD+Ps7fM/EaMkdyCUax74Mf30x6eG4x5yHhyBPpBJhtqmaN10zQqADQHU3EAqUjLaGyPpZ ogN3RJ6Z4eY2uIIFPlpcvXhxjS+/LNzaGe5org/xrGY+MsL8LvwdnyH/IGfl4G0B+kz0/PyFdoqw p+gh9CfRRWpmu2gT+k70x9CluHQUWh/bFZNsnlNsE6WzJZ4kSVmemqbYE5OUN3RmOXFYecf+4WmW hv8oXGBpsfGUsDCRPcmeoAZS2K/JzTbjFpjDDvbmtipBuI5SO3oEXTSfjB2NTZmhnGEF5JYY5mTR FImdVD4tKlQ+LtIFFlPOZusShuemQPNMUPodh5U/OO5SzqB3D7q6chFxUjnqaFX2TdHZwZjyM4fO MOfhweEeB6aeVNpyDygNRaa/8oAudMeU2fCv9CQps4pdykzHR8q0bN3GoBc6KpW8oleUqZiIMCeS uj0pSqZjnzIHrikOX/Yc9NOsix2iPHYo5l6inIKI7faW5xYf0Nm9vWU5RW6dbfbMKss5kFuW7c6t VNy5pdnZkFe+aN1mvd260DrDmo+LWJbVZc2wptom2pJt19nG2RJtNptVZ7+NLVAsp1k3LQAt3b02 i03W2TMwSqfZMdN47Hc2ySbYyJaqGx+c4HWTqrPuEygZRhBOWkzJorNjqHFuOuZR8H8dhm8Mfyaj SphZSig2gdkEWoI33j26hbbf0LnAvmDi/JTZpd7vewRNz/Az//s/dubQDuCdS+tyBPB6C8FwBIbD 7cPC944d98AVLsnPr6jZ1NvZ3tJovq6rvnAQb+3ark5cnyJ1TmdPS/vQXSQrWFffxN8XQ2GtXQ17 tRbV6+zpNOdx8wh3I3d3qt4eavQt9/c0esLeWKen08evLb11JevXjFprZ3yt9SXfsVYJT7aer1Vn zrtirTXcXcfXWsPXWsPXqvPUmWvxzfuaa0s2dKA68UqPV+qcWq28epUfN9eAV2dP8ff8e+j/skht 3AplbmRzdHJlYW0KZW5kb2JqCjU2MyAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNv dXJjZXM8PC9Gb250PDwvVFQxLjAgNTU0IDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA1NTUgMCBSL0dz MiA1NTYgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsw LjAwMCAwLjAwMCA1OTUuMDAwIDg0Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDE0 NjE+PnN0cmVhbQp4AY1Yu45bNxDt+RVTegtf8/1oDQQG0jkWkCJIJcR2oTVgu8jv5wzJGVIrreIV sEseDYeH8yT3O32k72TxSS1RjZ5+/EN/0jdy+Fj68YXeffjp6MtPcs0e1WZK1R6pFXqm4OyRnRfE XBbS3JFrpMtapchX+tz3s/THB1buWTkoHCV1/G0fuRqOVgtlF7FrM+dniofFD/YrR8NPyaBwi10W lo7SbPWNxiAngs6+0lTRJQidyU9QpUA/2MPb5vLCgh9Lp1LfjCLK60y32C8gZlvnWqdamYPs6H0n 4xcrP+jXxV0Q6NLzCPZLyJmc2EHWwbHLXk55OTctIXLgqnIbptYXzKjX9ESK6LnPy4+K3UgtTSpz pq/0HkHt6d//jSpCVAljMwzeo0otp9h2Mic2f172VGzJGTfCoSJKcfAeuqTYhT6Bo6RWcVRyO0r2 EHbFHbU2RS7QNBFkXo346kK8Ys04pRzO+2o2IZlsy61RtWBfwpZPNsx88sx0WHjHJJ+AdUeW6iSf JCt8nflk48wT6OL4WzPNpE0ioHJwhrJGjIe5oIuzQGevjrvU9HroWUIjmiy2HVkbzYy4wFx03Jnp bP9mH3MerDWX7YQjA3hP5zaJGUmwgeq+LEspJhY2ylYQ1MqeWwG2u8VeR8y27kHs38TAin5wHlvD +hzVOtOMhsSM8cDxXNdMIp4lhgu7RNAZqgfHOsfnTZUPqCG5UEJUZrQWLfLW0xaNPNEw9GbUkxSn cVOiKLYPGHb3cuuZUcBfS6hVrMKYo5P/oHRjvABveZmfgeTQL0YgJfLwKsJhateZYK4aYGqKwEpG eFyhXWbS7zqnU7cdBTHgomGA762ExM34YcG7NjB30VHvkM3OTk/yoRcaJ3pFHKnAVYxTYnrT3PGm gzdjQe6ifgak4XJnmvncHPTMIy4MEaLYsE4U52apIVg5OUoXB7L1uFGUm+NLiDhNMPaG6sV4hGlf v89eGY96NHOMay/kZt9CMMleM78bwuS6K7aNpdSje1L31r3sxLy7WMGEUYcYW3Vol5A6xNg4Pqyp PNXicpbZS22SOsTMVUrP/wsILPagDt2JEjnTrDs9SsQesy8DW2eX6tN6rEpvne6+kpuu7tE75KQv s1W4LvXr74G7Ie6y8xcuva0e3js0TPSn0XOfdwymTyGZVo7gc8qQ8kOqZV03kTO1dDhXcLNeUlGl RNNC5n5Yp1jF3SAiJ5amWl/uNxHYfrFSKT2NalJEzsc+w8VcjcAjgxv6diK1hE9HTIFv4vg2WF9g S4/cf4l9IudzfywUByPUgO6yEJiq4s7voK1YXLEL+gdkAMS5ZszRiRG1saF6LhHPIqY4VdIBCPR9 ELkOcc3PlIIHBK4Y6E5LSXixT5/DchsVERH6qkQA2affvZSxnHJZCDQyKuduIIVgn9YQHJ6yHQ8m 2EcRf5RaM7o7fOVyhgy6JB8EDh5rxhy84QZrS9xEQKSrHUog0QEj+/AaEcFzruDtp0oSGOz7yJzX TCoTAjehr0oEGOcZUbUYyynVPvy+83jVoW5rBAnWMxQJhksimjgCNeKmiGenIu5IFdkXoK22liHj WQZtPc41fY5oCHB+brijTBEAsExXq0oEGPvwmo4Y3LiPUDLfHEQJEou56D5zzmuEiopM+lMJuF2f Z1hINekpEx4EKWY8Xm2FL0OGNVIJ11i/W3EaYldOQw/uPQld4Xc8vwrmKx63fARJF0JXmUJpCPHr 3xpUvfcnvhXwB3/w3wCLjGe1p2d6dzrhuQdtp8/0F71xT4R3uqc3b/0T/U2n3+m30yoeppcRKAQ1 GBGZ95gZ7Moy94iZ/j+IF8SKRwZgwSNe8TGvjOtsQdw9JMaB2IVumYHXPWYZkn3FI2ow3m6yYS0x WSqoW8PvBf9dgd9fd+pVPHTZjajpATDceePbkuYmDuWJN3nENzwZ4fvxPzY3nrgKZW5kc3RyZWFt CmVuZG9iago1NjQgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9u dDw8L1RUMS4wIDU1NCAwIFI+Pi9FeHRHU3RhdGU8PC9HczEgNTU1IDAgUi9HczIgNTU2IDAgUj4+ Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAg NTk1LjAwMCA4NDIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAyMDM0Pj5zdHJlYW0K eAGVWT2PGzcQ7fdXsLQL08uvXbI1EBhI59wBKYJUQmwXdwFsF/n7eUNyHimtTqezAVv7NBy+Gb4Z kqsf5ov5YVb8TSWZHL35+Y/50/xrHP6u5uc38/HzL2e+/TK52OL21Znkdptg+Gxi3q3bsiLL00B8 tpsv5mkaRui7+VpnXM0fn8W9F/cgYfdU8Q/1U0zZ+r2YlBy+iMsJ89kVf0Ixuy34k7JwOGBgoViy e1mzA+f6oXgT+sglq40i5mTAUCaItAL/sFq/FlcGFny3Uu8LEfI6mSN2B7JM4xzyjT+bcNAZva9k 3GDlG/1tcFcEvhiPYnchJ+M0DzoOKzvy5cjLuZ4JtZP11rxOGLOv2MIVYkREGPdprCOxg9XwRJuT +W4+Qdbe/PeqqgxUpYyXlvCqKmaO2BSZ05w/j3wSG3YL6qStIOxCzxSxJ/MAjofiittu1yLC9tFZ n5zpCJaAyJ6ty2kurkhIissh8hfrqmSbN1TE6mxwo6qg+kZ3FNUEaU0BaosZQv+w7b0yci8plk+u FaXfjlLS8srQ9fCGzzr/CQXFh+sfpU5MX/FcK8R0JQWtjShJl/znxWd+bpz0G6zf+Gb+LDUwvtE1 XeMSmvplTrQV+hkWM9ZShQzRrukXKVK2Xb9AGI3qfsY4jlYHBPV+Q/dnqz5Ujzmawqvisj6w3oVD z6JIMo+nKeKu6eoiGD5VhS+q8IAceB9UztK512QdNh2VPDSmCNXMUQ0Br1f1HdxmI3g3gUuoLVWY WwU2oEUhFTisLgS+b5Rw6xQw0ZSwxerGksGw7xisC23fZ2Kv7WConH1/QL3pe1JUgGFMgygLbhae EiOhhTLs7Q02VyIhdrRSZHjiZjH5UmlIouZy6THT/7Ab/p56+pF12nH9tGjGijJuLRofFmIcdwO5 WTTnUpJeSQXMVdPjUmiENaqFOwW6lnal2U5lyJ0Cdoq1nUJ6+vGMBGceZxMfQMwlYdi849jQhheH SjtikEntjbBrco+q+6gnneK68mDTjd3c0eGZWteWDgx9mR7Zu+Grdmxymr6REcTnvi6nR3zXFx1T tJNYVLEgbPboctbXz785txp9Hf6nCJtQZc7R1+WpU6McBesBSt5bFjVB2zLYan67+IQhc07sZURl LONu9PV4rgBpd2TcBFmW2rj7wxxRV2I56+xnMXcNVgt29oIeN59dPGIOAVtaXK3D/QDT7cWueSA4 uiiCw7zLsnv2UQuOOB15tbP7gIuHuN0jji5htHbXY94l1lb1A8JcCvXOrgrdtJHjltEKG/Ktywbg hFNDLewJo961ImDXu7JeMSBYIm0hQIqNemJ1sDqOE8W0kz8uY727yP6iGNthrwxqFGWh3NlEuVWN U8uIkFbXxvXbwBiHjKp77e+g1S8DV83oX2sHqSemq6Ph9CPRiBl5UBtNwx0AymZ58RpwRUoaUks0 VpY92/VjEVZyRK5tfDYjNpk1EbSzUdeTdvZeR1c7+xWCmgOVFWa+hOBRoTdpfehF9Q9PVJViQ3l0 Ti2S1KRZxfR+fFP90zgu8hWtL2RF/VzT7BE7IFfUz8PMVRGr1iH/g9YnYZDXPVrncjHm01H+uqS0 OQA3t4gLKY1jzND1LGLqfxJxU0C7I6iIOzZFrroWb+2+ixpW/bc9o75sshve8/AfvGJyUjh5W2Ju F9tnRfA+qVifcQIRk7Wsm4kFuwwuvw5rgDF8xtq51ebsokKLWxGLmNAJgTYPxhDBtTvLbYdO8jbP A27tWeZRKjSp9OvLr+5EAZ2nvvLSkJcaPN59MQbG7ZONKTiPGKLdI07Q2CndEXswPnm7r2XxW9s/ kfOGGL/hLVHx2A2wtWYX8GELdY/1CW/WVhxb+jP2hFjstkbsqQ1afMzdRJ0QaPPIGDVZkbO68auT VOZ5sLe3Z4whFZpU+phXnZC9ziM564zPouzZ8PuOT0nOK8zQhDFDmOIiQ/CmwZHW3Rmawm9OppQp 87szhPguM8SkjeW8J0NnUbYMwRNuwpcZGtiDiXtoV2VcH+RtLTYUIsXuIeByvnubVtRmwulObOIO Ocr1uj9jb95xMC9lQHEr3a06IVDnwXlomOBI56G/4SRs5/P0Z5mnUTGJJpX+kuRc2JycxyNt8etg zCgT+CRQQBBJznuQUELgAiFOhR5MQMtPEjPrcyC9LwXsR1tAjWlfCh6+ZUzrU/Xsl22s9HrrCl74 ilt1QkD7xTDpfSlg/xIn7EOch31pUOnQIKtOzuMBN8nP8KTdd+QHL2TQ+PyUILxXIQYFgVYAK++j zVVADcDxXtIYkRfEFuEDyCYmEf9hhD5iWWHpA+TTDBZE2Q3oQYE6h4xQINg9J4hnuPDTHGBVH2UE SXSDShtT0oMCfY4qHFIVEFcL5sUH5MDhN5AhHGx5xNB7agP30sD92huW2+W3FbydXfovK3gZVhC7 GOGM3fq+S81IfpGpP798esQmVR/wH+qxQDMy4vHZfHx8xAt4eHv8av4y78J7g19OvHn3wb83f5vH 381vj9M+WzcdbLa4Ue+bLdIXLqnBFalJK61Gd1PzGTuyuL1FLb1CLWHRX6WGHvZGathlXqW23aKW pPloy8AizLlb2rJq7rSVoLug/8L03gzuqU+BbRrjFuYRni+X2N1Hdo1yAsKSDxG+yBZ1XW3fTLed ofxNvhDny5Jkcn0AX6mrO/hKvVXbt/JFs6kDb/KNg++X/wGBgtMeCmVuZHN0cmVhbQplbmRvYmoK NTY1IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEu MCA1NTQgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsw LjAwMCAwLjAwMCA1OTUuMDAwIDg0Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDQ1 Nj4+c3RyZWFtCngBjVSxbt0wDNz1FTcmQ1SRoiR7DVAE6JbEQIeik9G0w0uBZOnvl5Ilym0KNBbw nnU+UkfqpBfc4wVBR1oTFmG8fsNn/ATpCHj93r4FPNxVmi+pzW/aG5fkhQokRy8lu/0Z4oM+TCh+ 1ScT/oVdJi/5soaFBMdLEcQe6ZaRayDYwR00Fi6IwXNYVYfxIh+hPSmJM8R07XiLvQNxpzhaD6lV w1iRuYmhqYq7rKl9IJrL6hnYu5AdNPow4twFs19kuoh6JwZPtRrvhFn3B+ZsJ60iQ6zufe6jYW9Y M5NxdvzArRqP8eu/roK6aih2veGsrrLOGXaqjEbPTzzDJs9Rt0PNF3unDLvgUTW24+Gz+t5+9FDw GnzSwyIp+JjU5W4i5CWlrAJXnyVn5XDj8LL0mGNed794ier5ScmV4iRZkgbYOjWmI7J6liynJLL8 uc4xby4bUgZlyLckA+j11B16OpXcin+4c7OGXjdY74AUSVuRVVAurA7jqv4v7FF3W/LiS6Vw6AQq Tu+bp3nbxJankdTjRxZK9VJSOW1o92830DHRvwQpsaV12zM+bJtaXvNtT/iCq3QNvasYVzd0ja/Y PuHjhvvfLYr7kAplbmRzdHJlYW0KZW5kb2JqCjU2NiAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURl Y29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgNTU0IDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA1 NTUgMCBSL0dzMiA1NTYgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBl IDEvQkJveFswLjAwMCAwLjAwMCA1OTUuMDAwIDg0Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0v TGVuZ3RoIDEzODM+PnN0cmVhbQp4AY1YTY/cNgy961fwmByiWJ+WrwGKAL1tM0APRU+DJjnMFkhy 6N/voyRSGttxOwvsWhyKeiSfnrT+Ri/0jRb8pC1RiZ6+/0W/09/k8LPQ9y/1u4V++8hudk11/K4+ ZWcXXyjnZH0K5v5K0S788bTaDZ8U6Mz2GH7JrttSlkztIScKfaYpLVZQC90Jq8n39KCwWL9sLg5b 8D0QIuJZUJj7PPrpc/VyWwPA8T15X5fQpYzv6zMUfa7AdDR/Mz/fyU1zHlOCTpd0bkR9kJZAYz9G odQmRTcCVgykudxHxdV29DpYULev9AEM8fTPf7Wf0H7F22vI7UcFZGSmjJzUsXroaPbo3eMYgZyM HvSJXow7A+RSAJ0SpbjZDO4NQmahQhmEHDbg6qkLD9GGRsi0CbmKZLcOC/e9stSpDbE6LZXK4Kzv Xi0ooqulp1VA7oPNHCxHn3leb22u1O0rdk44o6g6b/LArpYpH7VphmIxBwswOKmDeAFDZwPq1fjN uBwkAx9leR6cWIX57KfV13jaIclo9EzyBl3VS2z/y3JJ8x2rWOY0s85sZpVWRW1TBTq/8+wntrkC neXVL/RKqa0yH6r8860YfbI5xhMlzidKDJsSX3TTyQ5QJc5hEqqqU5g3KXGNslNi2FSJEVGVGLEm JW5ebQPsnmclbnQWJcbW6aovUsxEHtSZpfj5m2evIcWIP2U4U3VE1VaG2aZn1p6kXqTYCf28aHFG 7fY6my8sRol8SdJ+FHcCnGgxSj9pcW1aZzG0tWlxY+cYTUkrB2ct5r0LLab3H384+vIDEu1sKRt5 3AfQcrhiq4YQxfAYhjXbuBTWgzbHeLV8pc+V44jqOerh1sFTAu4hfttsCrPKr13ly4Zce5GHbZB9 7fISReVB0crschD5UsBY3drqdRB5zFSxbrRAcLU0jgPWQeRRroPXiWWa1/mw8UEjx0qXRFyE2t5A cRpUNGMnzFvdu88ivB0k/XzeXuQ3lFSlsIs849qL/JOfIhORxy4VsNozScioRdIe22eVLbWNXqvX YR5Kf3GVOeGUJtb0HI0aGm/UNhWg76LZT/bSUwH6Xqp+XeON2tqOqldyXGFw4ZZfuIhji+Asopy8 dRCz12EI1gefaOV7+JpWk1OsLiv+1BlteKcVC8YSOUj3QKzqISFk3Na4m1UMfNfHXp4iLM9rtCHW 6CiwRveouAFKQjznwY35PGVac8a/Gwq+QUH1k40pOI9I2S5hBfu8ayasJaZP5HKxGw60kG2qdVLD anPwuTosPuKoC4VdjMu5zahDUMxBwopLUTxgiM1DQ/RxW4NnsMGkAJA+pDlCrDB0jTbkGaBYQyEe HXcLAVRPebQ6aRhJTqqCWy+SCMtTWcRWlbrzJzpvk2P6qSHY7APuw9K56IAILr0FMhz8MWLq9Igg fwvR6CJrYIYY0CkXJ/5Et/AaRteoQ9R+QtFMClNCNP6MNZg/LQxwSXJal+hw2IAHE1uGCWwpqCRk sp1Irzpegc5n4wquVAu44kupZ5YrqI2O+OYbbNhAleEACBi1APi+DWt8qJCMcUYu2E/T9PgUv43Y XwGIQwPcAgDgjL+TpGOUnLQWfgPn0Ky5GGKrHPHYSQnHKi7jS99abuVXAnwo9xcCrB5YEz44EOqO JJeaD79H4JcG5sONXBvgT8IrArQSE26v9P52gw4g1u0z/UFv8lvCywRPb965t/Qn3X6lX247MTDQ Pmxn0Dsyva+Apbg2p3NkHGmHLEGVatgraP4Emqk6VaFFl7D3cQm9KBlTjn3OgJn6nmUHLCIaT7jC Fa5x+Q0c5G5fAeP2V6cjMuA6QxYWMJrDXkGLA9rLv8/7p1YKZW5kc3RyZWFtCmVuZG9iago1Njcg MCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDU1 NCAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzAuMDAw IDAuMDAwIDU5NS4wMDAgODQyLjAwMF0vTWF0cml4WzEgMCAwIDEgMCAwXS9MZW5ndGggNDU1Pj5z dHJlYW0KeAGNVDFu3DAQ7PmKKe3CDJfkUmJrIAiQzrGAFEEqIRcXdwHsJt/PiDouhZwDRALuyNFw dna55Cue8IrAV6tizhFvP/AVvyB8A95+tm8BXz5tND9pmz+0kYj4PEWoCj9kt16QfdgexeQrH53x HnYePPVTDbMI9kGZka4r3dy1OoIVcQfFWDgjBR9DFR1Yoqeuy3H34lYcZv8cN5bUZqNs+hExthAM e43l4m6qDEeGHFwaZr5vkKG0Qnp2xjpjVEHMEcv1DmMonUc1jWc7Y7kYYrmuti/OsFvWLbLiBY9s pIjf/9UlltNe5NYlViHDDrlLr/Zl1Ltj7sjbt7qw65j41ols446d8UyPrd19YR/bD5tcYvFaJ6dp 9iVWrr8i0FT9lJISYE8FKdDMpeRIzNsam3P/GDTXmDvkhMVulCHSgT3OtqYjk9eY80EklWMcetvn 25puxSjNPs2aSAd6nBecRsquJc8zbTlY3pTOmoQnKBcfSuUBiDzmf0HP3GvN6pWEGK6fZXK8PE7j 6khNZOOws3cJHtPG2W6cdr08LpB9wj/lXRKa6HJxH5ZFfKDacsI33E334LUTcfcg9/iO5TM+Lnj6 A2058hkKZW5kc3RyZWFtCmVuZG9iago1NjggMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUv UmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDU1NCAwIFI+Pi9FeHRHU3RhdGU8PC9HczEgNTU1IDAg Ui9HczIgNTU2IDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JC b3hbMC4wMDAgMC4wMDAgNTk1LjAwMCA4NDIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0 aCAyMTY2Pj5zdHJlYW0KeAGNWU2PJDUMvedX5MgeNuSzklyREBK3ZUfigDiNGDjMILEc+Ps8J7Gd 6t6p7Rmpu+JyHMd+eXZV/2M/2X+sx3/pxbYc7Zc/7K/2bxvw7+2XP8c9b3/5idRcLWP8cVwFH50P 2daSXEnm+c1m5+kPItfpz35F9KpaxdXuW052XhzVpjnPtGmosMA+2zhlQUSvNnkXfYcHa5pNcZmC TVwvL8zzNnjncqiEvtyG6WhjZOu8TGT3xBeW7P6J7F7rTgLXQrMy49XqxoP4EsJXNbZZHD8jMsmE 7EIksstnzYTIWMvcSaxInu1f9gfgJtr/vgUK+/ymueTovmkuWbRtPHAyNzWWmV1PMRaTDTx6tZ/h Wviaa6277AG2erhej4HXBZFaCak6AEYXkASbDDKotoU3XBIsZQTvbhAJDYHkhsgxUfA5lab/5+sJ 3BX3ZndUwtoNKgEjQVKbji000B1Gxq2Woo/sYy8TdjRQ2M1bbA3bXHjLjMuGeC2gJVyKx0CYDr56 iS1egOmcMYAJHk7IIFCEDx29mmYXTNq8JSPa18LHuCVooX29i5bgiwugpNyaO3o/0RuZ4ZMC43eU Vhg+NF/PdN5owmRMkxwCXUxdmItryuD40o8hiJ6mCTmBIBcMTEQKmCJxvRHmzZ2zFgGAXFHiiUgw 5f4kHSOmGbon2195L5vEY3W+b+AxX9ub68vc38T/xCTBjxSPIoFCRTER/1EOduY47QKbxb005xmM rvKPGpK9dzkGAt7aw6ELqUwpTpBwrDNSKl90NoEyO6vboRLNllkLFcrzzK2EFtlGxcVfYKPEL0si ASCcrB2KjCW89GZJdHQe8rSMEtaWLcmzeBWnq4DKtEGYWfN0PypjLSB1abFEdagc8k3WktwecAZR CeFGQ6vCoZaYpEpX2bTooTVLuwQWkrVj8JFqcRQekVxjWbFEPLJCfhByd6xuOMa9d3GMeytIRtEs sktMp+oScp9Bab4PWHOTVGGLK2CvMMIUljuDjUtgxyHglusYRKMjBa1ZdXxkbTIHTCGDq1JT8dxH 712TFpHITnvwhI8GqIjq3iQ8+p4jlgm9MXaIJ6kgjK/pFhgXI3xww4fLQWGDr+TjOsOnyI4kr9qE aFGOdUSrr+TS9xhyXWJG+v6nf4P981+LAthD9cHEo7gEJoKpTsnHWVuSV5WgscmeTPA0G0X0l30Z XREsRwPLd918PKJrdDZ6RzeflPOw6kxZ035+k+H0zfMB2UozX1RGTGsL89CZsIBEOCKKDLZWYvlR AHqLgbg+ZpiYnMRQgl/CXSoz91r3km2etLfCeVJlsxGvpMFe3AUd7le3/YjsTsvcSeD7Os6bLaRw kBzFa38QmEJZU5gPerImMx+iLzLJkGKc7fO+hflgi2Wa2QvJ5bm4QZWyH1aZndxAlURFZFsEuPtX rozc6vU9AvIMIKwIvQeeCwKUaiVK6M632ekxS2FNYUUcLCFFeS5AI74e1IQTB7JZrJAG7y5NUN06 KdtDwQSxrKt0SMy1dnF6IOjwB7cko0qJvA6RIF8TOnWkDwQoj5v87nH0DD81QKzFtrHFuZ0jiexM p4Ke7YEA/dCGM7m8fiC4SRWRlDDriWaJBM0JOAIZuqW4IKzoaPaD45WIO/Cugz8MXoTQ2iF1WzOa Ql+wnEqCKx5EH8LhYk4HdOLQCQEPEWPOHCO+AWcx5WxUJS0VMcKCuQ7NWZLUXfJYmo3YmhqtY2Sd OSZOEVeWSJxVI+f90Dl+MbLluXm89xHbsu9YXC4pAJYZJlpCRGO4FZnPaG+yK4BXOZJrhYqXSrLr pWAnPrkjRbTLKGekQy+V5pw5xk48bMeUjar4pSJGWDDXoTksia7mA0hbRrBOoHWMrjPGFDF1ZYrU WTFy3s+MmFriXUp8ytFpeepaJUCbDBFC3xl7tLkWV2pGD6aSwx21EaaQ9H7gYaFW0oGgrTlzTLmm NOCWqgCHPZqM8r+MDAGvw/gYK2eXj05mxQhe553WGWMczM2VpSLusxERjP1gndF3iMe8S4lQbkh3 jdRwSoQ2GSJUmgsR3NkqtkS9lEoI+/4woeAW3Uvoe+g7lGPNmWN4XorzES8mVSUvlWkEGkNgeB2a wyqwRm8ZNyPlZp05pjniyhDBN3ZfjLBg7mdFSDzmXUqEkHvXcwpgWYkQyxA1ihC4BS9mU8KxbPTU oJLDlUYYKuCWShFCmwoduAVuGXPGmPCA4pcqRWiqQIDIDBU2IoK5Ds0ZKialjLmEITWShi+6zhxT hMQVVmH3pxH4xgJeZ2BIPOZdaoRydjWBTPYILRmi9hldMOpnoufU2SCD80WCMxRAPyTwqeACr3uo iY44kXPOHD+bWLNrEVyiKiiuw6wYYcFcBzW3sgTtO2gfgmkEfSCOzGmdOaY54gqrsPtihAVjnVEy XzaPZZcI1eDpBCLOeTxsKIZUBgyhNe4+4S0hdo0tAkNTguoIbw7C0OieKyIECekENByYI2PkNoLu OiC4VExAX8cq04gI5jo0h1UQmEIYUiOIna4D3+YYc9QVVhnuY102It7zOgND0+Ntl4IhVG3X8hlD mwwYQrEDmaLYgeJmVEM1+LGEHqvWTyVpFETSAeEtnUI/qLysX1HQRfzwhEIzhvgq+O0kDKNPb+b7 pye82YCtpxf7m/2ufbD4mSXa7z6GD/Z3+/Sz/fFJG5J5BXtoJVFkIhWZK8dKhS1SetgzlIAxwzy9 2Xddi9euEZN7Yvcr13LDCzlSeti1jFpAMy5dS9euEYVm0Oqla6mDHknpcdeozyC2vopa/oZr4C4c xHLtWkaBIaWHXUsgZ5px6Vr5hmvokToRyVVCiW2G0uOueZAAzF66dly7Rqc10Qm+ci0itEPpYdci ahzNuHStqmuf/geAzs4WCmVuZHN0cmVhbQplbmRvYmoKNTY5IDAgb2JqCjw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA1NTQgMCBSPj4vRXh0R1N0YXRlPDwv R3MxIDU1NSAwIFIvR3MyIDU1NiAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9y bVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDU5NS4wMDAgODQyLjAwMF0vTWF0cml4WzEgMCAwIDEg MCAwXS9MZW5ndGggMTkxND4+c3RyZWFtCngBjVi7jhw3EMz5FQylQKPheyYVYAhwJmsBB4ajhSUF ewYkBfp9V7Mf5N7ujvcOuBvWNJvdZHWRnO/+k//uV/yWvfgtR//jH/+n/9cH/K7+x9f+bvV/fCSz pZXeftefQszLumXfSlpKcucXjzZ+gm/LTj/+FrmYTVnajt7J80NNPkmvjb04bZ99FMhMLj6tS1z3 UA1KUQY3x4ZIOO7sX0NPAFOnsEuEF2eOYuxx5BFQ1LgtakOmTBRzt1a3yNkHnQHt5y9eoRQ4LHfx Icgk3DGbIJtyw3TlNB2ngOV8tpUz6MbmBjj7b+4DKBb9r//jjwd/NCOd55ex8gIhRzUKOs+TlWGT 2SAjsmV+BmXExX9GdO8//gz+608fSlz2lnzNaaklgr6hbUtAYSiCGVak5KWlHcsgvVw15Jv/gur5 RX4j+b2tHAyUy+5ra8tWM6WOMuqrWJJ/cVMDBSMVslZ5KCCb2m7jkcg1WlYhReoIjlMcrvBsAxLF R+vRM1k5WfuCvGEnbFHuFy98wsM2nntg996A+7NVmFpYPy+8prFCGIb0yrxdbE6cYdniyt7iBX1H 4/4jyOo7Wd09st4u2eaZlLRklLC1KEJhYnH9lbaoakEhXj3qlUaLuUi8ueFLArViasqXIbXrxBQV 2xlTuQXGNT9I1IwrjisKNkarR1waFlh98zgxpmvsc1way3GXS2M9r1kytx49k15OHJkSZKm8Q6mu DJgCY5Exqw2M9W3NTomvwMhFZRKujHu3VjcI5k3I98T6D6nEKMa6Kw6aTlIcsqzMUmuBipr0ESPd XUbGukP+wKpUligK1r1F3f3b2P4nDHFx7sCYP0akpvxDT44MNhw6ENs6o2HwJacA5TLsZGNWdsK7 IVx23dcNphu66uDs6V4/Wdut6yAnrqqTnEUlZAIXJSGl0jbn89hKDwdQWp4I6idHgQnTlaT5YoJT XHIWGHbGCdiZP6U5Zt8wWyGheRprpnmDr2al2FPIIc9fsYp0zpjAPMe6EM9lxg2bZkD4vc12is0z IJzvdnwuiKrFNHt0LrjPfHQM6+4zVnkNmWLktcF5l+NCyd3DwFY+p+26Z9mGHmXq1uSYbPAlEpE6 U0bLOF8GZiVUcByOFgVrscU0vZmt4B9v4tqZrBwuWlnYyUGMzeEvb+PUYoz+stBm9LW44Yz36ysU tsq0EsmbzYVwDCPq7CAWxDS1Hj0fni7j9TqRZlqMYRUtpKwVdYHWDdnh/0BpJ+F9+pAVIe9Lwuaa alzKto0dGicXGaDCDy/qjKkeAmM9zEoPqKokXmUDg40ifTV6FUyYccNuRcQHsVLvqnRTXMQAsbJY n0A6v6Sf8Edbt5ci4o2+ZS6Nlr4hXuizsmtYaY3TLDDH7r6bmFaxUecx58K0GSGm2Zogh0fPh0x7 tfZjd0akrFA7rb1lppipEeyEe5JRZ6BMF95NGtVbrE794o57Cq7ltTj6Q9f1kHa6kPqW1yWvBeMO JCxlRSghbUsKqcIG1xDYhNSkT29jXfEWIpdxujQT7PPdrTlRgMehPoIggrR2t+zENQx4NY60qY+G YiYS/nBylQ9io9tVz3b8wdeJkYPmHQvuWClgR8/b0lDXFx/DNYQV+OxDbSjZ7GvlGx1mzJCy4AsF ZqzWpW5bhU3tt75Qi/Th9tkF9M5tJzdqgq8i3a05UYDHQfZVEdw3U8ZCiBNXISN0uxzjcJv6WChq ouGbEwX6ODJjw5NmafNTW1nWvFFN2QRN2GcwNy9b2V1BBYFNncsd8QVnhpgT3fegTBVTVfBRiGzi FqmPtWn3CPh+BE6JCQ43q5iYEwV4HOqjCD5sJPSdnKzzOIiN29THQlETDdacKKDjEKck4jlLZVBB MdWCI9I0QxOGGYJcRhyHc6jLtvUZYsTlfs7AxEQczVIChzIOcGQT6ZjY+3Abkcd9CREcMhNoBpuQ LqeKe4cCPA71UQQCv9EMDSfI8mocbqOPhILg1ETDVyev8uGqGxFbljJDLsNli0hzmqEJoypDfSRI NzbKjI99VGWClHUptVGV0XfEUl0qqFPYBFRB7yNtYj8mke4bwwTlTm6HEwF4HNKyqgi0hipyOMnt ehxpS2UiFISrJj1Yl6Al4uQ6H54hi9iytCpLZV9K6cquVYZEDfuMowN0s8ZJhwYiEpIqhBQCYyKT oFTcp4sOsk3Qh0hUVR1KkCo2MScKqA4NE5EQdWI6NMZRHZpCYWgEa06u8hEdGp5UhwryLrnS1zB0 2EmGSgMTriHUWBdy8B2HVZHx0Bw+V9PHNvlYnWCD/YIOcZiprv4B2yLZ0Dfu/kH7w8nj/Ee/+Ff6 12vqcHpx708nKAR8nb74v/yb/a3Hh+7o37wLb/3f/vS7/+30eufBjosVaxnhQkCPAiNF7UZPR0bz QT3c6cU/DC0eh0YqFYgOR6GVHNjo6dBKLr3HYWj5ODSSh0iScRRaJiEio6dDw37dexyGVo5Do7pc qVaPQkvQlW70dGgJikc9DkOrR6GVhusFFwY2DdTK4wCvaohMnw2z85TKEfso+h0Gm0awn/4Df3Y4 sAplbmRzdHJlYW0KZW5kb2JqCjU3MCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNv dXJjZXM8PC9Gb250PDwvVFQxLjAgNTU0IDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9y bS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNTk1LjAwMCA4NDIuMDAwXS9NYXRyaXhbMSAw IDAgMSAwIDBdL0xlbmd0aCAxMDkxPj5zdHJlYW0KeAGNVz1vXDcQ7PkrtrQKMfx+ZGsgCJDO0QEp glSHyCmkAHaTv5/Zx90l7ZOVkwDpODdczu4O+fi+0Cf6QgG/dVTqJdHXv+h3+ocifgN9/Xx+F+i3 X5jmj3qOH89PKXUfU6NWk28luesrFR/wk+jwg38qvQG9GKv6Y4ReDpofjkRZ5rl+BorDELoSlpvR lUUvlINPYcRj8XISlkZ3hpiqK91idyBumxfHlMoadMWUTjFlqUoidWlXBLEsH8XuQq4UtQ46z73Q qleCohilBsoAZowNs7or5rSBlooClu/V2mfQDUcAZ4wr/U0fYbVE//6vjwg+MrFS5eJeV3EU25OK BVazgmK0JRyl78zIszDOsBd6gq74lq7c4euYqIXk4+isSxKrYvCj0auWbMPM4VWcnYZavItRMVO6 2AxZlsiGIY/vLI6ZYri8ohsyUz3asmpeWm9YK5LOwzYzlnSvw16GiS+wU3XjiXW6Vj9zkXnzo2C3 mJMebaxbxCy+sbSfOG9ynPGhS4z+Ns90vKzqG2ad1IxWHzVv6DeWYXcgqP07bn/DVeaE6Wx2lVXO GbZVIGqFF48M23mzrX05P6vzO5z1Q+fHge6ORJWDpricH7q4CSGlYBukvgc0T5asFm1RHN3F9qBo DuaS6BQy0+vmAHsesnFFNkSTNOtGFalHvwErzBuTrMfm90jijuzE7225W3wLjspemSzshqU74Jt5 cqRvmHaRCyV+R8fE74tnRz94pkP9jqobNn3LrPmQyuJtIJo3fGssxe5C3vX7d17iW8L0O1ae3j7t KSe+QVv+5mxzOy4nUvM9fznTN7eDp32ebj8vO77hFmN/cMVJJftUo2t5+Iq7BNaZCLUCYoroekk+ 14rLToknJ+E/5tgYvQc3llYUcgnhJkWDKCDrYI4h3ZeY6hYkH/s60DbHvI5KMcopn1q2IArMfLg/ zytldyaPG53lIHpe2WoBOVTc6Yo/cm7wXDpusSdKoULx4WrAXXCcJ9ZEqAb4NQTULBRfuXgVD1Dm pJB5jo2RC77JMRWFXMLkSbEgCsx1eM5Eyhi+DTzqLUgZfV/H6ZjniBSFRD5tQc58IETX4ZqJ4i1L qxCfjRnX3r1CG/ZEeRwoIbLtw4cjw1WCuIrjNR78IB/N98IVGig8OHng4OQ5MsaRNopvmStklCyU GcTlIYCsw3MUgftbx33UgnQ0c19HxjxnSnHVKCrfgigw85muMsWWZW3Ym70W19CoXAPfxWpDEGC4 SxkGD502S2yz1MRksAfeQJ7X+0cGqfpJwvF0ujNWd5L4veV8Sfl4oTgH+Mfuxc7jsJdX+ulyQW0R 7/JMf9CH+EB4e0n0IeiHx/jg/qTLr/TzZe2R+YnPBjwEk+/c6Pc0cucn6V6NOGjmjLs05vc01ta0 usF3rviPpX7Ticm9U3HDaT1bWOci7wp3s8qP6YG0uJ/+AyPG23EKZW5kc3RyZWFtCmVuZG9iago1 NzEgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4w IDU1NCAwIFI+Pi9FeHRHU3RhdGU8PC9HczEgNTU1IDAgUi9HczIgNTU2IDAgUj4+Pj4vVHlwZS9Y T2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNTk1LjAwMCA4 NDIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAxMTEzPj5zdHJlYW0KeAGNV7uOWzkM 7fUVLJMiiqjXldoAQYDtsmNgi0UqI4/CCZCkyO/voR6UbM/MzhjwiBRFHZGHlPyTPtJPcvikmqhE T78+0z/0gxgfR7++tjlHf38QM3ukJr9po1iqLe4gf0QbmM35O0Xr8Oep0D6+qD7Zo7qSAvXBEShS GWsinckPwUS6UHDWu8piE9hW/JWxDg5UU7BsEx4ZmisT78T19Od92yOtzXxUFITxwgTJTHwys4/P xPMYmLnomYKHwDxOuE+ZJmgYIM3YKSRVOKDYhPuhwaHO9I3eIZue/vxvqgipmnjZIVd6FnZmoed4 NbUfjCXDPoyDQbrQAzbnxzbnmm1C7rgWm2NaPHFloHBB+bLrJm+gG8RJY5B5BMR50w8Cmx4XsE9z tqwk551OedkF3/CzejeqGU4DfN3rXqAx27rOuLmXplfxIPcj/nzFuCbNGeHLHHerwbhmNXOGKOyU u53bOJdZPI6QFVJUS7NYB684wz6zj0E88yTxbnK/iAefO/PQbqQuZy7NTj3MLerJuo17mJvce/vh N9PX3whAsN4H4sS2eG/QicphOWNh12Af1WRvq6vCjrlKNd/oCx3wH6r1zCDoMDFTsy1K4BYYfmkL VBAPUhFA5gXZXQcNvlrHCWfI1oW4KgPwj9bx4FQ76aablQG7URmTxEemMFaOykCap2ZVhl86rYxj 6QbDvXqfleEXLmX4ptN1iv5OsyrDC6skiLM99l4MuL1ScbMo52F704tnNfitMobVo70Ybp9sxthG GDa6cV6VgfiOypi1IppVGV3q1XA/frYybnK/KgNQ6sq9duapW/05Sl3svXtVCXzsVeJXlbTr3mbc 4/gy8iWXPAhuDxyAS7LJi1NVZJt9zFA4VBPYxSgmmOBmHiuaeMYVhO7ORTYeBscwmB7cVLQ90KRV EW3khCQMF4ZLuN6jiVixQHQDRTk9qKLvYaQE2yHXF54yC/w4rjDuOALA445KhYUpPt/oEPkHSi7a Cib5zBZli1AtDfhbXW4KFzJilkOzSQ5dpq3p8tkkJ70Jr6ll4oaJOpmKvs8ZbqfGWVeQ+unE+FSv 9xmyrAE3GxQ1mfDVyVS0fVCdErKFWE+ZI9LpUZMZvYpbR0653OkeKMRoMc1Ha61ov6oAFg7oTxEN OoJTjIejdN8QfV/RRTSWiCdTACOWhYOFEXG4EHnuIZd0HArE1UXU+vKAqO17NFGa0EIxLQZudbGf A3tIYBRqvzeQ/REXcLbYWtoloHHZdA94mAm5kDmQJ01qHfLelltivLZRghV3QjNClDonk2lG8kpv T/J3J7kt5YN/4JDDO0xWnL7T29MJoYO30xf6l17xazqCzW2AR7unV2/8a/OJTn/R+9NtYaAPpCw1 2rKMypAsPw1VTymM6LYvRHzg50PbBIO28FngZgDHWV4AXEKOHyZ4sTwSY9PCp8AZP2C67QLe8/FE qCdwrqEtNM8CpwE8LOAf/wO+I6MWCmVuZHN0cmVhbQplbmRvYmoKNTcyIDAgb2JqCjw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA1NTQgMCBSPj4vRXh0R1N0 YXRlPDwvR3MxIDU1NSAwIFIvR3MyIDU1NiAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zv cm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDU5NS4wMDAgODQyLjAwMF0vTWF0cml4WzEg MCAwIDEgMCAwXS9MZW5ndGggMTExMz4+c3RyZWFtCngBjVc9jxw3DO31K1jaheXRt6Y1EBhI59wC KYJUi9gu9gycXfjv51EUqdld57J3gC29IalH6lHSvdAneqENv2Uv1HOk7//Qn/SNAn43+v5lfNvo j49s5lsZ83djFHvwLSZqsfu0NXd+puw3/MRAze/4KYF+hV2WXfFt3/qWSQYtU5qerkusaAidCSuN BRZ2obT5uO2hLSzFaaXRnSHG60z32AOIO/iFXagSOOiKMQ4yi1Sc+SzqiiCUpaPYQ8iZgpZB/dyF VrmC0QphFkLtQNXsDpgVXzFnG6kJGWBZn9cuGnZvpYgzmzN9pQ+QXaSf/6spgqaM8Cx3cM+rTIod Ewta8oOdYYcChCkGjpdmoRRDvCdwfP/xR6AvPyjE4HMuVHPytWw7ZB3y5lMNC7oo5GrJvqWOGOZn yFf6jM76yZEjR77rqgAKrXWqrfle0+iq2U4tcTutCfpo9k2sc1DTbAPY9jVkqTkpCz5Yz5RlkeIK hbGUBras9zU7jNFTCx9Wc4cbx480hYP2lf4sXGQ+FBq4rPFg9ssv11bh4IM9pCQq58VCsHDcBzbB JxE2imIr5EUskzGGltdkDd0aohCvyPZm04ZsSbQ5Ng3VtxlTnHJs2E+kabPxaZaePyWaeuQ0WY+s nBd3cw5XdDmilFb93tLOi0vXbbZDvNA9dpltDjspVNKCmTDabL/NdNXGMazCGZstG5xVYDiJV8Cl EnY8zv5rzFZ6WnAPwW5qCRzmUrqf2Gzb7y7E5k5ffXHXVktLHF/OF05QJDX61iR1ZaGxIbOpLFN1 X/U1tlbxqTNmeIetPTCrOxv4vSK+m/3nE8NymqqbQrPZIespvn4lxWPWbmpwWJgi2YIVOZ4POBPx ONB/8GiIe/U9d2qh+NAjxxbEtVB97LUCKH4vOLga4rNN3PP0kTlOhj35lhNOPDOJ00SCuLgrIOuw jyKoYsN75RAk3awjc/YRKiCnJkrfgiig6/A5vlIeI7yRVg7DDjcLRLWFjNK0lH0okNmFYrvHnnAK RL/je61ye+CKMaQg7VgdA9vWKmzquGECGkJ8ZI6nQdzxpOp5meCRISYSBBYDcLoO+6gJbreUyjFI vFlH5vBZVAY0uMk6GsTYSz6sYdx9xliztArVhsdT2iK6yyqk2FAbDrhQcEbVxCrgS9iQDC2BeCs+ llYabDjbvrvGVWcfmaOTGu763PMBw7pio1F0PteBz0Bcqcg1ZwhyxQjCxdaZc/gsLmqj/CWKM/a2 DlfIIlmWVqFSG94cnQ9dq5BiqNoT3lQtjRcKbrw6RYaXMd70/OqYL3q82KFFPGNgBH0PdYYiRvyX wObQwR9OFMaE/2P1dvE4PdP70wmiRrTTZ/qL3oS3hL8HIr2JOngH6G86/U6/nXBX6bEwRnw24GmD Pxyw0a9y5J0Xo8XRjUSE1j3HinoOj4c4xrducrzt48GxoMM6l/q1OnLtxehRjgWpD4+HOKbF8dO/ +XO5ugplbmRzdHJlYW0KZW5kb2JqCjU3MyAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9S ZXNvdXJjZXM8PC9Gb250PDwvVFQxLjAgNTU0IDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA1NTUgMCBS L0dzMiA1NTYgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJv eFswLjAwMCAwLjAwMCA1OTUuMDAwIDg0Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3Ro IDE1NDA+PnN0cmVhbQp4Ae1YPY8cNwzt51eodAqPR99SayAwkM6+BVIEqQ6xXawD2C7y9/Mofki3 e7feNAEC5A4+S28oiqQeKc58de/dV3fgN/fsWgru2x/uV/en8/g93LdP49nhPrwjsb3mMX89RuHo O/65Euqewvb4xcW9009zdQwg/Rx2nnJ5r/1ooTkeZC+Pat5YRe+GuEcHQd4CmqHloO19nlgMoogE g1mxPa6zF8dDyvdheiP9wYUwtgi21xbYgEa22HhYZrP1yTp+dH5Zc1489Lan91PrWRxADEz3eUbK MI36Nq3VczBv4NsV9jKyLes+u7fgSHB//YgADgSwQ+Mo4hi/UKB0hqCahNdADgmbrRIs20CiEJ2X 2XZ2DzDIP2eQz2FPubsa2h6PRhYl3dFDzTI5u7Qx6VLSmCYNkndKtO5X2mF2RTtgMUxVRruxcp29 NF5p1915m7SDPUpxOWwwwSjU2bJnnyxSIP+kHfSTa8w3mky+8SPTZkRLSr6+Ycj5kBBJoQhZsUye Hz66Gyy6ODSqI8oYxHDhz4h+c0KVzo9sRo4JR8YjY0y/xZhQ4VHJ/zPmv8SYi0P7dxnje6drsNS6 t5JGidkP/CDJuELlSJVGMCnywFBwVI7rzlGk7lS99SDVVIarIxC6WwYYNsOsCFWpWJCLgaVEKbQb YnZRqRFdhikyrb9G5jpN+3H/qi6pClqtqlaMbKZPZLozMXXQkO0KQRi8hMGkqJZZuLikkVneSyCk lmXkv8kpBjk+BQTfMDsgdcgAKXYZxfQKuwu5XQGfUGrQWf3imxPHS3VQ/DJs8UvKIDVcJqfY6r9U yCEXRZ9hfLO+effdu0/fXQpp9x6tj0ekwHSQOmFJ6JsioDQjoFXZWw5Ecl1lyGf3cdzW0BtI71Uf mcKxpwS+JnhWK/nPQY5VSNmKpdSKaUoB48OMXQbaNbaycdQgIv1GmRml9z3UW0bpxQ9M8kDbgwjH mfHaRkDGMmPBrqWukNGRjvAvFyZ1nIIJAZHV3AAsl74c73ItW0pNTElwE7GUmlJGFYrX2iWoXRzE 0SsMCHJXLYO1q+gYTIgbhzhPdu0fVMowW6fI1KQIQn+jqbjgFJVpJcLG+dPqzJUkHSowzSk4Zq2F 5RQO6zoA25OuQwJlGOfUeMna0Wcc9gevVqHVHZStSDDfkOIoewKUHUMqn2VPHalRoY9EQsu8gqd0 8gmiGewziQiJrXpTQXPbg1YIgBjXhqOfGuLTPcYUTF2sUAkx01Q88YMO5uPi6fD5wzt4J8aLu8Sw wyfqvmLcU+t0SeJd8gp7cL7UPcNYCRXeKiYijvpS9tKQkhoJX7Ks0WD5kvZU+wyWL5FEZrQE0H3o 1mERIOLsooSjMffRgC2mqIiab0oU4FhwyKamgcLLGSGPN5vLCE3swQXYR5Qp8LHiwMFZQ/LeUixb IPLWXiBThkyAAl7Dcxw1Ls9aj7SIHCLCSiAxgE33oTUqEvcSE1g7lYSLfXhOa8yUAcE2Nd+UKMD+ cISmxeqlRYgasl56QAkzDikGXiFCuJlihGvYKuBjByJkCBETgQmoZSmCQ4XSp2e8UQdZM+Z0dQS/ hwAOiQiAQ0RMiQK8D60ZyFbgte8HIjSVoC7ClrkPz2mNmaIiaj4rgW0K6D6UdlOTejkjhKvDt5rW LCuCIWoPLkVkDHWjkW9z3MOGILi5FABpLzXjcoxt3PgJqctreP64JdxiCfRYRLyImBIFeB80VTCS teAiTzBRlWw4sYt9eE5rzBQVUfNNiQJjH5QyitC0WL3MyPFORTQm1NtGL/kZBecCAoNQqAJgFCp0 N1ymfN3wxYw6HPleFkc1YyFk+6hv+EY1hOg72/io9vbkPE/wH9U/2q3H7fTFvTmdUBah7fTR/eZe +Z8cvrYF9yrq4DVGv7vTL+7n02WRpTsFlQoX9w9tROr/QxuREvfbGG7bSImZkKw341hqE6F741ga UQ814K44ph/YiDJSKF1unTXlDwvdbSMoRCvusxHH//JZIyFxJIO3GQO8ybzIyid8HqJ32lvQLY0t 8kFb3Gd1nla//xseJnmeCmVuZHN0cmVhbQplbmRvYmoKNTc0IDAgb2JqCjw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA1NTQgMCBSPj4+Pi9UeXBlL1hPYmpl Y3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAwMCA1OTUuMDAwIDg0Mi4w MDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDQ2Mj4+c3RyZWFtCngBjVTBbtwgFLzzFXNM D6E8wNhcI1WRcktiqYeqJ6vbHnYrJZf+fgYMDysbqTHSrhnPe8w8HrzgES9wHFOesESP11/4jr8Q DofX3/Wbw9N9odl5qvPb+rbMNrmAKMnGmMx2QbSuPAmzzXxSwEfYefAmO2e3SML+kjJCizTLnmtW BBv8DsrAzgjOepclDiz4GiotqSSjiOracI19AjGHOMm7VFBDX9H7KoYCuyrfDA3tHWEu9dOxTyEb pNehx5kzRr1EdYm0SnQetSrvgGn1O2Z0J9WRIup7G/uo2BVrZFLOhj+4Y995/PtfU4FN1QWbVu/I ptLCKXYwJr3kB55ig2ekdUPJF1qhFDvjmRLr4bCJXa8/PBLivJ39guiCDV5wMQOJNvopkSJ2CT6R M1WOOJ6ZGrPPN+Rskw+RB6hR8lIYJrqWY5/rKoyoBALsMknxmEHeLVLn7LCDjk7p2luSIX03U3bn dPBbnT/d02I30EwjsLsksjjRUZhzmd3l52vsmTtdKL5QfGoEmQ2vmtO4aEohciOxjWpmmcp9RDl1 sPR3Ky3VCf+4Mve1pDXrBV/XlYKYbz3hB27kC3hNedxM/eWW0E+sD/i24vEN5dn7aAplbmRzdHJl YW0KZW5kb2JqCjU3NSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9G b250PDwvVFQxLjAgNTU0IDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA1NTUgMCBSL0dzMiA1NTYgMCBS Pj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAw MCA1OTUuMDAwIDg0Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDQ5OT4+c3RyZWFt CngBjVQ9T+QwEO39K17JFRjPOLbjFum00nVApCsQVcRCsYsEFPx9xo49jo6TIJF2nac34zefr7jB K5y8IQfME+PtEX/xApLX4e0JV4d3wtM7aIo2xoQ4k53miXCG52wDZ4XMaUCZbUiM07BT5BnHeqPD 7aG45+JeRNgUKn5ZT+U+Ch6Jgo05mfWMybryRCSb5RH3/8NOgxdsym7mCdshZPhmaebuqyNYwRtI yhL53ll2mcLAPFdTak55MoqorlUS0ViK/QAxOzvKm9SioftirmJ4qOImf2jviPjSeDr2I2QF9Tx0 OynsyBepLqIWY+eJVuXtMM1+x4xWUiNSRONeRx0V+8IanpSz4hnX0taMj2+7CtJVXbFpCS+drZlT bBcZ9ZzveIoNnqFW+uLPt0wpdsKdaKzDZ6P0vf7IyFEky2lGctsQnc1AvI0pRqE462eWUXBTHTQK udls31LFMFtKftpRUqGY5LqTUAG9p9h0RIY8yjzunLh/7qnf0mU7KY2i8rsTBbZ4SoVkBWjI9XR7 MCOGFje8dJgsgiBbQGYguCAdxukrdifVTtKOoVA4NgIlI9vsOHZZ2SbiupKklapnGe1KKjuwLrzr BbR9yF+5OVYLs5xxtSwiSPwtR9zjgn5BdhXjIvbDpUAPWP7g94KbT0EKEY0KZW5kc3RyZWFtCmVu ZG9iago1NzYgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8 L1RUMS4wIDU1NCAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9C Qm94WzAuMDAwIDAuMDAwIDU5NS4wMDAgODQyLjAwMF0vTWF0cml4WzEgMCAwIDEgMCAwXS9MZW5n dGggMTA5Mj4+c3RyZWFtCngB7VjLbtUwEN37K2ZJFzV+xE6yrYSQ2EGvxAKxuqJ0cYsEG36f48eM fV9pglih20oQn47HZ8bH40l+0kf6SQa/YQ40DY5+faPP9IMsfg39+p7/ZujT+2Smx5DH9/nJxqDN SGPwOni1f6FBG/xYR6Oe0w9dgA7NKuhxNtPgqTzEgXyZp6biyDJAe3IVE+hA3mhnZhsF8q7Mqw7h mRHFjPYCCUm2uQ50k+xcKWJ5Xs25zAP0mZCrgTTWgnSRMKYkNkYuzrOcAbE6UEuUFV7W1ixcsusw ybpgsn8ckRKE48ZOnGMrELWnZ3qA2Bz9fkVJBCVJXDXdUBInSTHURW85382MBOvtWAaw8yVLyjJ2 oEfws6v4ScQ8uSldpLZG6S1QjqDTB5+GTUoXFXeiZZKsWKHIwKVJsuNLSleiHd6elNhy+LtIBDu3 YqR52tMqpdOBlpTe/B1afREesn+s9AuqbkpXkguZt4CsV3qqmQtKp41KV8tKp81Kv9X0W02n60q/ 1fSL3Us70hcq4a2mSw3uqpWv3cutpnOPx93Lv6jp3hiN5trhunQhtKJupFF30qn3GDcwwGqrPtSH ELjndrVXh02VtsvNehtJ99LmoHVuHvFc+xOHgtKNrj5nKylLqT0hucZrCx7a9e+m45akjfq/9M+p AWlWhy7CXqadRT3xyEEn7pIyZEqw0jwYp4QtI63IctMBXxLhuRUjrTFZbDqOBdD6ayxSWwynUucs I5zDIsREg6tYtpBRb8H9ZeqqpcuAclM/nV8vdcR7o/yDl0o7GW3xwjkORg8mQH4NsTqYOcLPrN2M h3FwyQaN+lTn5DFkZsdRm9kMbAIgVhNxwkBZJ83JiBr9rJGX0DnxU+Yi69RxmsNU2ITpVyeqsed1 numpCzkHj3do8S1xo/QZOyA/Y8DxNGNE3hzCOsKwH49dhv7nnC1lKB/uMSIbLUMVy2o73YUVqup2 pKoKOvtrVdGZqqCzv1bV6Y7nfuupY8w6aBoyECo0dJShhomG1IZz16137dwhZXzMXjt35xkCcpQh ydiKc3eaIdSEdO6qhrooJUNxms4y1GGP5C0KN46jnVFtPApTBVBqkVs/4GuTHfQUUZgc7lWYeNTE NKMOcTtZp2NEWRIDW10WD8rjJu7WSDMYgPRcwFsHu7AzMtvWqMM0o5AArWrAtMUDAzmOkhimKsGF iOo+YUFn4WYIA85RiKjnPZarD27pgK9+SVwu1vJkx/S1EPnmb4U+V7FihDsq1zAbVDZK3xjzB8WH HdkywH+p7oFocrt7obe7HcohvO2e6Au9sXeEL42O3sz8cG/v1FfafaB3u9PqilsFHN28giNqxkaO ftjA0b3C0UwrOOLUbuSYZLg6j36ZY5zG1zmmc7ONY5zdBo7DEscQI6s0oLtNEr4qyyNFF9uV6ozo j/JRcKmFxiKLIlVFrffhjlikH/8A/uWg6gplbmRzdHJlYW0KZW5kb2JqCjU3NyAwIG9iago8PCAv RmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggNDEzNj4+c3RyZWFtCngB5ZzbstzEFYbv9RSyb9Cu 8h7mpDkkFymCgdopxwQylaQKcwGDbRwzBs8YEr+snyUt9fq/1VJrTnZylaKK0Za6V6/1r3O35Nfl V+Xrctz+t39e1nW5nE3LejwtJ+X+afmsuTMfpzf+uCnHo/E4jNhsy8m8nRl+2pmrYrMrP95sJqNx mL95VlaPf37z9HBTbv4ZxoXxn23KMH8S1ws/dT0bLZerWVh1WXbnFtWLdl6YMh4t6uR/gc/FdFQv JvW0XI5n5XQ8mtezSWB5GXmehMXHZTNsxrB5OVlpWF20oiF1h6VFzZxVj6Xym7Ka3JS349G0rG7D 1bfl5k9FlGnVArEq1wGcyTzwu5zUp6avRKe8CaIFej/fFJHw9o3dGdmvRkw1ZawLmOFRHFs4mzON /Z1R4wZUHvg6k+VoWVYbu/FpnFtUP4nId7r4VReHp7p6FfFodJyAELQyrkeradDTeGTAd/D2seMw YACyO+Pmo+Z3UlY7yfi9VoaFYDERw8BLvHiuC4GIBLrxSrgzWfj/ork82b5kqb3m/6hR9qio9gxK kG11DMfAp7WkHVE1NovqB5HXE9b7WU+2erRj4QOj9AwxGaOl/yU6ENy//IPuabqUcIg3ikqzWQhg 9URT9Tcj4UC0Dsx1CTSbR7ZyWXFHQ3Yw/n2mSyy3t2hC5hjCRXBJsyIQxq4gJ+nOoFi0+v/STBnj wbIa6ZpokkVI3GOxWrXuUaTxNQQkSIgTwXKAfUdVY0wXbYw95zGICpbu84md9CS8Ket5E0v6LgC7 6JM7Yq68ibRuJQkLM9T9UGMeSVdcPI53ioqVIJiZ0AGHxEVdyD5f4PrM1CkeMrKpZZopmQhJTAXf jMwxy2yShVtmBOv9LLM1udagmpy5eVZU95R0h4P0YrlIgnScVJ6dtJiH0N9N700uvevhR7BGG2Bz QIlvzDoIJ6DueooZVX8zEvPJiPHEF5Q2eATCeoLL25CBoKihYmX/NieH1D44qhQl6wGwwAoWAt/7 g9YyXIoqHy2CSABETocrDc6ARxTgfKe1ucMYmIhDkuDq9KPacl404s7s5bONXXze/haVBgxkbHEE dp6dRz3zuzPLEjUMyyqOMsnsrARMjJaAueiZpndvPcoQ5JKoYhmhOOKLdaiCBwqmHECXWbFVi+wx MoTcvRUAsIRsGFccktY6vyEvkATzCkmgzpMAQRatyLi0tCcv3RHH8EISlYqR+4XKAMzQybEiBokP MRq5TaSiyvONUzyaXZPczGLPxZrEyphHPj3RSEAD359EDCUm61iCQCjUwxgR/sa86M+fPFZawcO+ NR8Zua90e4QEdF8xxq8tbO0cI1aXeA+c8pkCaN40EHkWwRXdloEKMLmDbt/eFMvQfObGCVBAJ1aR R8jpwY9SBKrRiAPcMRkE3IT2rEmZnsaK4ETrsvrkobQj4l5epA6eJr+iQj9AwfoiIyngUA/6U4rq rcZCNuHc9J9y3la9gAL2IepZs5to/0yHJKYGODBa6AuPRqItbn/CEuMKScvFdCRgCY/bPCOAIiZx 6L8UPooqxfaMt0xju9DZjgk1V4RvyC4ErICmOAAGQETCH6RHTcLPgIWxkMEAU2mC9oe6EdHFFHUj 527/MrFFM4neCqUD6MECqXDVrlEW3nHCORYmdli6jyIjTfyiAplrjcn8S8bkZY/WxClZIo8LvjOA Pn6VElEVTEu8XK16gmJkWHoAMZhhaK+KSNoZACZAiNwZfR+LPWYAoVBJxLXBR/Q9lLYDF2dqsUna F9nuZ3A32EY3WMqWrCEZMz0yFlOBXl+cpKG8Qnv3WQHkVSEePH0DFKq8P4pZuwUl6R/Pt4LjtBW8 sH+s18OFbr9gx5MRBijgPOuPSvVHSeA/qhBMWKo6MjLxco2IVVZZnaqyNJZlKAcQRENE7msVBV9a HfVIN7hQDSfNYkNZdAwmab4BBxjIHhu0QUlc/A14xZ4HHtXtKMdTZyJUrBiFKsYtcrCz3bIUVqlZ cfBAF44MiMDKrDRcIVga0QoPvFbtVjYOAKYn1m2pJLkdfK12W+N0Iq9XvW3xIpyrnNr3Q9qMFa99 DETHKp+EcRzM1+my73oomD0lLT26JgkAuGBBowffexN/JzIb06QS0dPfWDAi0s7yCCKuNpFBagyD i6zWcRuHoJf0gH9I9khjaR7xKyp5htZmCktKqL7d6T6eiFNAQ0SPKCvJuX1lDcRBl9STwlBP19Oy m1cOvUQQn/qbkYhk+iuqwSLkjPMshqrgoroPdQBzyQBkj14xC+bh1kqFjXuImRMHlvWs2REZOrIs ukeW9SwcRKaHlvFs88yhZT1bDzbJnBTehqNCsRm2lbJjy3reKWSK9hg3hBsIDBxcWs44d3BZVGOl F6j1Di6TdTin1NEYN8aqVxO36G5K2MFlecnBZbs/KkQ4bann4ei4c3QZ4R/eiavDmflm1z+ZQcgn N7JyeSOJKDN7Mzl3HU3VyD3miS0qwrRS5NWYnVD7qbtLOQ2n8t0T+6BqdDLANwXJR00SCKexYitj E98hKLyQ9jWH/piAhzf2yREWICsiGvmdrIKcw4WGCP3bh+IEPUBWoc5zEHUGwBOIWAHRvL1CO1ne YPB5aSEiEe4/lpg8EhCUdaDZ6YiHO6Si+vtNeG+i2Qe7ZlpZfWFFQNpXWbUEYPeDYcqzToTE+WqR BcQQd/rvcMxXy6vD4Xw9GdgxxDFvQ0wRg0PBcL7uvAJilRfT/z9C4Xx9eSCcr5qwmYdCeZ7MGHdj 02zHrXQbpzXa7rZXW3jL5gkLeINWGH6n4JqNaVGCMYJFlMYjRB7huCMix32+OW6JbOE3ikFl5Ycq eCdRCHY6w80HwYOooDQqjlR9ugOjCxFMOjwEygWhNhLlAeUYVxoBpERStoS85qKcSNJ8u0uY0Ycn ICEwAxsXLxkUqn/ja9/UmEkgGEiV8+Wktez+fqpaiLDDRKOxQ0feUEt0OINp7eeV1mAVFT395xZk qWcWSlzEoKQqsgivlZDu32d75pJeBJh6p2vJhjGmpYW8ciahvcMogEKK9coGBFiU+SKNS2AxIhPe A0NAGQSc+V7F7a1I4QjEDNb3nbiuqSUvCWE0d73mV2snVM2oEOalWOjPZQ7SyZrcFmAScrkrbpkv bkCCwQ96h9vQbSQ7Y/p16CnSOtHyoDe7aty9HEQ01oF/TCPC4vbAnEwcAeiWhlnhT1mZdWDpHWbE aHyVCARkYgsuwJALKAtvbuSmnNelYYFuu/LoJrz/OlqU1d8wM0Vn6Jk/fmhwGEXzbRQe25ULt2Dn 82ViA/1JR15QmLctbN5g3J32oWSrDKPBh4T4cWPp+nCSwzRV1qS/IdUzgZB+udME95ilu/fijg5m xXiMh8TWZyuPR9gkk8VpbnjBPqINPTO2WFnJm31td0qRe0K4z5L/h9qXt4zYPc7Hha+KpHmixKWC T3R3h5nkmRM7kYjeh+FBFjLe76BkO6RiVQ9aFB24jaSMnYmy01A6DzQrigQOGnXaKQOOkAEVYQ57 9ERKoZUEh1jmRD9PXgo80cXNVk2WGNrY6r2LPwvbD52NrYvexp+tm32zPJZQCN3OQx4reIM229ia j4cLOAj0urlkO7sPEDvh7JSMs7qMR7Je1gl8xlduVZFTwi31JIkV3UzxqSpWzBENkxH9fCUYn2yO LZ/ZutkRvfSd/FnouXPM+/GbAIrPuwPIN+BTNwZyOQHCpBs4RcOb5RYixwNf2i2cF6WATdOci6H9 bDnYwVR1ddqcLd1m+0kzfAlTDDQas8UMyG1K2JO7F0xjWk+nUaG9V8BN9qJVdrr/ZxMn6/BRy2pw 6sZSMSq0sJu8NU3yAWI/v/LCj0AnzIRwqBIVJ4mPqIGUx3TGcMH6JAJsSbMywc+9kTyrfV9oAOTT cLO82WtR9Q03eYXAa3NCMJkNGLij1yDBhXDNosIXfI7qoKhGXmh14wjqhoqXDVIcK4ZHpkE9ykUR VxSwzJaO9CVLbqVnlTVbD3pEET3itLJQDRgjsrfFWNbB1SWJ9Ms0RwrLFC5xbNIre9ImPNP+oIPu 7NJf2ctwZ8HrXPFBawbsV13vLVPPAlYSpCHptAKEH+JiGUJL8jv22AyPEJhHeAaKlfMAtZZGdSKH UcDLXmPNgJPs3880zIEVkeUJ9O0iqTnh1qXNvWkoMMROI7y1er36ki8R02B3kf8AM8IJKVD1jRgQ 0ZhoedrNKP0IN9ORMMTmPY9DVWNE/ZhJab2kkSQuQQyLEjWjfgTe44dos/Bpo2qkFF5L2IPewbGq v/wgM3u3xURAGKaN14THSOlcCJ2uwzmuHfQZj2enLNd0IwNiOQv+spsg9Wea2LYQt9fUIcgupVvs SxzzujIEglzsCPsyAQlAge9tH+aPdnptWMKYWMaxtWQGzFklLJanlDBoW/HL6xCg3bYIQwQmJCXw IRfGRqaSPL6vTUEt5JjNCsQwCQ+oj9TmWI8Uas3r4wQLwm7ksqj8JIlHlFM5d+g1qQZi23TV/tg0 fP/ec7AkRUbzP1q/AxVa4cJPK4zRpDAHAoUO6YkyAeh9LxSlcpLPIKaJjujCDYcC3DGIBzo1//KB BTyyveOL2swYrveR+XD8vSi9Pan+0m6+hvNv//pF8t9Z+fxQ9W/fTP/qopHQ/FsO+cZbrRCnU4dR no9sHf0+udFV4ORI4W7KHzKHy3Odv9mu2kmi4xbYpi6u18/sf9NreW2NVzv28C8loCmDtt0qSnvl s6F4knUhTDmy/z0d9+vm5sXNe6db+dhqZSjbxBMpVNbqKrSujUQFKNJl5Uc4mrUjqhw8aBAriB4a 7gS8Dc2fkWTioyRVKsRoDoHFy7+9H4KjRDbPb9+jHp6EFxqGYvVFAQMMXymLETZvJQwfVDCGHUTQ RVDG8Ig7hrYHDN/au4TgKO/+464wdTN4ek8rRfhSDGrqpdiFRKdyNWbWimd0/7kXdiEn4Z98SVRg B4p4xmkfycoqKgv2H8UoUBKed/nsPKtFRTruqBgdhRE6f4mQgJJDyeL94OqOhT8xFvvCR1nTxuSv w1wP/zJpB+hFLoQ/2TIl8Jo1J9+agweSKRJjRU+S76lfy5tMUUlBQQeaKZU1RJqwgHftw8FhNHp4 BWHfH/bYJUqQ3h8+djdqXj+5Huw6SxxtML8o3Lg1wT+GQVX7exNRADHUpcCIQCa3aavJhl60BjNX PnqFNHewamHPooqQ4pTvjP9hd46jeyTHTuYnc+xgJMHiAQr5LrSJB9hENC6Plt6UejEio0JhIIWC CPVApUnAC4/ZE+ZAd2QWMTI++79+TAsHkO8fxb6Hxc8+IMEiTN9WcG5LX8nuTp/lZA8VsbyKAKXM TnOfuDLON7nA08aHxfnmY9Xuvvtx5ziWZqdJmsXq76kAHXQO3z7ANLKO2t/ZwTq3zWdCLYPdfw+t eQdk3PzjbDNPOb5j9LUkZC1cEjvoFY/JN7xMMo0mScP9WN7CYJSsIERFgH9+Ye4DD1wwmXf0oIul McYehVcDHZqv/gNmB1HHCmVuZHN0cmVhbQplbmRvYmoKNTc4IDAgb2JqCjw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlL0xlbmd0aCA0OTg1Pj5zdHJlYW0KeAHlnFtz5EYVx9/1KRS/IBfrYTQjzYx5CQsJ xNSy5GIoqrJ5IE52E7zOZSYsMR82fBVa6vP/nZZaGo9DeEqlKtaqT58+90t3a74tPyi/LZf9f/tX ZduW2/WqbJersi73n5cvuzfNMn3x2+tyuVguA8T1TVk3/czwp5+5K67vyl9dX9eLZZh//bKsnn/9 3eeH8/L6HwEuwL97XQ7nx5XrsEJbL9p2swnrb0uwFBHLl18OUCwXmzYQof8FujerRbup21W5Xa7L 1XLRtOs6sLCNPNSBmGXRga0Ba8p6J7A2giGFQGKgqPsv/Nm0zNmNCfu4rNbn5cVysSqri/q8/KS8 /qPxuOvn78rLIKy6CaRu69anR+mE6fV5EafvhKc8D6wFfF/rxc139mZhfwWxEsQyPhQBmxHDkGAZ gd5fGzZeGJayenJe9BSEufV2sS2rawP9ndC/1sPf9fBPPRw+19NXUR5F0HkihKCVZbvYrYKelgsT /EDeDrvsADCFsi6CQQWRPT2IKUQUlopSZPEM5OVAeEUloX4xOzXnLZtjBBTVPqdpuGBZfaiFfj+W 5kYjGMOUTqJViK+MlOAhUQRGSVGN35TVt4JBW8AIXybAw5ey0LtvNB3134scFIBKhFAQ8d9BUqzN UmbXvfP0waPz1y54vNV7fYwZ7pAYyGa3W7REnFMnbTdDq+pWClZ1ZUY/Vts9HEG4WMJ0sJQ3xlNR Ccbd4Yb5ezj/TBIVOJJFMV9J/LeHJwMTLo+YMOoQ3oMtHuTP4mN0JxmoGdlaVBE0tNINwsiIQAAu lDhrwhvBIjsyI5FgZ4ylCzbT0WSzaRK9n2osbcgrWJjltC4EfSrFOSuwK4olEQcJJmDR3rVwkgmY 1McmUJwWVNCZPWQ6C9ZhdL0SXzxgLgfxRahDR/BgD0nsQSogDGIZZpVn5yHnLzZl9Vcw3+B0mL9W Z9HEQ4yv/E26aEhpRcVsbFF4cWYYhnSBgD/YuMkrG0oIN6pkBi8q1gwx1QZtjaIaUXpSuiBvkO1X okuLXuhBhOZsBoikbJkKs03IwxNOgCwpUGCQIeKZ6Dh8IxKR843GFHqR4V4jIP7/S+6XjwuD0y6V OAA2TciA8bEVlLkVfJZJSymmrJAt8iJBswSeGSVZVFBB6v7YssodSsPwQSPr+YQMFCvEJKd5RGO6 ZkHovea/OF9ETJ3lFY/K+auQ8ykKx2G8mIn99XTO/wjJPYGxWGZ9Z9UA7oKu0Gf+BsZBGyXg1QAi lmGjH8cmqfEGtK9kDLgDMIec0GTaKBJFPysq1AtZWpsFXKuieMpJozH86Zmi2rsXbw4XRKe89SAB jcVOXIV4BKT1RSIMQyuascmFt1CaJCQwrBdveIOxIlt8UMB3I/2WXmo7Hi0JGptUVPAmfFMijWaY iHThDhM77Np647dUJHtD3D+lXXG7C3XMTF9c7l8V9MXtLnTIj+6M2902ccplJCyUSbQxFyFDJUkm 643by7Q48zqLhujn0R23l2EP5OT+uN2FLRXfbrHu+GoUyTDsO5kbb2bzduG5BXcgX2C+mRdoATUb ZddsWKGksX8pRuC/kCOPEaj+DSSdKJ5+l4cwyDvkHpO2lfOdQrvxfZ5xgplpLsLG1USB9Fy8vqeH d/Twfl8Eh5pXzHr2vUVmsKkAAbdIUdMR4sGFr37du6txLCo9FrGWYxJu6eHrn1KXMKlVCOMokNAP 23u3Rlgx8IkKGuAxbFndalVgYPseyqg+IQSLh6KsJwckSq2osF7mgFeCBQQikIHo9A6NGo8HltwL oWZR7O2BsSWKCqa8YafDC/OTaD3RErRN46GHcK/l9zkfhzuUcPAaHqpQopwWvwikDLtFhIU8xe0z OZe1Q152uXMRxWAfGoTmDDFgki/Pi0iEHPFMwC/cg6CHVg7UEozJIGlDNcJkIUZcmEIGug9k9fu0 iPsmQxPaLSv+GOIBEZgRu7wgHFM98MpDrkj1iHNjynFMIhqt5XwhrkFTMFPjTNf3bTiyUCY8NWKv lhMR+ynxgAcYz2JuKomRIpjtcpO0JBHwagDPPNxqa15DLI0YUSLmIdh0v3KUew8YCm5wBqW5Ym7P nlBLRP5yOsAotkQGBH4PiJUbSXEBGSxOGnLhMh9Wtdbb44R0ZfQCKWqeywve08M7eugycegpL4tw 7DHcYocorSds+gsAVCu0FZWSb9Kmw+1ZzhJjWgtRp1n3gaC89LrFS2iINKF4NYCKQiCJnEOXB5Is wQHzqaSPCYFQAhIzma37/t7dnUXZpC+CZE9NwpQtgZyYlLXuooa5sKB45WUYlMYFJ9P32WJkKFgX RqUl8VcaW0wFIgTrGzt7rIEQDXdBVV0qKirpDK68VTdN+wGBliChAUFv62hIf1CYQFsygRyGLIp7 5EeSIlREYC45kttFlOyRXaEjTW6zbSZb3GIZWlw/+m22j29wm+0lCWaqvQ2NbuKbWXvb7DY+/ed6 9Nvs1ie3ts22a4SV0kMws+b2uaI2njYO2qF8NxvF09gDt9lFNZ8FusPvYRbAwjFoxaLSyq88xyum lZVHGDPtrrCVqQxtub+foGsMzbrbUZm+yDC05nW3Hzq8ylC87O8e9GY/KJi4ytA03X5QIl87BPUN myaSaV1ybtHN5SSC5CRitOlIHmPXIZFIX8YydykVsnPIUAwiRcULYFUz8YL9x0Sjw1bCrjMkBQkh j0jph3fBEKQ4TqCbpttYTi80FP2lmYHUHXo9JfOPMCxFyCz3ECmxabc5KMVQSRpAv1aqBlHYZBjp B9ZFhZsuQ7ZEkqpBQ1S/4BWJhFW9D5MPsaWDEGBDdHwjSr2J1WwmqZ5IVKnpwIzzkIuQvjnpPmPB e2XBAElq5SSxmxw1onU9HSN95ChYRIXKNFsQUO8DkTIIAIcg3r02or/XG0DGGgllakYTymJpNHJ4 W6owzL0/xNOb8Wb0jAes1kSdExu1pg7B33c5ua0xjNIubW8c7tj+QAChn43iy5mTsFwi8M10aeU3 vRzq5JQvAxlbm6ait5HgvXDKIMHtTIrYHFuw1Mhhzjx4YExo3BVcenGsqORayV6hKMwRamTKiEbN KPxnvoVuRB41vrE7sX8iUBGAYKBREFk4KSpeAcy+B4wgMykWKvduMWo9mAUQ0wMZyiLTLrK+nCo1 oez7+bCcHB8DLq6Js0g750OwTPbDLKI7zRrqk8ThGVbZ2BHifKNocNewLwJQHAtAsVYChCUNJDnd hgceIEvUuDf9ByBqEzaBicyKfUnMS48Tulufw3quL9NUz63DBdCkmotVQhcBh73JOtx/HdZy4Qbu A9dS19upnSyv5NqBxWWV3HqbXLel0Kby+vEHb0VFKQY2yjYpgRHoVR3Hi6WKl4fquGSrBeOhOlId 19cu8kAqs3VoHdMqLt4HnnHQ7q5xyGLx2oJvtPzZ0i6BV0uGY7A3mCpmmHhHDNjQjLN5WE5Y770k cwWb7Js7EjD2CwXB8Yeb2Vi/e0R260ronqkCQJO/6Niuy+rgZjb0g0Ffs+6vbySekFzQHvQ161XX YAx94eG+Zr3ujq/zcgFj6m4ldNqf62vW3V2nCQTY6YQ/WGIjdizMECQzRPWgPyQXuKF4wh+s4kyM 4qfua9Z9+5l6xLG+Zr2a2t6Y9YdwB/W4P8TS7jR/iL4z5w/5FthRf4jIJv1hpsqf84eiytKWexec iWxZCtGKKEHe9q1QinjNAh2zYFIgFpOC5KlImAXwkSWASaLI6EjsFKm9VvS4l1VHAj1s/eijQ23h BhbhTOKFtHQzWzlgJsjXzUTX4SoUal8M4R8mjjqTq0gOl/hvH9QXFjcm/orYLrIGI5368GUVboOc EFdXu1B1+Icv0a0fqDBWu6mQGOqK4YcvczF1demnc54uf2YRdbW7HFQYx+Lpaju4TsWG8Uc479B0 HtMP4cDEJ7ofw550tdiqzH24blmlh41mDQo55oXpBwcaop+DGOGntBdocgFOjW3m3oLNkOD3gvAD 0NDnjvrRsRiSS32ZGIQPHhHmcznFe3p4Rw/vD2Negl+tWMah1iH8wpEnUD+qE7QJMbEKyEN2sKRJ VxZ83u+rw+RiEjxCBA8eDg9pZO2DWaZaLRSyjEk+pUEBbjoar7qN64mqjLvk8MVWHuvf8ISGgZbF mFh9D4Y5KY09X8cUbCfJZbWwPRjx/HsTLv7L/sLAvmPdI6JwR2GhOvDGQkN/kZG5tUGM++xMrQSz mAkOCsGs/TqulNwfEg30PRipRsQR3j2CCMUSKvENqEUUWm8Zj7khvmpDD0DyPnGXcdWMDpxsn/Ha NDlHelk5wQfnguYu45QXP3ojx+IsLZqk/IBlbrsvbATrFrTXsfNExYr2NQ3iqUHRG9pnt9vNCuG5 KUZTV+BjIfzC8LpHeuGKKcqsoGo8O9my5JxbrLCk+A9dusZACHe+6RZhjuVIZh+7VuGSmHFKsIio ozd1DnYhzQtp+AvzHwiufac97pmnznjQKOaNZlE/6+7Tw5Rhf8qsjEkvnQm8LKpD1XBoIZkQ0d06 eAVuUgK3KmQ4XygToWeNaAEWJzSCduwCyeajxcgkw/vnGcwni2otRBjojEbxGI/OKTV8iamyJMCe wdm9YAxNogoyNwyK9olDAmbB8XiJovIqRoK/778FDJ+cu4PEUIF0MvePNLjlY11wgvLyN6DtjMP8 ZOYjolUw4qkiBKnCqG6BdRvyE7VOX0dwKQHbQ2AglHRjmEx6SCKVAihCwdiRAlQxiarpJK9BZiBC nC8qv5Y8jpClf2oJPCeTfxtr1xbxW01iHaGwOg+IKX/z4lwu5HsaYBJqVM98jYDZXGAqFgoWLJ0B DcPcM/+udWG1TBF+HuJRtUz4qQS3uUEtM//9Qn05vQn6lLCNzSF3pDPWzB1Rk8hKYMA0mK0DMEkH CGwAULDI9TVHVVRR3TOdWbAg6DNNx+BBjFPIGDwKI4DXKpyFRniZ7KUSOZbZkMWaQgM1GFfiflbB Bfez6KBZoPF4CoFjxWB4RqkHQLFwZV2H/v1wVV/qqwCvu5LyCEtQJk6vN2kR6DXdFVV+1URRC3aR DQqXRIQ2/jsJgRpADAg6jBwveOpdqPVpEHxH6gbawYWmky9PtLKu1iffUYKABzARUzQd5rG0WefB zDQXTWJmCE5x2DUIMMygSEk5R4O/sgHNG6iBA6EReWeMIAdjf4IqKAcvMhO+HASP9rN3luIBPJgX xgKBsiuxkE8+6LrvoxvRehOOsLCzQfC23wia+LKmbqerjKwRRSgo5nRXjeUlvIIKFdyCNB+TVsyu kvpSQsScBJoNoBpBGC3JntUN32ihLMUNTcKgodtHLLKStHjIufYaAfuAa+jijXjBicaNgJ85waXv EdC1C40oBn/GiyCRKqBBSVGTBBdE5R/mp2tb4hHGJ4MEUVREinwphRXfQkipGB3YwaSYQ1EI2I+2 0UcSByM+E18fMx6I6E1aJnlE90RlSvL4QyEBH+4+mQpywdAKSZYZqxgcD5gD4tCvRnnuRoHCh8SY rRGw6AU8el0PJ7ArYBZytj3HGerkZpSmIQnEJgFgMxmojSS+rTkChRgNgAyuieEmzvQoU7NAM1E+ EdByXwm7tTIvP1rrn9JP6Ou62yE84YStrrv7IY89Y6tnfqKCW8z9z8t1/UP8haPsHk+9mq76587Z klqKxnwxCAjlxC1rsHGpQTGIkf/t5oLFbaICVk548II8WLcUx02eOmjo9BvZ9TK5bMc525WJAZuR gbFhhPUDgqdhhJokI/eQp5Dsbo+9gxh8mecKL3PwVo2wIiAQhRQRMP6gWXzXhe9phEiGUvz4Wzx5 9tsbL0X1bzBli4EJfjMQ1/e4QIYZCBOl0uDT5+rvnp6XbdP9lqFAwtaX2RoSRvikdPFQ+m+lZJeg wy/HdfnKU4sTDN9aVBpCMfCvkQgZet9cZULCHAj3bTxW9Nz+0AazTw4LyJ+mz+Eut5SznmRdahmB euFLQLL3FeJ8z97fYhSGpE1sRHg1Fb9ENBoRpNd4rh0XUaw3xnok1+WqmPceZzUkITOwO3cOWMjM XBSzmEi3KUm8Fqgg1IkmVuqnniqaqVflRdggNuOiATNjXlC6TwgTqP2CL0YhWkFExAQEBrWq5uQU CsLbvjGWzsGjxRMUMAo2R4UGWUtIGnAKTIWQHyCO+8jkXRnTdqJDl+eEcWj5sYVSDPJ7fYIU4b71 fOwDZARr0gs78SmD/Qa1MAOLsCbMBFkTVN0Af7hB5aAI8o57pXOCN0gPqhk5GcFXFjVmY356FSWJ Q9YUecwnDo3FjyHR4GRezAvI+wGX55WUFXma+sZYELl1Sw4gS04ZzVbzGyHYDbOEhhjHiD0ke94i ZnhX4bgXbP07H/9eNpGfCR1xaQ3RhdVBl6zOTeKkaHPs2n4RfpV6/vdCw0/Q2mdHJ27dNJcT2VFW iRWIU3xhjuVgroJFS0zaI7ns5o1W9MlmF0ymbppPY6jqDbPMFidufuR78Ngtrg+94AsRUPkRJSMl CUVMMB3Qw40norxkZV0hykUo1DKssJttggmShwHNf1yOOyNLdIeJ6tWadbtYdr9Lvnbb8jrqQ5Wq sEhUNZkFukSOiCeOMQkR8saLdM0mSiNW4SNSwO8fLKyiNx5scvIjtCyJ+bAAQ3tEU37wX1XJEnsK ZW5kc3RyZWFtCmVuZG9iago1NzkgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3Ro IDQzMTY+PnN0cmVhbQp4AeWcS5MjxRHH7/0pmrm4J4KR1VJ3S2MfiPUDxxAYB6xsDoYDDLuwXgaM tID3y+5ncXZ3/X9ZXdV6zNq+mCCC0VZl5TuzsrJK+qH8uPyhXA7/7b8u27bcrFdlu1yVdbl/Vj7v R5plPPC7XblcLJcGsbsv62ZYaX+Gldti91D+ererF0tbv3teVh99/+rZ4brc/cPgDP6Pu3K6fqRc G4XmdrFe9+Q3JUiKEcmLFy8mKJaLrjUm9D/ju1st2q5uV+VmuS5Xy0XTrmsTYTPKUJd1sSx7sDVg TVlvBdaOYGjBWDSO+v/sT9eyZpty9vey6q7Lm+ViVVY3q+vy83L3QZBxO6zflremrLoxVjd168tH 7djy+roYl2+Fp7w20Qzf9xq4fxVGFuGvIIzguHY5figMWxhhSrDMrAXym4CNgYClrN69LgYObG29 WWzKahdAf6+13+rDF/rwoz4cnunTd6M+CrN5pASzyrJdbFdmp+UiKH6ib4dd9gD4gtnQHMpU9hTN SDjzjlERB41IZd9oJgUpqsM/NQfH90C9uU8xZUQx2FImROkyFEpvRUozjQbeTWz6vZDtxQA8IRwj klKgXwtrkKiozAajZpBxj8kw4nsBaPDeIXotYIbofWcIuyFoC48ILNRtt5GFZhZFYeSLNt2iTfOE mfUJ3MMhgiJGqq5XwVWP2rmsQIL+MCVo0Zc0+aX0xupU1/o3lOF6nCkq4fpZuKBLsGCCrwSjRTDw TA6RMltWb8SDFj0PzrSH0oOmAptFBZs/IRqYsYBWAawBYsZIhMTFkLuYoFkODB+QPHBRVPdAIzsc ptBlJdFfi9ZBI1+IMQ3A1wOfkFgwiyQMlWPcitItXOYBClbxJOwoH4HwxbtA+OYP8oDUxbEl6HEJ oxPtOHMB2jVRgIY92WLtHqQ/SluoOHNFvAL1SS7JGXRSVLg6WsI+TKEDYSGChC4LaggLAhwPONQe oMOBaZwU3QlDRhyONSNIkIktTSARS7GqnAU14yxXQZtFBb/wxshMjhbRD+UmbDaHq2i/HvZt4oc8 k8qkf6N6hDQRxs3f93HYekA+rUc+sQeeIFRR4U5MeaALDRSEBryC+EZuCuge9YPYWT6zo/UliZeP w6e4huzWfeExV0VaTRdXkd26NsCojiyGkvlMHdmtraKM65p+q7Wg9ErSSrLPi+OVZNdYtTuDgHKD 0mTUZ/EWtWRfmea15OgazFA6nqolx2rWOElrybB/kHgII9zWDWrupEznhcT6ttd+VE2O6p+vJrtV VL1Tft+F9Jt5du5w8k34xRUJYDKlu+2gQ99FcGxlCGFNVpS+T2tGtvTcDd1o7ws2Y0qrFRFUJe+H OIcjUhR2QFI+iFs3zH0wVlHtiUPRJPcfsGgGgxIPEYejm30abEOSAhbpxA8DSCMelM72sAAsH2CK EQwpAgFvUf0EE+iLaFtmEbMIIhAxrUAWQf2NBkx8efiJ1NTeNjOJyY7J08TU3k7S0kXH2/b21nJK EZ/eJ0nJOBWDFmHZ8bZbdklKKmw5gqOkRKNWi8hUUpYg2OE4YIGNKcEyczYlFXa8PZqSQvTg74QC 3uOe/911IX14SrJTbZyQRsXPJ6T2tt88ON6OrQ5TWeb2hBF+OpOtAueB4YL6OIoqa7Esbu2cdd1/ sFO9dEe5AH5ZZISIto80axEM7PIoKt/lX2gPJ0iJN7GSh7qXdZHZrMopKio/rAU3mM2tJeeK/gbr WbJRIymrBNp2Yza6oBJo2/4k/NhKoO3bVu4C7EobJYUb8+tTlUDb9VsgPgQCwiEJu8iUl4RdcCqw RWGXVAKksawSQJbIfv/tSqDtrKUwCbxTlUBrrcpcZbt0twnRYI0ieaf7Ig6G3wOENxJNL4NfehXA cmG+egCamGDk5i6w9uQj+cWT62Iaw+7o2JX1ebjZiYEUOMQSkfNAMmAIEfmQT0kOQhwplEpgQqCa yENeEKaTUCJCmQ9oGV60CkLTXOUZ8ThBsIND1U1Zxb2DwJUkCCllSCfHumdzjbC2WdMGu7B3Zl3t Gdcd/cPdyzs7/gnZ0Bzbiru1SsuieojlDWkAFFPviTpsWF3G0JH5uM7nfDvZn+Tb1iKSyk/4dsqc lmDTkbfoYIoLvYF/hiTIT4Qs+mOnox1zSGk/5Agf4IM5hLk3BGNeFVmoAowRBMIAPB/uVYpHm6TU ALGcj4z9iHoaiKKOEmQkLytEMbX94KeqnI6URnVfik4ukqwwyrRpbppLgYD3pGSG0KLYdx6DgChR EKgXSvM5IcTIiLCoFpMEOxbOj8oNS78Fq8Mt2DvejJ9LJ43V/LnSdtNtLer/SnZJ+rM2F8z++tpu 4/pKMfXrAFpUqW1Lv3AQ2ruZzSsJcDq2UeeOE1hmMwbwvXjTCnbcZ84scXOWPf+J5+Aw0dZP1OMg B9zLL5LQ3D1gI8qi0m6EG3F8VNKNdCdgJLyko3ncy2EGZ0ZAaSVfjAGCK5/Y3vqyOaqi41Za09WX lM9NZ9eCfh17URut6dIDZ99Eo+AdSme7ju17fXPn1WazngkXKlw+yCdoJbMJJTFesYQ+wFzh3Bde xQysCmcW0w6Moi8tnIesU1R4Jw7onoPxLW6UdTmvNpv+ituvY0+Vzc1wxDmbYSgHoujBu4gZRohm D4PZCA1xDbgcNzLCVDk5FlnStqqADVPCDuEJIa0CBBmCZqNLVjEFrAYwENYgFIX/ykqMwBbQWJFl fbM/Lt3L6jVzIjZivKTgdZ0jrpCA1doc4w2yZsQwQqIQQcyqvrdOwUuCD4etpSurvwmdch4W2D/g zULsxh7LpKcoiGzFBwSgOSpK9/AXCEQWZDnSoRmmhEdcwbH1GhVh83VN0/Tn1DyErnbBqLFaRhHf DzMQmVHLlUf2iV5GU/fNhqiXMQZ7f/KYNg+b2l7JxOn4ovZhYwaeu9b3hGz5MVJP1kBsVpO7Svph JFEwyQDohDh2BxmDJKTkoiKrgo1sLWzMNCqElJLpKW4UC1EQTrPOY17IDG4njXhKXg13SlFSPtVE bOzSN2/afiIJCAJFFwNe9ODgKlr8IDnj4aNe784XdSJQVAQOMUVI7s+VmGVcYoZEJMzsNFHlJGOK c0IdwXVQGaScGs+jj5RGCnKiIkEGZzuZOT8CZJ4pU5+I0fWmuyRC15vNo+NzvbX3U9mZipi66e8c T7xeW28n12fhKRYxAx5p5/8yNtfbaZfxVGSu7ejU5/r0QuVJ2n7/QcHKZua+KjcOkRO1b4laJSkp 3oNMIw8g/lak1JcB+EQz3dCcCZPo3QcIxTkBKG6yCaQdIaxsJOi8CZWufg3DyfLS7wWIy713V0Vd f1lNoIoSDhwOalGRwJSwxJcswwuMv4T8uJexow1jqP/dJuRCERZSNIc6NCPI0KuNnpJoxo+kCBi9 bWQsE/r50Uth1sCNl1FGddZDiqG6i7LKzAuldTe5BeMGQ7LK0JGQ0vaA+DFNlbU9MfaQvLDlul73 V0B55rwbTOx7Je0TvCMPu0zffjH+tUoLdks0/mgPcaakRXwJpPKUnByZJcDazT42J4FouV+rM5WR iK4Uwg6u1RAnbfj1OmwIOJXB+ILUNLyiwkB1j5BASJoZJ4qZV6JXJ2I0Eik0/kTAIi8ICXMXRt5Y WeE9pB3wYIXzkRedqySoBVLKWHaWFGyq6qzAmjlcotm+djoT86vJAygq/QN00cIFMRTZInEvv4LG OfmAVrOYDLSLCtpSi2x8c6NPmARvBZ275HiQExJkhAMhYynS563maBcSQi3/81+1uz/dKSFrDuPA p97FCAtsIZJmhMO1qRJavf54y+ZWScvPI75CE3RA3tbDQzAGhJ4HUS2kTtXqkjjSqAommzrj28Ph Od8u4h05uKnnBWUplIe9NCOWmBjV6xIywdElr5BO1kGBKTQlirIjTqmJ3LBK3s6V3894rrb1s9WC 5Sx4h5gKEhEVNzlxzaSQKiBKe3Cb5Ad0FkXFmIUJAmFLd6r4IVi22svWg9eyYMAFr0bkRUU6QWwu Bw4MOVJJig4iOYKEEFuMhejjS6WllWWcFy8slVbb+dco/9FTQxQwhoL7VqYGFCujRTtDSAyk/4B1 OLnYS4o2v+Nyh1UMgt+nML31ToLq8WHxhwBi6+5c88TyKbRobWFk8EHct5rRe5Hb8sm4+VCc4tik GtBJTLH56OvWlA34g4RUIraAYKuNr/KCzfY3b3f5jqhuLonmI+nhOyoEHYicuPDsf6KJs2r78uaC RuuqHZ4t+b3XRY3WVWev0wlN/04HLZibxtmcu/ladZMTDeXXL6yZsxq+GxPffp1q56za/rowbeYo lLOgz3MzIPKr6HGGhsoo8IkNBQ0pAXeUO/NOijWa0VrYAYkgfIPSBjNk2GM7tJZ95u/TIZrxxRt6 EgB56LPrNFsAw94Xp7E+sUVtJmL7fBojb8Ln/bfK1aQdWM+h2Uoluh8Lw27ihyFWU3sFkL748IPi MeWai4zpGl2kOTmzJ4rQjLhUwRqXP4GDy16ar+wNziU5bGUZ6LEZbNWczF/tmfw1fQT3y2xFr+zr LBfnrnq8dkyzFwn/s2u5DY4bpSSixC9kv1QE4d9HL3LwZeLP14xU57ral4SLeIbC//Sw4MKTc2Dy XwR+1qsLM9G5XWwTuhpQArZdwLMy6Qdi7wXdP7qmXy0nF6xDq7X/jgY3oe4G7BfolswtbmFfnuKV OVNYmg9arXSVE/LXGYLNk7OlxTGHKj+iHDFDx8qTs9C9xFh4JBTYpJFbFJSa88WCYMnMDT2rAtCM OyACXPnrDPgDiJHjfEneTNUw00sb70VF9SHPMi7bJOrN/DclraacvimoN8Ot9iM3inpjlfTJrcIe SUX9mOxNQb2dfMHil1rq1pv0m5KnSt266696081iF06tROzEjYZbr3wkZAJPDTg30XJDhmNocbxp UdgPyYwP+mbukurWXwRe2LKom7lS5NOjspLIiESFWRA+zzczGweVbYblZJvwgh8lyYI9UHALIAHW wiYvb5gkhfvzsnCXOfn+3GD21xiOSkFKATWC8uErlRCCzViHQbJyrJ1QzKqJWlRvItReaw8cznXR 2NBwaFTlm8hvgyOIR9QCSzAp9gWKP2Qvke8SpJ7n0R92IM/zDO9X/erafwAjoWfP5KnhwIJmVGJE +0/Ed5RJo1944oeQeKJU2y9E0eEec2r14pVFrQXnzH1s9MNPc0FrBwghu/Cle72cvEUJX59/grgy 96NcFa259f3bMzz+xUIHqFEO0sbFtTLnCL7m0ejE5nw7ss3gx/o3AafdP+oXwqG+BOKuknPq6+hf ykVK/+UGudgM+bHhiC5wegL/Zbo4DTddIkUPN/zna3SKRWCPFWiKgG4fymqPoOIYvthsYEMg4MsW Q1yUQqctelVICW1BMFiKo1Wrc79mGg28O0kD1vPN6Ig1eMWf+vQTRetMWN12M3VTbO6QIi/4TQ8O e6QRKYJ0iLk1A6fMjMJEzzj2TIEGGwiNmxtgKcUeJaRXVhC9pGk+84okpLJ3Tn/PZtt4vhqfq1Rn VmxWM7Z4P5gfppEwVwd6eX1dzH8j58QePJPY9OzEvkAFMWoSJyYr5PkMGD4oE+HEiAMIgQU+iAMs LxHpHF3mhIDoIKa1wkX4sNTjQLAoCRjakJ4Q+2N5esEGfHRgiprujf3Wy7L/KcJpz2rYsorqE+UC sMAHUu3l8GKVFMYiagNG/MWOVjNFRSF8GD7Yp6j+FFwTHvjA4pxzbAkMW4pVjkpWH/8bB8bGCwpl bmRzdHJlYW0KZW5kb2JqCjU4MCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGgg Mzk0MD4+c3RyZWFtCngB5ZzbrtvGFYbv+RSsr7gBWyFFUof2okgbI3WbJk28E6Coc5HuOIciO2mk nPyyeZYucub/1ohDSdzOTQEjQCxr1qxZ59OM/H35Yfl9WY//Hb4s+77ctuuyr9dlUx5ell8M33R1 +sWfbst6VdcGcXtXNt240/4Yd+6K2/vyrdvbZlXb/tsvyur97354ebwpb/9jcAb/9LY83R9ObuyE brfabnetnb8twVIELF//dIKiXm16I0L/M7o361W/afp1ua3bcl2vur5tjIVt4KExYupiAGsB68pm J7A+gCEFI9EoGv6zPzY9e3ZTwv5VVrub8km9WpfVk+1N+Wl5+9fI427cvyv3JqymM1K3Te/bg3Rs e3NThO3gKW+MNcP3nRDf/RC/WcU/BbEWRB0+FIYtEsOSYFnpBPL7iK3VF0Z/IOXxTTFSYHub7Wpb VrcR9M+C+EYfPtOHH/Xh+FKfvg3yKEzniRBMK3W/2q1NT/UqCv5E3g5bDwCYQtkUZlAmsn/elPtm tUskxOHi9r+i4QA1R4DuP5PM/y0w+HklDD9r6Wt9AIYPAbZwTRnHQYKA5PiQGMBSbxnFjuKBgAlR B8gXE5MQrq/EIltdL0KCkIA5aOmer45HpPWluGPxj27x7o3jp9QlN5uN6TFxymIMLKNTlqlTbjZb A3yoW262zaqfxh0zk73IfWK2f8kxN9tdamch5IyuGbX5+q5ZVNE1B0f/Ta4Zo8Rj1/fru2ZRRdcc QhXuttlaoFvsnJtNZ65ZpLHeRPbMyRsjyF1u7Rg1NhxstqhkfL9iaLisu7GA2A2MTF9uhONOfeRV vldY8fpI9yip4NKOfhKeYSh3eg76NnPHRJGn0d59kN3OfdjlogJkyqOo/UpWh8+exIHBhgrC+3s3 lnxXm7L65CiBIES41Aqa1Rdfikf2/MSh2e7TABM9A72/FKpVtKdzf07tDf0hmB+FCu18LpGIcOi1 xDClhLXIQVHBk7ZnogaLVgwyiT9eWbjr9euZALbEThM+I+nfiOGMT5QAC3zIYO8j4qJy47vOMCcI FPJyBxDIVMIlceDIbreWsKuo7th2uCMC3B8lcVQARXfwepxkLat15grJTbNLc1ZSSJ7mrGafZqyQ 2q4Ukpt1m5Y1Q518kq+seBvsZSicrDLKCslNa6X0aZl9JVvF5LG4kDyfrZISs5OzXCokQ6w0rc1m q6LCK9EY2vRAZUqU/7jLrLcnuSoIfr6QtMYgTfDU3k859I44adnjlFQPitctVuYXsc0EC6umop+6 TT+eJE3MnlTwtXwacxYtOC7+YJkgMKCUgOHLk2eS2pQEJ26o/6ZBEYzmSoU0416UFYD9ziq0Jc7U 76yNe7A79buhvsw9wgtAa3E+Lc53Zv3e2sIZBJRskwIwqfh/o0uFPotzfptLRS9/bZfqzblOC8BL TtVv9zMi+4eMrKwWNlxjzWE95tQEz2a/ojrirbgKUQPu8Qy5CrUBBk1Skt8KVH/nHLzrbGHkNVm2 GXcReo9snrsOHPFDbANpHe/gEvc/Ag2bnHKAP2ECeAbRDE1iYLotiRuTFGpRfi6F9t05rz+ZxfTd JvX5RbOYvk9yIB2be3znKWMuhfZ9MmMiH7xhs5i+txnYwllM3w2ROYmxcRbzLOYuLFP2JCPChRKr pChQjxgjl/vFNBh4EvLMpJPcPe5tMaKCHtEhaMjAk/mGaVB0k6LyBkbbPbzRrLD/gC/iOZGMogJa iJALPkl8Eoi3I3BjMeFseXKcCg3CYJUjYrBI6i/ipk7Pd+fsHT1+HS0kRdnDEWQL51QuXutLTVEs c5UTAc4PTYNmMKohaKoimS8G+9ay3Ey35WYE2UuibFGJdJjL+UcBbuEUDsm2qe1KbKiCiR0fUBvZ Ipeg22yGEMKmllF6ZU5DuXLRerzPir1uP5n2nXZOBSP4bv86076+HmpJAtFM6O+dzNnQX59M+97Y 4G+B/7TYC3qad5puP0z7uNmJwf9csRf7BeKpG2le7IUK+GyxV1ZYJl6Af8rzglknVTkQfrJMP3dO 4oqDREdUB6UFnUfsZqv7tWCjWyc1k1bgQ194SrvYbC3rtbpNvaTT6jY2fvf7r0Vji+ESKzGCbGyx CY53bmzRbe3G0G0obqf3mfRYw+1OVAOh0gKQ7qXGP7nkujpk/78ZW3QbGxclNdelDqvrhwCZi+yc 20VxLXK7mC3xBvqnYJTFcrdLruFm3S44OAcBg+/IDQA573aRQ7aedbtyuOEIc3uhn7hdUS12OwqK POtZG9Gth+HBehNveZttUCm3W/3OQLoBpBPI5evm2uBDipreruAr2Pu1q62uDZOvs5hmvC7K7YzX FdVyr0vGiJ3U4cPCqMytVh67d59O4K7fOttIAJswxasAZFjYteNcKfG7i8lubTfNWaD6i+jETslM MrHZuURkk0xEFa1dWVahIqQ6iy59sSoWGqGFujxbMfcQrPb66AD3Od5DjqD0Z57i6HISXZ653QIr J2lagSYPVLlewepsgDJxRr6Lao7vSUxwvH49AGFq/oqKM2zsMQaV0cDGq8/BzYdnLr8b36eEgf3M BU9XD8Oy4IULt7T7uRHFx4ECM3giNoENE+MDTcGjj2S9CE4eYzc84rR0TqcK5BDUhVBkRH//WAn7 +a1m0FojJ3G8VkRGSR8VVryvwt+0heiXfxAIeyK5+XTusqkP3Wy0lfOoFsjkOVHjgxjdogLL6j1J 6x2dJOLPCwuicDT4g0y36UxDwKBEHembzBFixOIw3FDOp136O3i1kHAQkWkFpCkJitfzvUe7S4og +j1v1++hD7vnlFxF7uh6J0CgZJf4IoKI+myBLRaqQ6HjvnQ4b0M+90B0p0WPWz805J4D3yz5reiv ennhmKCVM9HBIzEIDKnHWY6a5DDtIRC5K2eWB6mRHQs6qMa3rTx1z5Zabd+khdaYw80g7G3fcCVr hVZrDwCXl1ltv0mr69jUzhRZ8T723MO+djO9zi2u3MdeLrHKtMSKUocqqi+Jn5VOccRLrHjONqwU 6R3LQ0ssu89B81Y/yGUpsVrrO9PG5lKB1dpTzzmfhhXxJuPDYrUApPWcaZmf9C04DoYmbMriPDT4 IMZmSt7IqfvO8GYgPaes3o178BhCMucRBV9lpU2O7w8R34uba07QjM3EpX6jHe+7H+AIzX7Ux9ku oRb3T4ab1AtvXFvrgwbNnsX0ZvQb7dgTLnaHZu71j4zyb9NSzJ/FyBswdezW87lgLkzYsFxs2ZOY 0howRHuACfYYPnklTbbDxKGogMkSTObj5GXYY7P8ScxBS4aVvQQv7eGLX/6rioevpoEgKYy1Hedm Uzwq4fEn6IK5w409dB+eVE+1Cm8I73ORpSMVv+CJPVoRJOciDx7nQQkf0J+l36FZe3Bz09Y1/fLC 5ma9S57SM4L/YCRgZmQq/uAcoYtjuJmAJi0zr2nAgvwSmccwP1XPz1IGm723uljkR3zvKIIGgovq fX0RmPY39tRiF6gT15HuZPIt9gXxyLqySELelc3QEIrYR9N092CbWG83D7aJ8UUxdwxxPvws2oQY Qir3+gbVn5bQ3lCismg13gz6bCO3AKGXRMECBdMoRGgEGQ0J9nrEIyd4U0MFWjRwZB7X/RuAuLDj eGx1rmviNMD5wJUuHJEHRNrM+Z6g2GZcB8t6URGbWBSqPOADm77PC4lE/U1alz6ONZQQTkRc+ttd r2VF2GI+wuT89UZ9edIwUpN6amZytJ59GnykobqgPZaI8GIWl8FkJaqpCDEq7BYtMSjAXPggBeS7 dQ7eFIks3C6I026smIrr7XuFNVgAE9Befhxf3Ew5w7ZEkohOVRu7L86Aw0SkwSBmVTvOPhWBi2qI wONXb8U/tVSOS6ElExnvi8EkQTRNU1ar6EoGaKXEvqzeRjdneWJh8kikyH6xgWLQXVoMBvIRMHY0 DYUzT1fARwiZs8/RG+IN4pw32E8R89G8NAg5kqFZUNSgX/ZoDZ3iSlrBwpFaOCAZKQsUpvSF26yP peAT6yFCcwIiRTrCuCQweUaDIGzirHBgE5Vbmlh8W8duhI5AI5vJ3Fy8sAky4VtkClR/j+idQ3Zw sEC1lVPy50HECME+2APH30Nqd/4rO9fWKvj4wyuntf+Idmk13ZwMsmLl9HEIIEmp+Z5CytPnzx9f y5WoyMUbjAObncSSmYJrBkeIIIoXmB4+4hFeQgaJy1ZLMejaNBFjAJoI/Vbk9H5qoE4wLFlVEQMG PyWZCgpYDFHUYHeRqySnTeuXspqrX4To2UQ3NB9wmbMCu0ICnR6LY2xJ6IIH5K/t0joaQrBaCZBJ 73EeGZK5yECUvCjI0UFkxix446akmjZ0Vyqs+uRtU/Qe3a/ZT40QgaE6HZuaQ8UfzIlokgm0Us5w 68oSKiLocxTlBJyB54UNUaKoEFEmEFCfasuqZY6ImItqgTFBDrSL4bQSjVQltxCAZwSKLvgTQnya vVrhi1+wRQY13yi00eqAOJe7EF5UVuyaOTRKNHnKiySRDmceXtxYCy27m7vMWNk/c9CaOdlrrX61 3m5be4udPx0RlN17tIK68npEW+beuNrYPNgr8/NrD0ia3fBo6w0f5zb2U5elw9xm+A07o4/4r2DY ddBtjOkYDR5KpYYZsaQ0KYPF7rFcPmCnwBxAHB08Gazhjmw7pI4cbf+CI5/cJY09zVmH9rf7+KZg ozBOo/WIDX+GQPgiM68mafIp44oJ/qTxJ4pemIdH4SRUHe+8lERLUCbtoFrCQMx7XryKMCC0F4Vk K9qCrBCEVoQDW/BCyTXodRWipdznmww1PJ6dW0OvSXZSHyb0KRLO3/A3ff77zOEKFYFCFyYt3Bwv IcypJ9CFiGHqslqBF2o0AAIXdLTFB1f7TWevBwkXC+v9pj15A8/8/G36Sh/BPZ44ybPJ34k11BIa ozLfwWck9FwvWpGo9HcgHRnCE6xXwpCgpTllDg2EPd7MixadCUf4A/adnc18QEzrZCGDAbAOJjhb BRbVJ9PdryAhOxl8GdNUd8JGdcgeH8lku33Q8fr/cou9Ox6rk/EHGtfLk/1wm//Q+qS2F5nYvafJ mQrlyuuLprbL63lM4cb+zbhyburh5n1plbKfk9jbGBrxFovDzqbxhN4UTyHLs4cgLa+SZbsXx6Re VEnZnPx6Z3jHXA//oldrzy2zp7kfqfjHy7jS5ejD9GyYZRP08o0eKflDEJay7ECsgv93Y6iFhvgh GYzllCN6DuBIy8HKox/+DxNI2aAKZW5kc3RyZWFtCmVuZG9iago1ODEgMCBvYmoKPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwNTM+PnN0cmVhbQp4AeWc25LbxhGG7/EUiG6MrZJoggR4 yI1rndixUpYSR3RSqTgXDi35IK0PpC3LL6u8ShqY+b8eYkBiV05VnHKlKgsBPT3dPX8fpmfo78qP yu/Kef+/w+dl25br5aJs54uyLg9Py2fdm2aevnh3V85n87lR7PZl3fQj7U8/clPsbsq3d7t6Nrfx u2dl9fib758er8rdV0Zn9O/tShtfh/nsT9vWNuG6HA57eVXYEKOez1Zt8n+diOuZjViW6/myXLSz xXq9bMp6HaStbdp52VFtRNWUi6Wo2qLXCXVPZFnNNWQzlOcfZVVfmaCzVf/wYD5bFNWD5VX5z3L3 x6jUprfEptyaderGpF7X7TifbnhZba7K8FBeFf2Lb/Ri//2VqWwks/i3jH8XopjrwaQKTOKnohIt XxqR/DZyMbHDmLUe7vs8tVm3rHb9i6L6nShe6OFTPfygh+NTPX3t9kiMYEiat7PNwpZrPosLcGJ3 p50bwYjJnjDX55oqPhQVkx9ltKhmvzI9FDtMdFD8TQ/DIQKZfbXZmHgC4m0HrVejIt978sFVEaz8 p2jcjyX7h3r4vR60Zv/SC7QKX4rqBhOwEtL3Sw3aszbYQoxF+42EGn74QkwGM5duYFvdoJCYfSlm h2zQI3R8TzN9puHA/AZ54cQc9x2RvScww6s9j9+KowSSsZ7Fwcx0kBA/akiuL1OL9lOppxdQwBed kEm0EinOU1Toqi+iRBIojvr0laRl8W1hQ6zISJAJOCAuwiFuGF1UkgUZIDWKJLR5vHZvWTUp8Ive xSxM5rNqEmyPqIfnw2WOwhfORooyGllRdM8rESee8HS4iphZxI9lZZQ/J3FRHZ5r1J/hc+DpJuPA iw6Bp6HVPCTkk7+K5aPr/pWF37/3xJZr9OlcYCirH6Qfhne7INiFeEAO6jLOCCLgIaNIJOZjOYFX 1Lqo7s0cRmOJvFwtu4i/WMWMOZLFjaTuSBqRTKRwo29TYIbYH/L3SaYsqwf1VZGAPMvfq2ZxmVOS wYP1MMXPyODdogcf/y9k8NIyeExDLwRzVtSjCjC1RZVF3NOXWzPDbXP4ajFWPF3naAl4KiqcFyGI 1g9jHL9+LNnNQ9qmK1CEQk89n0tR8A/qDz+JXCBmofTBixjJpS9YiXQzDFoYlMBNsMITsD4P4p+P vsFYmOQGgb/O1NwfhwK5UZQJYeSf4iRF5Ql1yGcW7Z/8FTpGvbndWq3tvhxq7aQiL9vtiSeHkv1c MW7UWy8GSTB4BcXwA3uSXFZY5n48Xzmfsi6sFkzjwcCLywpbT3lxUZ2twx2hyNsIxCN1ePTRZAHS ZNF5cYzTwAfYgE9BuE+esod7sZXfqQ8H24/X4e22C7m7myLdyZnJdhEPuKy7mtDs+ELAmBaKCvfg E29gJMCKH/pCgQM8B9QkHo066+bMHChNJrwabnumer0Xww9lf0D3jmOu8wWL2Nqn9ltU29iuzYaJ N2T7UyOxDUea2XqS4rw/rCbyEcJpZ1qEzU7mEe2qC+na6sSt+oRPRIhO+UQ57RNFt5cOufiST0SS KZ8oKjDC6mY+0delmU+0q27zlnpFCFlnvMI6HLnJrtmSMnvET1LEJjr0uxlA5+5yRGbfFlH1vVDQ J5GNbg1C00CYJYwN04n3CJAD8B9uQL+cSH+hSdwtFCojbCSEl8THIwbCZLB8JyrYL9H4pt0drH+K XraoMx+zTEEPqGwXi8zD+j5N3yQ6WeiVdaMWFzMFjROrHC9mnHa5HEClmPCuCPbbeFd0RHwIr5fN +TLpXUWVIPPNM07nXVTSZJx2aYEl6fxczDh1FwrxLpL9xwoUYBjwgR3KRaquJD8pavFKRtrn7gHr zAXw6HxQnsIuvMED9lZ0RdFwHvkZRIn7R3igs7QIYwovWfQBeyGx2IsCbaEIX0b2gISm4yDrWcA5 zXrNpusKJFkvrwGbTbc/S/ZzARdns16zCblqWIyAcvfKiTqw2YZe3VlOd64EiwrnmwupyMUnWZwv I34ZwbAWl5/hl1bUgBODQZb1mu1ykPUueWazWdAT9ULhseQEPInAfYoT3HA8fOg2/iGTPSIAPNmp gaJvD7RPRoZsTuxwIDbg226kILpnRUhwIjF2fsyJ+/o3Goc4MBxfyG68EWsyu/eu4vRF9VZXd9cl 7TpZAP7MrS+8QAXVF9bD4iMhYBYK+7tm36bZTPh6s72Lp7dJ1iQF4DXu5/YkVI/t9xrL5KSSX+t+ r2nXt86+TRNaZsPAeP7cJTkWoMsi7N0zz4rhDPQJ5aLxjIIjQEt1GIhH8hEAFrvkuOEBDomLHjT7 /UHznEzL3HiEOGsoYYy52YeKlLGQvIYvr0ScSBxeFdUFwTUqN5a+PIxbc2uVRdtfD1tlt9DWQ8N3 IVAV1l8e1h7Zgp+3kaSLU1tmOqICy4yRfK/AK7EWI/37C2mJYV30yRql7hvKl/pUTd3ttO9Qo9QT lYXHrmYidtlZ9VjrhSj4K6lRFt25wG13D818O1KjvFn0MnSHTS1A3T/nEVwCXgET59IL4bGo1NIa gSr8vAer8fmcEoy4JlJ3iqGrioLQxNg950YXvO5cTQcX8ZdoeZQUxV8URt6PgYqOpiiQkezh4TM3 RrYAmRGikGk1PHPf841L0k1Yrk/2LqEsTrsJy/UqjQqXL5OUy81JHdLdQUi7AB4TWt89j9Uzy012 PyblM4gIyWbwNt2ECBniS7Jr+UWdQi03dskn6SZc6tQt1+ON0g8EQgActwVe+3vzDd+kMhfEQKO7 TrcxDh1NbUoeQQUj3vhljhuhn/gBdfSHMdFeXeLENzhJbhzr8JLp2JCkGpycVJd+Qgdr28IFcFza n53fnSSu3lutqNzViZIQzWLEkKkeDv4NIR4vSizAessUotC/CVyoGMcWFSf+GS1G1JezXKNS/Vom O5eRaxVLu4SWNMI4vVY6KWM6SS4++Sf0zdMJRRv13D4qVlRDnf3sSptGzVpWr5310RZGyhBODRbW EQrN2aX1gaYC6qI/JfHD/aQZVBiXYYN22V8GSDZ3w6Dayg9PW7RFdgSyXJ50HDE0gXAQVjkWtANT rbcZoO91aN2JnbdvBhVVI4lHjgVjTEny8OUmbXLNiHX2PofBQ+tFk3bZ35ZIA6uaQcUYOhdNurOO xn+CeyWC9oaJHuIxzLuuyMe2h1BECJBd4f9ssIHD9YGwFVvBRNNVl28sNY/W9Ww0KCvqjg79vY7h b6G7mr2Fx08wTsDsK1DbRdp4aTZcOiymbiou52OFxd+iQEhPH0p6SU+sRStOFIzN1gBmrBcPB9bH XzFFFiTTWNgbMM8TSMHgl/BjLtr+XB7UkktNSA34ITlnWnnsVFxLwuFLyDM70U5kDk2KoJ9lW1TE kLWh9Z4fTmD8Ul8vqg+5L3aSqnsTaulhqBmwpMQzBxz2Zv7NKAIbbxAZ3IuRSojk+BWXdrslZVHw Fsp+lpYpVFN40skv9uVYMXkU1Mb9a7HJLqVb9ZxHjqMvwoGvaBLfFJU0urOfL2zvkPh5dwtlys8X q7Fwuxv6OQ4ATD3m50sKYhPDh7VBR0hQH84MgkZQEzDSGxURan6jQi5KTY0jgVSAcco42dYgA+Jp btYN6SBBgx/lAIBcEyGC2CEKM+pLHJsc8Xtm8xN0hmXek+wcdCxeeG5BaE2HOpmokBIOs734eS0S mOC7h4FZioq1+sQvMaMZFh+mfgTzKJp2TCd8tvWc6IdOA+WTYkdfZC90YNVdCr8MCPbYGGGq58Rh tEdTNBvdtETIf3I1GxSHDwf/ZnYWlzWIkxcepYbWRdCh5vo3WI7Segk2Zgm0RTcmYOPgIoStH6Sv yPq8IupoQWCnF3GMnUahvkTnhbsU8mm4I1ejlD3eHpgZKABZxSDmOfimP3BLagCIGH5JhJM42p2R RDSMIiUv7vtcLoVYwWi7k3J1wn3sB1tKNe4+Xut8K7n8lRsURSUIPqQXSJZji3VmxQA14ICfz36x +MLxHIHBzkyGyJAKDTgZMoOHvLjgExJG4ZOzGWZgclkF/SARUiDde/XlJQazokWWLTQFYAycHRFo hxCaeyTRJJuYhHzo1G4exM8FZPwseF1SFIXz28kKJ7ktHjY/00VRvRpp9j8cuD2wQ2iWBaEP9Ppz FaGWIbUGmJox+iLM6d9QssLgygMO6WVY2XrAPrLsvpjn50DfBEVhbbMxIxoMHEvK3ztKYgvY4qOP qHdDIsD7sbWLjoAqVKChhPFKHGJNpsmHxk0qMRp22A0waLS4wcVlsEAYgzZKKGHcOxuAIMWk8U6+ r+KFSMRopJB8kjfKOV7xTOSC+dgewpYzagkAERApkIsHyXUerJL4gM1hd3/gokOXjS6XFPqaDhSw oppGFJ5gE8cNsAeewzG+z9QCv/aNClLHuT3Wzs6ogZCSCW8AFNF1Tm5d9jkfiowJ0vNFwkZbmEPK N/2CEKMwGMMlnSd8t0swGBbEBm5dXkEkfsAHuUAA8MkGEaMQ2KtTMVaYyH1VFAxGSamEuIdgtcSB VHJ4s1uDsJnxv+xb9Xbsbpz4nBfYCx+qayUPJtcyS8lprsefIrfkbIDzpU8udPlZOiTGolYFxDgh OR4O4D8MBaVfx4dLXIaiGlvdkHKYGleQwppY/46USY1OWmXC80AAcf6rTQEMsHh/7WQXZz8825bV dT6bJAuSpoINQx4CashbnTXtZl/ONKpgx9f4kSBxIUx5CJiFdbpQkXFmYyJwZlO3J1f68iPwuj25 0jdxBF6vkit9+RnLSo3ZqZ9i1uuxHc25s5okhbATjfbgh4O3O6sJEZF5Gsn7Rmc1w7oCqLPCHpRt +RV7OCmoV6dX+i4dgdft+K9g5b4RXop+nt6mHdGrMxfXgR4spmnkvIQY4hs6n88OhvxoMryWB3dW uZKm0r+HiriKosy8UR/ymKYvRFjE1zFqORJgJQpKiw0rn7bETisBqgceUJm1I59GTYrqlWB+4a9w Ne7/i8nLcfXibpfj6v4YOP81IV61lVedntnmP+Ssl7+Qy3Fc3fE4EJE6ly7uESfnOLf5KWd6ZcnW WuvlcaD/0fzYma3dkOl/3GR/nLoeuxzHfSxQ5d22m5HNWoRaUloAPoHaqxrgDQ2uBnb5ubZMKDZI 9n6sNDgyamVbO5qXUQCxxR2S2Gbi1sHm5BZXcuWgu7jw7i45+bab5NuLmcexawlFQo1d4tquR7oW uMC5ywblucsGb/jLk/8tcO3n4bdF7cZizIjBAMf/I2wNISf/BYqiov6J4boH0F0uD6zDbaFwcf+W DbT+V8d5e/g6JmKLPuSrJIiN96ZZhsMo+hu7XTJf2gWHpf3q/vQ/DGZnsPlikuuQIOs2ETeYmpDC m7S2D9sLPhGRQrgpKnI9jZA/xLiDDDwwOJecfgo0TJmY5qP/ALWd0kkKZW5kc3RyZWFtCmVuZG9i ago1ODIgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDI4NTA+PnN0cmVhbQp4 AeWbTZMbtxGG7/gViE/DKi0z5MyQXF9SsiOpNpW4yg5vkQ/y6sOKvZZNOnb0Z/1bAg7wPg0OMFzx nFLVcgpoNLrf/kCjZ/SL/9r/4tvx3+GdHwa/7dZ+aNd+5Q9v/NvTSN/mA1/sfbts20Cxv/erflwZ fsaVO7d/8H/e71fLNqzfv/XNVx9+fXNc+P2/A12gf7b3Yf0q7hd+hn633G53Xdh168/Xuua39+PC sKZdbobsz0nQrd+2nV9vlu2qD5OrbRR3FfZt/YlgFwh6v+5FMLhRH1Q9k2PTBurdRAL/L9+sFv6m Xa59c6uHm27hvvX7vyVddiMAO38bQBkl2a6GS3x24uMXQaO1az5o4P7XccQ3y/QbKXyzFkWrB6Ri yi/cKCYznWg/T9wYgMsT22e1XW59s08DXy5cVPpHMXmlh//o4fhGTz8tvPDIQAgO1A7L3ToYqV0m 7M8gN9o2EFQg+0YbsNN9wso1Dw8Mhu2jsK/1wBQjQvLAVFLINdAEZ4t8YPhOI4JQbJDsOYCNa10z aAmG4WGjqWTeEbMxVk4+e4qVP8ndv9g7CxFw2ux2GU6VRVlc2aLtJqB/Hlknv36KaY84YOYPQ7+8 DUSGl1T/+EG+gSdo6shIuUyu/b1AAH/NiMtdgvSZnFEYi8CYn/JDNFkyq2t+14ioITlqBJKpLL4x WWIwBWXTBqhWcCEycBtxiXC6RksQRQSasFDCPR8Q923C45Vwh80BE34UJ8PmqE0O0JNf3ovVb+wn BlqF4pqweNPIzU18ykBnFXAhImGm5eAGyY8SCzb3EEkulAFtgnTCeMRdeameeDabPguodGKF2BDk 816lROQtfQDlzc9yGvTIpE6JVfpgZjRl5DM4/heODAWrJk5mGCARc3gC8WcTkHyTFmV5sCDRAEij Fw+ZdWPksCMkEkrcBDIEB81IcdfUFJ/yMZcv0oFXOnANir/UmG+wiliSECQJuB+Q8mfhbqYQNfjg /ewAPqxKADmTAvNBc3y5EG8mEURCi+K7QjDN4AZhIAuIrIijHLNjY1iXx0bz7sOH1/796zev/jKe VJXDq1rkGdf+VAroMPrUE2ydH3sWpS9SxQNcYMTIAdXxRx4+LkLNeSp6nowJ1tI0a4SfBTuGxTFg x54qxDCUHL1kV3pFkTtq/iHLkym0A1sSSkgVIinlC4bsYLgqhUQ1XAMWdnpJQ9weCQtMiRXKCYQH FbGTvoQn/LF4YuempfPFGqtaLq1CuRRqUVfx7endxdy6rZ8jd3Oe9SDVUADtpawoJsi5xuC+xwRm Si2nIqDaYYe0p2t+iJ7vKVCsEtTuUQOjwDZwi5RO54i364xEEa8fSmURTjShpIjnx3c6Q9Fxyg5g 7AAQlzTlGqKTB5FciWLYY/ZGJMEILEBiM5RInuuoNFlEqIid5S5wO6IGyv86TYLF5mWwaIeJDX3z jZR8nmrOL2UFpMuOzzIc7xkKZsxOmspdZrgN50vlzodiuVWjSzAlWMEFEO95Oh4hPxAL5EBjbrkd biAIcgKMgYRc5vWSaT4V3yVMZ+41LqB/fpnxY//j7H5DQeObl4twBgvj8/aIi+2RYTidmxcbJMNw eyKxFknsoWQtkuweGlokw6arWo2mgzVJepMuFN9Fk2TY5pWAHepwmrRJsrzCNWaZEI3Yu09sk5ya LllbJ8gZIdYdP3R34sBWM1manLZJ0toyLlPE5+k6OJjsxckxbLYB0LxREi1Qv68Mw4biySAr/cac +kKbxDUECx4vL7b4IIqgIQgImHdCTBCKDZIV+WQQtnRH0oNrrmqT1I7woe9JLCtXdFaqS0LLU1Wp AVu2SFwqFscD8VKLZK5rcNYiSX4mtJRlSKJgrxlRVlJJTJEiMPvN34nsUMeiKctnF/rHZbnYIkka ogguI42y0BrDElFEII3CeZ2Y4bW1FknCHTb1FknidLlFklg92iKxi4OV0ZJaLZIsb3PoUhOQPF5L RS0HN0h4gM1siyQ7nCi2C8ZhQDlpJuWsw40uVcMWGTrlsEVRyFkKInEkYtcUl5zsKl54CJUHYDAS +gTJkrU+AT5gZimYw5PWE30CpliEIjUUR+/lFoJ1eCgWl5acunwEOXs/wK1ODRJ/VYMkvk+ZqydQ PKvwgFCipXRgLs89OG+QpMjBOZAbP8T36WKBD6sACCmwBDRnDZLkC0AuoWUurhQs1wy2TuHg4k3v YoNkKN8W1dsjZyfQ5fZIf7vhGKo0R7JajAKi39lhZ/H5IlVGaDqFzjV2vQBoHiatETspcqBGjw9h nmDHpLgE7JBCeGMi5ZE44Zr5rOGvzhrxRNQObIkzItUnJY8sm8qvAANFpR9Y2C1TUzg8WQw2IiFK kJkHokSASRbO6TJYYLc8K5dj3leXw01eP9WKpH5rRVLFO6tLNm2lYL07F6QBgUfbIpZ4WCPUDOpP bItM0wUhcnVbJOudYymJBVdmZDJR5G2RJFNxmqY3Lb4hh+FiU3YJmBDgOLh2AjMclgeRzKCY5NJe XKhtDzixiYgRIzmv2dCKYby2WESYaMby1k9KPdW2SLzmTTe3VMaWyULWksFSAmX+GoN02aH5vcRi h7wt8ki51fdn3yCcwjK8jwJTw1uyMaUBHA7V1RQJd9F6UySd18bc0jDcyDxJK4MLNcGNRZJpPgnf janANTNNkVNLalpNXLrRnJoi0VfHqlbZbfpyvZqqutrZ68J3K7Nt335dO3ufp+wGLjgYtiJYeJg9 cSNA5rZUYDArLyhkfEQwmsI2doLXegWKOhxdAxw4VvillOQa9odIjlCsxklFIX1v/hoNb9miWAsC mhEP1D6fyF6loA6imvMXbM1I2qDSR5SLo9DBOBI7Wi+5UsSYjlDC5g8MxpC4PJRTD5RjzAHGPUpL VgK2rIkSCKEiy214+arYr6w+sFJUuSQ7JNHkqovgE6qGSTsYVUFPCHFI2rGmqWgC16AeYMzReqMt fN4Hn09nJAzPd8pWo74okBt/sBLmwuVVyykOcFR24JsRS5qgheuLD45PgxX8cAe20CLYQftAjYIY h4rrJbhwPQX+06+U8Z8uwteBpxe02msSNpoIH4MhOuIwgppIs7Sex3nfPHw16MJnhd12d7lr3m1v L/bMs+Ml9My7XVepgelzW8d8MLlqHfPuttaJgc//R7+8220DuvZZ4aVuebcdso8NLCP9E1fFUy1X 4y7kTesShrI3ph5yhTKpPJTCnSyAH8p5w1ubsQXzrQtfkF5ToHRn717OLmCpX1F5zdYNq+oLm31K psiZouPitcFQslwcy2y0JNDvElRCxrIqcagpkBZEU+56xwm64C8WZFB4YTVGUmoIR5r20WrY0boQ BYshIcEcP48aXl1odt3pnZveNkQ7uvzTzyx90Obp1qf3RFpkvvx0miODjVJmfcSTo+EIBfQCSvMI 4fSPvys1P0up6ir/XdXDsaZCqvkfUSEG4+Mq+IZTBufDY1XgWBGmisWHj4whK/ERKkaeoMterC1j mF3vI218z3rVVyjr23qs341C2IVNguPcBC1K4u4KBK25TwVApiMQAbIWwUWrrZjRyO/yVhIR7MRF pIg7O3F8Mkk6MEUSUoi4zr6+qtWrF4rxCh/woFGBbgbEkZzDpO7rqm/OSkeVTTjyNFmW3/AIL9BI SIZ+gFA4MgdShFWyePalq1ZxfJJzNCM3yVsX2O8PZCfXhDixu4XTxwJ9NyzbLtwquvAS9/y/lYSm SNkZAEqUOOjokGBkFGTA5xmxDpOQS1OZS4gfENASe5FOVmTgAW35zIYtsT00TB0Mmq//B9y99G0K ZW5kc3RyZWFtCmVuZG9iago0MjQgMCBvYmoKPDwvTGVuZ3RoIDE2Pj5zdHJlYW0KcQovR1JGb3Jt MCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjQyNSAwIG9iago8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMTQgMCBSCi9Gb250IDE1IDAgUi9YT2JqZWN0PDwvR1JGb3JtMCA1NjMgMCBS Pj4+PgplbmRvYmoKNDMyIDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8K UQoKZW5kc3RyZWFtCmVuZG9iago0MzMgMCBvYmoKPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDk0IDAgUgovRm9udCA5NSAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTY0IDAgUj4+Pj4K ZW5kb2JqCjQzNSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVu ZHN0cmVhbQplbmRvYmoKNDM2IDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAxMDkgMCBSCi9Gb250IDExMCAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTY1IDAgUj4+Pj4KZW5k b2JqCjQ0MSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0 cmVhbQplbmRvYmoKNDQyIDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAx MjUgMCBSCi9Gb250IDEyNiAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTY2IDAgUj4+Pj4KZW5kb2Jq CjQ0NCAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVh bQplbmRvYmoKNDQ1IDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMzQg MCBSCi9Gb250IDEzNSAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTY3IDAgUj4+Pj4KZW5kb2JqCjQ1 MyAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQpl bmRvYmoKNDU0IDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNDQgMCBS Ci9Gb250IDE0NSAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTY4IDAgUj4+Pj4KZW5kb2JqCjQ2MSAw IG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRv YmoKNDYyIDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNTYgMCBSCi9G b250IDE1NyAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTY5IDAgUj4+Pj4KZW5kb2JqCjQ2NiAwIG9i ago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoK NDY3IDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNjIgMCBSCi9Gb250 IDE2MyAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTcwIDAgUj4+Pj4KZW5kb2JqCjQ3MSAwIG9iago8 PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNDcy IDAgb2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNjkgMCBSCi9Gb250IDE3 MCAwIFIvWE9iamVjdDw8L0dSRm9ybTAgNTcxIDAgUj4+Pj4KZW5kb2JqCjQ3NiAwIG9iago8PC9M ZW5ndGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNDc3IDAg b2JqCjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNzYgMCBSCi9Gb250IDE3NyAw IFIvWE9iamVjdDw8L0dSRm9ybTAgNTcyIDAgUj4+Pj4KZW5kb2JqCjQ4MyAwIG9iago8PC9MZW5n dGggMTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNDg0IDAgb2Jq Cjw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxODggMCBSCi9Gb250IDE4OSAwIFIv WE9iamVjdDw8L0dSRm9ybTAgNTczIDAgUj4+Pj4KZW5kb2JqCjQ4NiAwIG9iago8PC9MZW5ndGgg MTY+PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNDg3IDAgb2JqCjw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMDQgMCBSCi9Gb250IDIwNSAwIFIvWE9i amVjdDw8L0dSRm9ybTAgNTc0IDAgUj4+Pj4KZW5kb2JqCjQ4OSAwIG9iago8PC9MZW5ndGggMTY+ PnN0cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNDkwIDAgb2JqCjw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMTEgMCBSCi9Gb250IDIxMiAwIFIvWE9iamVj dDw8L0dSRm9ybTAgNTc1IDAgUj4+Pj4KZW5kb2JqCjQ5NiAwIG9iago8PC9MZW5ndGggMTY+PnN0 cmVhbQpxCi9HUkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNDk3IDAgb2JqCjw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMzQgMCBSCi9Gb250IDIzNSAwIFIvWE9iamVjdDw8 L0dSRm9ybTAgNTc2IDAgUj4+Pj4KZW5kb2JqCjQ5OCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50 IDMgMCBSL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Bbm5vdHNbNDk5IDAgUiA1MDAgMCBSIDUwMSAw IFIgNTAyIDAgUl0vUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDU1NCAwIFIvVFQxLjEgNTU3IDAg Uj4+Pj4vQ29udGVudHMgNTc3IDAgUj4+CmVuZG9iago1MDMgMCBvYmoKPDwvVHlwZS9QYWdlL1Bh cmVudCAzIDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzUwNCAwIFIgNTA1IDAgUiA1 MDYgMCBSIDUwNyAwIFIgNTA4IDAgUiA1MDkgMCBSIDUxMCAwIFIgNTExIDAgUl0vUmVzb3VyY2Vz PDwvRm9udDw8L1RUMS4wIDU1NCAwIFIvVFQxLjEgNTU3IDAgUj4+Pj4vQ29udGVudHMgNTc4IDAg Uj4+CmVuZG9iago1MTIgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzIDAgUi9NZWRpYUJveFsw IDAgNjEyIDc5Ml0vQW5ub3RzWzUxMyAwIFIgNTE0IDAgUiA1MTUgMCBSIDUxNiAwIFIgNTE3IDAg UiA1MTggMCBSIDUxOSAwIFIgNTIwIDAgUiA1MjEgMCBSIDUyMiAwIFJdL1Jlc291cmNlczw8L0Zv bnQ8PC9UVDEuMCA1NTQgMCBSL1RUMS4xIDU1NyAwIFI+Pj4+L0NvbnRlbnRzIDU3OSAwIFI+Pgpl bmRvYmoKNTIzIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMyAwIFIvTWVkaWFCb3hbMCAwIDYx MiA3OTJdL0Fubm90c1s1MjQgMCBSIDUyNSAwIFIgNTI2IDAgUiA1MjcgMCBSIDUyOCAwIFIgNTI5 IDAgUiA1MzAgMCBSIDUzMSAwIFIgNTMyIDAgUiA1MzMgMCBSIDUzNCAwIFIgNTM1IDAgUl0vUmVz b3VyY2VzPDwvRm9udDw8L1RUMS4wIDU1NCAwIFIvVFQxLjEgNTU3IDAgUj4+Pj4vQ29udGVudHMg NTgwIDAgUj4+CmVuZG9iago1MzYgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzIDAgUi9NZWRp YUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzUzNyAwIFIgNTM4IDAgUiA1MzkgMCBSIDU0MCAwIFIg NTQxIDAgUiA1NDIgMCBSIDU0MyAwIFIgNTQ0IDAgUiA1NDUgMCBSIDU0NiAwIFIgNTQ3IDAgUiA1 NDggMCBSIDU0OSAwIFJdL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEuMCA1NTQgMCBSL1RUMS4xIDU1 NyAwIFI+Pj4+L0NvbnRlbnRzIDU4MSAwIFI+PgplbmRvYmoKNTUwIDAgb2JqCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMyAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Fubm90c1s1NTEgMCBSIDU1MiAw IFIgNTUzIDAgUl0vUmVzb3VyY2VzPDwvRm9udDw8L1RUMS4wIDU1NCAwIFIvVFQxLjEgNTU3IDAg Uj4+Pj4vQ29udGVudHMgNTgyIDAgUj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcy9L aWRzWwo0IDAgUgoxNiAwIFIKODUgMCBSCjk2IDAgUgoxMDQgMCBSCjExMSAwIFIKMTI3IDAgUgox MzYgMCBSCjE0NiAwIFIKMTU4IDAgUgoxNjQgMCBSCjE3MSAwIFIKMTc4IDAgUgoxOTAgMCBSCjE5 NiAwIFIKMjA2IDAgUgoyMTMgMCBSCjIxOSAwIFIKMjI2IDAgUgoyMzYgMCBSCjI0MyAwIFIKMjUx IDAgUgoyNjggMCBSIDQ5OCAwIFIgNTAzIDAgUiA1MTIgMCBSIDUyMyAwIFIgNTM2IDAgUiA1NTAg MCBSXS9Db3VudCAyOSA+PgplbmRvYmoKeHJlZgowIDEKMDAwMDAwMDAwMCA2NTUzNSBmIAoyIDMK MDAwMDEwNTMxNCAwMDAwMCBuIAowMDAwMTkwNjk3IDAwMDAwIG4gCjAwMDAxMDU4MjggMDAwMDAg biAKODUgMQowMDAwMTA2MDU3IDAwMDAwIG4gCjEwNCAxCjAwMDAxMDYzMTggMDAwMDAgbiAKMTEx IDEKMDAwMDEwNjUxNSAwMDAwMCBuIAoxMjcgMQowMDAwMTA2ODA4IDAwMDAwIG4gCjEzNiAxCjAw MDAxMDcwMjEgMDAwMDAgbiAKMTQ2IDEKMDAwMDEwNzI5MCAwMDAwMCBuIAoxNTggMQowMDAwMTA3 NTY3IDAwMDAwIG4gCjE2NCAxCjAwMDAxMDc3NzIgMDAwMDAgbiAKMTcxIDEKMDAwMDEwNzk4NSAw MDAwMCBuIAoxNzggMQowMDAwMTA4MTk4IDAwMDAwIG4gCjE5NiAxCjAwMDAxMDg0NjcgMDAwMDAg biAKMjA2IDEKMDAwMDEwODY4OCAwMDAwMCBuIAoyMjYgMQowMDAwMTA4ODg1IDAwMDAwIG4gCjI3 NiAxCjAwMDAxMDU1ODcgMDAwMDAgbiAKMjc4IDEKMDAwMDEwNTk3OCAwMDAwMCBuIAoyODkgMQow MDAwMTA2MjA5IDAwMDAwIG4gCjMxMiAxCjAwMDAxMDY0NzIgMDAwMDAgbiAKMzE0IDEKMDAwMDEw NjY2OSAwMDAwMCBuIAozMjggMQowMDAwMTA5MDM5IDAwMDAwIG4gCjMzNiAxCjAwMDAxMDY5NjIg MDAwMDAgbiAKMzM5IDEKMDAwMDEwNzE3NSAwMDAwMCBuIAozNTcgMQowMDAwMTA3NDQ0IDAwMDAw IG4gCjM3MiAxCjAwMDAxMDc3MjEgMDAwMDAgbiAKMzc5IDEKMDAwMDEwNzkyNiAwMDAwMCBuIAoz ODkgMQowMDAwMTA4MTM5IDAwMDAwIG4gCjM5NiAxCjAwMDAxMDgzNTIgMDAwMDAgbiAKNDEwIDEK MDAwMDEwODYyMSAwMDAwMCBuIAo0MTIgMQowMDAwMTA4ODQyIDAwMDAwIG4gCjQxOCAxNjUKMDAw MDEwNTcyOCAwMDAwMCBuIAowMDAwMTA1Nzc4IDAwMDAwIG4gCjAwMDAxMDkyNjcgMDAwMDAgbiAK MDAwMDEwOTUyNyAwMDAwMCBuIAowMDAwMTA5Nzg5IDAwMDAwIG4gCjAwMDAxMTAwNTIgMDAwMDAg biAKMDAwMDE4NzA5MSAwMDAwMCBuIAowMDAwMTg3MTU2IDAwMDAwIG4gCjAwMDAxMTAzMTUgMDAw MDAgbiAKMDAwMDExMDU3OSAwMDAwMCBuIAowMDAwMTEwODQyIDAwMDAwIG4gCjAwMDAxMTExMDgg MDAwMDAgbiAKMDAwMDExMTM3MiAwMDAwMCBuIAowMDAwMTExNjMzIDAwMDAwIG4gCjAwMDAxODcy NTcgMDAwMDAgbiAKMDAwMDE4NzMyMiAwMDAwMCBuIAowMDAwMTExODk1IDAwMDAwIG4gCjAwMDAx ODc0MjMgMDAwMDAgbiAKMDAwMDE4NzQ4OCAwMDAwMCBuIAowMDAwMTEyMTU3IDAwMDAwIG4gCjAw MDAxMTI0MTkgMDAwMDAgbiAKMDAwMDExMjY4MSAwMDAwMCBuIAowMDAwMTEyOTQzIDAwMDAwIG4g CjAwMDAxODc1OTEgMDAwMDAgbiAKMDAwMDE4NzY1NiAwMDAwMCBuIAowMDAwMTEzMjA1IDAwMDAw IG4gCjAwMDAxODc3NTkgMDAwMDAgbiAKMDAwMDE4NzgyNCAwMDAwMCBuIAowMDAwMTEzNDY3IDAw MDAwIG4gCjAwMDAxMTM3MjkgMDAwMDAgbiAKMDAwMDExMzk5MSAwMDAwMCBuIAowMDAwMTE0MjUz IDAwMDAwIG4gCjAwMDAxMTQ1MTUgMDAwMDAgbiAKMDAwMDExNDc3NyAwMDAwMCBuIAowMDAwMTE1 MDM5IDAwMDAwIG4gCjAwMDAxODc5MjcgMDAwMDAgbiAKMDAwMDE4Nzk5MiAwMDAwMCBuIAowMDAw MTE1MzAxIDAwMDAwIG4gCjAwMDAxMTU1NjMgMDAwMDAgbiAKMDAwMDExNTgyNyAwMDAwMCBuIAow MDAwMTE2MDkyIDAwMDAwIG4gCjAwMDAxMTYzNTQgMDAwMDAgbiAKMDAwMDExNjYxNiAwMDAwMCBu IAowMDAwMTg4MDk1IDAwMDAwIG4gCjAwMDAxODgxNjAgMDAwMDAgbiAKMDAwMDExNjg3OCAwMDAw MCBuIAowMDAwMTE3MTQyIDAwMDAwIG4gCjAwMDAxMTc0MDcgMDAwMDAgbiAKMDAwMDE4ODI2MyAw MDAwMCBuIAowMDAwMTg4MzI4IDAwMDAwIG4gCjAwMDAxMTc2NzEgMDAwMDAgbiAKMDAwMDExNzkz NSAwMDAwMCBuIAowMDAwMTE4MTk5IDAwMDAwIG4gCjAwMDAxODg0MzEgMDAwMDAgbiAKMDAwMDE4 ODQ5NiAwMDAwMCBuIAowMDAwMTE4NDY0IDAwMDAwIG4gCjAwMDAxMTg3MjYgMDAwMDAgbiAKMDAw MDExODk4OCAwMDAwMCBuIAowMDAwMTg4NTk5IDAwMDAwIG4gCjAwMDAxODg2NjQgMDAwMDAgbiAK MDAwMDExOTI1MCAwMDAwMCBuIAowMDAwMTE5NTEyIDAwMDAwIG4gCjAwMDAxMTk3NzQgMDAwMDAg biAKMDAwMDEyMDAzNiAwMDAwMCBuIAowMDAwMTIwMzAwIDAwMDAwIG4gCjAwMDAxODg3NjcgMDAw MDAgbiAKMDAwMDE4ODgzMiAwMDAwMCBuIAowMDAwMTIwNTY1IDAwMDAwIG4gCjAwMDAxODg5MzUg MDAwMDAgbiAKMDAwMDE4OTAwMCAwMDAwMCBuIAowMDAwMTIwODI3IDAwMDAwIG4gCjAwMDAxODkx MDMgMDAwMDAgbiAKMDAwMDE4OTE2OCAwMDAwMCBuIAowMDAwMTIxMDg5IDAwMDAwIG4gCjAwMDAx MjEzNTAgMDAwMDAgbiAKMDAwMDEyMTYxMiAwMDAwMCBuIAowMDAwMTIxODc0IDAwMDAwIG4gCjAw MDAxMjIxMzggMDAwMDAgbiAKMDAwMDE4OTI3MSAwMDAwMCBuIAowMDAwMTg5MzM2IDAwMDAwIG4g CjAwMDAxODk0MzkgMDAwMDAgbiAKMDAwMDEwOTEzOCAwMDAwMCBuIAowMDAwMTA5Mzk4IDAwMDAw IG4gCjAwMDAxMDk2NTggMDAwMDAgbiAKMDAwMDEwOTkyMyAwMDAwMCBuIAowMDAwMTg5NjE0IDAw MDAwIG4gCjAwMDAxMTAxODMgMDAwMDAgbiAKMDAwMDExMDQ0OSAwMDAwMCBuIAowMDAwMTEwNzEw IDAwMDAwIG4gCjAwMDAxMTA5NzYgMDAwMDAgbiAKMDAwMDExMTI0MiAwMDAwMCBuIAowMDAwMTEx NTAzIDAwMDAwIG4gCjAwMDAxMTE3NjQgMDAwMDAgbiAKMDAwMDExMjAyNiAwMDAwMCBuIAowMDAw MTg5ODIxIDAwMDAwIG4gCjAwMDAxMTIyODggMDAwMDAgbiAKMDAwMDExMjU1MCAwMDAwMCBuIAow MDAwMTEyODEyIDAwMDAwIG4gCjAwMDAxMTMwNzQgMDAwMDAgbiAKMDAwMDExMzMzNiAwMDAwMCBu IAowMDAwMTEzNTk4IDAwMDAwIG4gCjAwMDAxMTM4NjAgMDAwMDAgbiAKMDAwMDExNDEyMiAwMDAw MCBuIAowMDAwMTE0Mzg0IDAwMDAwIG4gCjAwMDAxMTQ2NDYgMDAwMDAgbiAKMDAwMDE5MDA0NCAw MDAwMCBuIAowMDAwMTE0OTA4IDAwMDAwIG4gCjAwMDAxMTUxNzAgMDAwMDAgbiAKMDAwMDExNTQz MiAwMDAwMCBuIAowMDAwMTE1Njk0IDAwMDAwIG4gCjAwMDAxMTU5NjEgMDAwMDAgbiAKMDAwMDEx NjIyMyAwMDAwMCBuIAowMDAwMTE2NDg1IDAwMDAwIG4gCjAwMDAxMTY3NDcgMDAwMDAgbiAKMDAw MDExNzAwOSAwMDAwMCBuIAowMDAwMTE3Mjc2IDAwMDAwIG4gCjAwMDAxMTc1MzggMDAwMDAgbiAK MDAwMDExNzgwNSAwMDAwMCBuIAowMDAwMTkwMjgzIDAwMDAwIG4gCjAwMDAxMTgwNjYgMDAwMDAg biAKMDAwMDExODMzMyAwMDAwMCBuIAowMDAwMTE4NTk1IDAwMDAwIG4gCjAwMDAxMTg4NTcgMDAw MDAgbiAKMDAwMDExOTExOSAwMDAwMCBuIAowMDAwMTE5MzgxIDAwMDAwIG4gCjAwMDAxMTk2NDMg MDAwMDAgbiAKMDAwMDExOTkwNSAwMDAwMCBuIAowMDAwMTIwMTY3IDAwMDAwIG4gCjAwMDAxMjA0 MzQgMDAwMDAgbiAKMDAwMDEyMDY5NiAwMDAwMCBuIAowMDAwMTIwOTU4IDAwMDAwIG4gCjAwMDAx MjEyMjAgMDAwMDAgbiAKMDAwMDE5MDUzMCAwMDAwMCBuIAowMDAwMTIxNDgxIDAwMDAwIG4gCjAw MDAxMjE3NDMgMDAwMDAgbiAKMDAwMDEyMjAwNSAwMDAwMCBuIAowMDAwMTIyMjcyIDAwMDAwIG4g CjAwMDAxMjI5ODMgMDAwMDAgbiAKMDAwMDEyMzAzNyAwMDAwMCBuIAowMDAwMTIzMDg5IDAwMDAw IG4gCjAwMDAxMjMyNTcgMDAwMDAgbiAKMDAwMDEyMzQ5OSAwMDAwMCBuIAowMDAwMTM5MTEyIDAw MDAwIG4gCjAwMDAxMzkzNTMgMDAwMDAgbiAKMDAwMDEzOTY0NiAwMDAwMCBuIAowMDAwMTQyNDYy IDAwMDAwIG4gCjAwMDAxNDQxNjEgMDAwMDAgbiAKMDAwMDE0NjQzMyAwMDAwMCBuIAowMDAwMTQ3 MDg4IDAwMDAwIG4gCjAwMDAxNDg3MDkgMDAwMDAgbiAKMDAwMDE0OTM2MyAwMDAwMCBuIAowMDAw MTUxNzY3IDAwMDAwIG4gCjAwMDAxNTM5MTkgMDAwMDAgbiAKMDAwMDE1NTIxMCAwMDAwMCBuIAow MDAwMTU2NTYxIDAwMDAwIG4gCjAwMDAxNTc5MTIgMDAwMDAgbiAKMDAwMDE1OTY5MCAwMDAwMCBu IAowMDAwMTYwMzUxIDAwMDAwIG4gCjAwMDAxNjEwODcgMDAwMDAgbiAKMDAwMDE2MjM3OSAwMDAw MCBuIAowMDAwMTY2NTg3IDAwMDAwIG4gCjAwMDAxNzE2NDQgMDAwMDAgbiAKMDAwMDE3NjAzMiAw MDAwMCBuIAowMDAwMTgwMDQ0IDAwMDAwIG4gCjAwMDAxODQxNjkgMDAwMDAgbiAKdHJhaWxlcgo8 PC9TaXplIDU4My9QcmV2IDEwNTAzMC9Sb290IDEgMCBSL0luZm8gMiAwIFIvSURbPDhDRjdBQUFC NTI1MDNCNDA2QjYyODJDODIyQUMwNzQxPjw1RjM0NTYzOEFFOUZCMzFGRDAwMzI0M0U2MEY0RDY3 Qj5dPj4Kc3RhcnR4cmVmCjE5MDk3NAolJUVPRgo= --Apple-Mail-2F3798D4-F1BC-4B8C-BC6A-5A52D0E98076 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sent from my iPad --Apple-Mail-2F3798D4-F1BC-4B8C-BC6A-5A52D0E98076-- From william.d.ivancic@nasa.gov Mon Oct 22 12:10:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F9921F849D for ; Mon, 22 Oct 2012 12:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp9AKvdgl39L for ; Mon, 22 Oct 2012 12:10:37 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33621F88C6 for ; Mon, 22 Oct 2012 12:10:34 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 1AB1A2601D7 for ; Mon, 22 Oct 2012 14:10:34 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q9MJ9w8C020856 for ; Mon, 22 Oct 2012 14:10:33 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Mon, 22 Oct 2012 14:10:28 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "manet@ietf.org" Date: Mon, 22 Oct 2012 14:10:27 -0500 Thread-Topic: DLEP and modem Link Property Advertisements Thread-Index: Ac2wiOW/eBU1uMoeQi6P2m8wxbwm4A== Message-ID: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3416819E11884AE9945484421FF65A9Fnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-22_02:2012-10-22, 2012-10-22, 1970-01-01 signatures=0 Subject: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:10:41 -0000 --_000_3416819E11884AE9945484421FF65A9Fnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few months ago (time flies), the authors of modemLPA have been in disc= ussion with the authors of "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] to determine if DLEP will fullfil the needs that ModemLPA is targeted at. DLEP is currently a client/server session oriented protocol that provides link layer information to directly connected devices - generally routers. The Modem Link Property Advertisment protocol broadcasts link status notifications to directly-attached devices and devices or applications that may be multiple hops away from the modem (or other sending device). It should be possible to use the DLEP message formats without all the signalling required for the DLEP client/server session to perform the functions addressed in this draft. The modem would simply provide link states out via multicast or unicast UDP datagrams (DLEP-Lite). Whether or not this is a good idea, or acceptable to the manet group, is yet to be determined. In the mean time, This modemLPA document was originally submitted to the IR= TF mobopts research group as an individual submission draft-ivancic-mobopts= -modemlpa-01. That research group as recently closed down. I am looking f= or a new place to put updates until a decision is made on DLEP-Lite. Is the= manet group the right place? I really don't know if this is the right gro= up or if someplace else may be more appropriate. I see no other working gr= oups or research groups really looking at layer-2 triggers. Finally: A PERL script, modem-LPA-packetgen.pl, ha= s been placed in sourceforge as open source software. The PERL script generates modemLPA packets base on the modem link property advertisement draft, "draft-ivancic-mobopts-modemlpa-01". The script was used to demonstrate modemLPA by controlling the rate on a file transfer protocol. The file transfer protocol used was Saratoga and is implemented in a PERL script. The Saratoga PERL script is available on SourceForge. Search for saratoga and the script will be in the directory saratoga-v1-perl. This script and the Saratoga implementation currently use a multicast address of 226.1.1.2. The all routers address of 224.0.0.2 is suppose to be used, but the particular Linux machines we where running on did not want to pass 224.0.0.2 and we did not have sufficient time to determine why. Eventually, we hope to include code for GNU radios that implement modemLPA (Or perhap DLEP-lite). Code is available for modemLPA from http://sourceforge.net/projects/modemlpa/ Code is available for Saratoga from http://saratoga.cvs.sourceforge.net/viewvc/saratoga/ I am currently planning on attending the IETF meetings in Atlanta. - Will Ivancic --_000_3416819E11884AE9945484421FF65A9Fnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
   A few months ago (=
time flies), the authors of modemLPA have been in discussion with the autho=
rs of
   "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] to
   determine if DLEP will fullfil the needs that ModemLPA is targeted
   at.  DLEP is currently a client/server session oriented protocol that
   provides link layer information to directly connected devices -
   generally routers.  The Modem Link Property Advertisment protocol
   broadcasts link status notifications to directly-attached devices and
   devices or applications that may be multiple hops away from the modem
   (or other sending device).

   It should be possible to use the DLEP message formats without all the
   signalling required for the DLEP client/server session to perform the
   functions addressed in this draft.  The modem would simply provide
   link states out via multicast or unicast UDP datagrams (DLEP-Lite).
   Whether or not this is a good idea, or acceptable to the manet group,
   is yet to be determined.
In the mean time, This modemLPA docum=
ent was originally submitted to the IRTF mobopts research group a=
s an individual submission draft-ivancic-mobopts-modemlpa-01.  That researc=
h group as recently closed down.  I am looking for a new place to put updat=
es until a decision is made on DLEP-Lite. Is the manet group the right plac=
e?  I really don't know if this is the right group or if someplace else may=
 be more appropriate.  I see no other working groups or research groups rea=
lly looking at layer-2 triggers. 

Finally:
A PERL script, modem-LPA-pa= cketgen.pl, has been placed in sourceforge as open source software. The PERL script generates modemLPA packets base on the modem link property advertisement draft, "draft-ivancic-mobopts-modemlpa-01". =20 The script was used to demonstrate modemLPA by controlling the rate on a file transfer protocol. The file transfer protocol used was Saratoga and is implemented in a PERL script. The Saratoga PERL script is available on SourceForge. Search for saratoga and the script will be in the directory saratoga-v1-perl. This script and the Saratoga implementation currently use a multicast address of 226.1.1.2. The all routers address of 224.0.0.2 is suppose to be used, but the particular Linux machines we where running on did not want to pass 224.0.0.2 and we did not have sufficient time to determine why. Eventually, we hope to include code for GNU radios that implement modemLPA (Or perhap DLEP-lite). Code is available for modemLPA from http://sourceforge= .net/projects/modemlpa/ Code is available for Saratoga from http://= saratoga.cvs.sourceforge.net/viewvc/saratoga/

=
I am currently planning on attending the IETF meetings in Atlanta.
- Will Ivancic

= --_000_3416819E11884AE9945484421FF65A9Fnasagov_-- From charliep@computer.org Mon Oct 22 12:47:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB28311E80A5 for ; Mon, 22 Oct 2012 12:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-2.357, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_46=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmfbfOreP9yN for ; Mon, 22 Oct 2012 12:46:57 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B971711E8097 for ; Mon, 22 Oct 2012 12:46:55 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TQNxe-000308-R7; Mon, 22 Oct 2012 15:46:55 -0400 Message-ID: <5085A2AD.7000301@computer.org> Date: Mon, 22 Oct 2012 12:46:53 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad860047f54fa082bb508e633091d7b76c17350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet@ietf.org Subject: Re: [manet] DYMO review comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:47:00 -0000 Hello Thomas, Thanks for the detailed review, and please excuse the long delay. I'm on it now. Many of these points are already fixed in the new draft, but some of the important points require more time than I can spend on it today. On 7/28/2010 11:07 AM, Thomas Heide Clausen wrote: > General comments: > > oI found the document rather hard to read, in part due to the > terminology used. > The Terminology section states that it uses "some terminology from > [RFC5444]", > but is not explicit as to what. RFC5444 defines terms such as > packet/message, > both of which are used in this document in (I think) manners > inconsistent with > their definitions in RFC5444. I'll point out a couple of examples of > this in the > below, but the terminology use should be cleaned up through the document > to be consistent with RFC5444. I think that as RFC5444 and this document > are both products of the MANET wg, and that this document uses RFC5444, > then the terminology should be perfectly aligned with the terminology from > RFC5444 (I have not seen overruling reasons otherwise in the document). Agreed. I have started to do this. > oThere is an awful lot of places where different terminology is used for > the same > concept, e.g. "target" vs. "destination" and "source" vs. "originator" > etc. Unless > these are truly different concepts, then I would suggest consistency so > as to > make the text easier to read and less ambiguous. This will require another rigorous proofreading after today's submission of the reorganized draft, but I do fully agree with your point. > oI find the use of "node" unfortunate. I would much prefer "router", as > this is a > protocol running between routers. This applies both in the text and in the > "terminology mnemonics". I note that the text sometimes uses "router" and > sometimes "node", and it is not clear that/if there is a difference, or > if there > should be a difference. The difference is that AODVv2 routers are allowed to route on behalf of other nodes that are not AODVv2 routers. This point of confusion has been observed by others, and I intend to make it perfectly clear ASAP. > > oI have a general concern about how DYMO imposes constraints on RFC5444 > usage, > which precludes co-existence with other RFC5444 protocols running on the > same > device. I detail this below, but I think that this is an issue that > needs to be resolved. It certainly is not intended to preclude other RFC5444 protocols from running. I have already cleared up this language in a number of places in the draft. Typically, language has to be changed from "discarding a packet" to "ignoring a message". > oIn a great many places, it is stated "IP address of the node sending > the message". > If a router has multiple interfaces, and/or if these interfaces have > multiple addresses, > which of these (any? one matching the interface over which the message > is sent?) > should be used? I'm not pointing this out explicitly in the detailed > review below, it is > a general comment which applies too often through the document. Generally, the IP address would mean that of the sending interface. If an interface has several addresses, then I expect that the choice may not matter very much. If there are cases where the choice does matter, then I need to figure out how to insure that the choice is done interoperably. > oFinally, I have a very simple mind, and I like bullet-point-pseudocode > over > "textual pseudocode". E.g something like this is more readable to me: > > Upon receiving an RREQ, a router: > 1.Record X; > 2.Record Y; > 3.If z then: > oDo FOO; > otherwise: > oDo BAR; > 4.Retransmit the RREQ > This is, of course, a personal preference / stylistic preference, but it > is hardish to follow > the flow of the algorithm as it is currently written. I also prefer bullet point oriented explanations in most cases where there are more than three points, and even quite often when there are only two. I have made several changes along that direction in the draft. > >> Abstract >> >> The Dynamic MANET On-demand (DYMO) routing protocol is intended for >> use by mobile routers in wireless, multihop networks. DYMO >> determines unicast routes among DYMO routers within the network in an >> on-demand fashion, offering improved convergence in dynamic >> topologies. >> > "Improved convergence in dynamic topologies" - improved over what? Well, presumably, over other routing protocols that may suffer from performance issues in the realm of applicability ascribed to reactive protocols. Should that be added to the abstract? > >> 1. Overview >> >> The Dynamic MANET On-demand (DYMO) routing protocol enables reactive, >> multihop unicast routing among participating DYMO routers. The basic >> operations of the DYMO protocol are route discovery and route >> maintenance. >> > > > The document uses the terms "on-demand fashion" in the abstract, > and "reactive" in the Introduction; these are not described. Are they > terms representing the same or different concepts? If the same, I > suggest consistency, otherwise I suggest clarification. Hmmm... I will add a definition for "reactive" so that it is specified to mean the same thing as "on-demand". I think the latter has a more intuitive meaning, but the former works better grammatically in most places. >> During route discovery, the originator's DYMO router initiates >> dissemination > > "dissemination" merits being elaborated; I believe that "flooding" is a > more commonly used term in [manet]. Is this the same, or a different, > concept? If different, this needs to be elaborated (*how* is the > information disseminated?") This is a good point. I will replace "dissemination" by flooding. Perhaps "disseminate" sounds less "brute force" than "flood". And anyway it needs to be emphasized that AODVv2 can use better techniques than brute force for the flooding operation. This was also true for AODV, but most people seemed to assume that brute force flooding was required when it was not. > >> of a Route Request (RREQ) throughout the network to >> find a route to the target's DYMO router. > Couple of questions here: > > o"target", is that what is commonly referred to as "destination", e.g. > in IP > headers or elsewhere? In most cases, "target" is the same as "destination", but there may be a few cases where it is different. I need to carefully check all occurrences. > o"target", I would assume that that's a "host", see issue below? > > o"target's DYMO router" - should this be read as to indicate that a > given host > (destination for data traffic) is connected to one and only one DYMO > router, > i.e. that hosts can not be "multi-homed" to different DYMO routers? If > so, then > this merits being called out in the "applicability statement" section. That is a good point. My belief is that multi-homing would work just fine, but that needs to be checked. In the meantime, I have placed the following sentence in the Applicability section: Any such node which is not itself an AODVv2 router SHOULD NOT be served by more than one AODVv2 router. This should also be inserted as an issue in the Issue Tracker. > >> During this hop-by-hop >> dissemination process, > It is not clear what a "hop-by-hop dissemination process" is at this > point. I assume that it is some sort of "flooding, but with selective > relaying other than for coverage", but it is not clear if this is the case. Well, all flooding is hop-by-hop. There are of course cases where an AODVv2 router may determine not to retransmit. >> each intermediate DYMO router records a route >> to the originator. When the target's DYMO router receives the RREQ, >> it responds with a Route Reply (RREP) sent hop-by-hop > "sent hop-by-hop" - how is this different from "dissemination" and > "hop-by-hop dissemination"? >> toward the >> originator. > ois this relative to the "originator address" from RFC5444? > ois this the "originator" of the RREP or the RREQ? The originator is the IP address of the node that triggered the creation of the RteMsg. RREPs are sent hop by hop but (typically) not flooded. I think the intention is to mention that RREPs are processed at every intermediate AODVv2 router. > >> Each intermediate DYMO router that receives the RREP >> creates a route to the target, and then the RREP is unicast hop-by- >> hop toward the originator. > Above, the RREP was "sent hop-by-hop", here it is "unicast hop-by-hop". > Same or different thing? Yes, it's the same. I changed "sent" to "unicast". > >> When the originator's > Of what? >> DYMO router >> receives the RREP, routes have then been established between the >> originating DYMO router and the target DYMO router in both >> directions. > Just a question: does DYMO create symmetric routes? It is said later > that DYMO must use bidirectional links. AODVv2 is not constrained to create symmetric routes, but in practice given the operation of RREQ and RREP, the routes will be symmetric. >> Route maintenance consists of two operations. In order to preserve >> routes in use, DYMO routers extend route lifetimes upon successfully >> forwarding a packet. In order to react to changes in the network >> topology, DYMO routers monitor routes over which traffic is flowing. > What does it mean for a router to "monitor routes"? >> When a data packet is received for forwarding and a route for the >> destination is not known or the route is broken, then the DYMO router >> of the source of the packet is notified. A Route Error (RERR) is >> sent toward the packet source to indicate the route to that >> particular destination > destination or target? >> is invalid or missing. Here, destination seems proper. > I would suggest to be more specific on the "route to that particular > destination is missing"; is that not the same as "there is no entry in > the routing table, matching the address of the destination". Yes, that is the same. But a route table entry can be marked as Broken. > This, > obviously, then raises the question of how this is done in case there're > network entries (i.e. non-host routes) matching the destination address > -- the pathological example is, what happens if the routing table has a > default route? This is a good point. Perhaps the prudent thing for now is simply to make all UnreachableNode addresses to be host addresses and not allow the Prefix to be added. >> When the source's DYMO >> router receives the RERR, it deletes the route. If this source's >> DYMO router later receives a packet for forwarding to the same >> destination, it will need to perform route discovery again for that >> destination. > > Is there any functional difference here between a packet for a new > destination (i.e. for a destination for which no previous route was > installed) or destination which has been "deleted" due to an RERR? Right now nothing comes to mind. >> 2. Applicability Statement > I think that the applicability statement should call out if/that > multi-homed hosts are supported, as described above. I also believe that > the applicability statement should call out some of the security > questions that I raise later below. Also, the requirement that DYMO > routers have persistent story available (5.1.4) should be called out > here, as some (smaller) platforms do not have persistent storage > (outside of that which requires flashing the device....) I have added a statement about multihoming. For security, I think it is appropriate to make a cross reference to the Security Considerations. In that section, additional restrictions due to security requirements would properly be included. The mandate for persistent storage is "SHOULD". For devices that do not have persistent storage, some performance degradation might be experienced when the procedures for recovering from lost SeqNum have to be followed. I think that is a reasonable formulation of the requirement. >> The DYMO routing protocol is designed for stub or disconnected mobile >> ad hoc networks (MANETs). DYMO handles a wide variety of mobility >> patterns by dynamically determining routes on-demand. DYMO also >> handles a wide variety of traffic patterns. > > Can this (wide variety of mobility patterns, traffic patterns) be > quantified somewhat? I can be a little more specific but I do not have the numbers. >> In networks with a large >> number of routers, DYMO is best suited for sparse traffic scenarios >> where routers forward packets to only a small portion of the other >> DYMO routers, due to the reactive nature of route discovery and route >> maintenance. > > Reactive vs. on-demand -- in same paragraph here, so I assume that they > are different? No, as above they should be treated as having the same meaning. >> DYMO is applicable to memory constrained devices, since little >> routing state is maintained in each DYMO router. Only routing >> information related to active sources and destinations is maintained, >> in contrast to most other more proactive routing protocols that >> require routing information to all routers within the routing region >> be maintained. > It is not immediately clear: back-of-the-napkin math suggests that if a > DYMO network would need to maintain routes between all possible > communicating pairs in the network, then this would actually require > more state than a pure link-state protocol. Thus, I would suggest that > this be somewhat rephrased. I will add more clarification. > >> DYMO supports routers with multiple interfaces participating in the >> MANET. DYMO routers can also perform routing on behalf of other >> nodes, attached via participating or non-participating interfaces. > The first paragraph of the applicability statement states that only stub > networks are supported, I would assume that "nodes" in the above should > be "hosts", as otherwise it'd be a potential transit network? Yes, that is correct. I have added that clarification. > >> DYMO routers perform route discovery to find a route to a particular >> destination. Therefore, DYMO routers MUST be configured to initiate >> and respond to route discovery on behalf of certain nodes, identified >> by address. > I do not understand the "respond to route discovery on behalf of certain > nodes, identified by address", is it not rather that "Each DYMO router > must be configured to respond to RREQs for a certain set of addresses"? I have used your proposed text. >> When DYMO is the only protocol interacting with the >> forwarding table, DYMO MAY be configured to perform route discovery >> for all unknown unicast destinations. >> At any time within a DYMO routing region only one DYMO router SHOULD >> be responsible for, i.e. "own", a particular address. >> Coordination >> among multiple DYMO routers to distribute routing information >> correctly for a shared address (i.e. an address that is advertised >> and can be reached via multiple DYMO routers) is not described in >> this document. The router behavior for shifting responsibility for >> an address from one DYMO router to another are described in >> Appendix A. >> > I.e. multi-homing explicitly prohibited. I wonder if it is reasonable > for the protocol to have this restriction. > > Is the following configuration supported: a subset of routers have two > wireless interfaces, operating on distinct frequencies and being > "participating interfaces". An "edge networks" (an Ethernet with hosts, > say) connects to the MANET by way of two gateways, each of which having > one "participating interface", and with the two gateways' "participating > interface"'s being on each of the two distinct frequencies so as to > allow the "edge network" to connect via either frequency? > > (A banalized example, consider a vehicle with an on-board Ethernet, and > two "routers", one WiMax and the other DRC, and with road-side > infrastructure routers having both WiFi an WiMax interfaces on the same > routers). > > I do not think that the above is a particularly exotic situation, so I > think it should be supported - if not, it should be spelled out very > clearly. I should say that I went back and loo >> DYMO MUST only utilizes bidirectional links. > How're those identified? Well, for various technologies, that is done at layer 2. Generally, AODVv2 attempts to avoid unidirectional links by using the blacklist mechanism. >> In the case of possible >> unidirectional links, either blacklists ( see Section 7.2) or other >> means (e.g. adjacency establishment with only neighboring routers >> that have bidirectional communication as indicated by NHDP >> [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality >> SHOULD be used. Otherwise, persistent packet loss may occur. >> >> The routing algorithm in DYMO may be operated at layers other than >> the network layer, using layer-appropriate addresses. For operation >> at other layers DYMO's routing algorithm likely will > "Likely"? I reworded this. > > I am wondering if it is appropriate to call this sort of stuff out in an > IETF specification, considering that the IETF is not in the business of > standardizing L2's? Check. I would be O.K. to delete it, but I don't think it's normative, and I don't think it's hurting anything. > >> not need to >> change. Although, modification of the packet/message format may be >> required. >> >> >> 3. Terminology >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > There's an errata to 2119, "NOT RECOMMENDED" is missing in the above. Good catch! > >> document are to be interpreted as described in [RFC2119]. >> >> Additionally, this document uses some terminology from [RFC5444]. > > As stated in the beginning, I think it would be helpful to call out > which parts of the terminology from 5444 is imported here, in particular > as a large fraction of the 5444-defined terminology is used differently > in this document than in 5444. That should not happen. I will fix it, even if I cannot get it done today. >> This document defines the following terminology: >> >> Adjacency >> A relationship between selected bi-directional neighboring routers >> for the purpose of exchanging routing information. Not every pair >> of neighboring routers become adjacent. Neighboring routers may >> form an adjacency based several different pieces of information or >> protocols; for example, exchange of DYMO routing messages, other >> protocols (e.g. NDP [RFC4861] or NHDP [I-D.ietf-manet-nhdp]), or >> manual configuration. Similarly, loss of a routing adjacency may >> also be based upon several pieces of information, and monitoring >> of adjacencies where packets are being forwarded is required (see >> Section 5.5.1). > > Two issues: > > oAdjacency is an already well-established term in OSPF, is the use of > this term > in this document identical hereto, or is this a re-definition? Would it be better to make a normative reference to OSPF in order to have a specification for this definition? To my understanding, without going back and reviewing OSPF just now, the meaning is the same. > oThe definition above leaves me confused as to what an adjacency is; I > am not > sure how, for example, 4861 or NHDP forms adjacencies; NHDP discovers bi- > directional neighbors (all of them), whereas in the above an "adjacency" > explicitly is not formed with *all* bi-directional neighbors. >> Distance (Dist) >> A metric of the distance a message or piece of information has > "piece of information", can this be more specific? I assume that to be > information contained in messages, and thus that this is somewhat redundant? >> traversed. The minimum value of distance is the number of IP hops >> traversed. The maximum value is 65,535. >> > "Routing message" and "DYMO protocol message", what is the difference? > Are they the same or different things? Routing message is RteMsg, but I need to check if there are instances whether RERR is also included. > > Also, what does it mean to "attend to messages"? "Receive", "process", > "forward", "drop" and "generate", I can understand relatively well, but > "attend to" is new....while we're at this point, on occasion the > document states "handle the message" -- I am not sure which subset of > receive/process/forward/drop/generate that describes. I think the original intention was "process", but I have reworded the places in the draft to avoid using "attend". >> DYMO Sequence Number (SeqNum) >> A DYMO Sequence Number is maintained by each DYMO router process. >> This sequence number is used by other DYMO routers to identify the >> temporal order of routing information generated and ensure loop- >> free routes. >> >> Forwarding Route >> A route that is used to forward data packets. Forwarding routes >> are generally maintained in a forwarding information base (FIB) or >> the kernel forwarding/routing table. >> > > Suggest "forwarding/routing table of the underlying operating system" I think the draft is fine without this definition anyway. I hope that is O.K. >> Multihop-capable Unicast IP Address >> A multihop-capable unicast IP address is a unicast IP address that >> when put into the IP.SourceAddress or IP.DestinationAddress field >> is scoped sufficiently to be forwarded by a router. For example, >> site-scoped or globally-scoped unicast IP addresses. >> > Isn't this just a long-winded way to say "any non-link-local uni-cast > address" ? Yes, and I have reworded this passage. >> Originating Node (OrigNode) >> The originating node is the source, its DYMO router creates a DYMO >> control message on its behalf in an effort to disseminate some >> routing information. The originating node is also referred to as >> a particular message's originator. > Wait, "the originating node is the source" seems wrong. If both terms > are used through the document (and I think they are), then I suggest > selecting one, and being consistent about the matter. > > I think, however, that there is (in places) a slight subtelty, where > "originator" or "originating node" implies "the router issuing DYMO > RREQs" whereas the "source" is the source IP address of an IP unicast > datagram containing user data. This issue managed to get me confused > numerous times through the document, and it would be very very helpful > to do a through cleanup of this matter. The originating node address is used as part of the payload in some packets where it is not the IP source address of packet. Trying to find the clearest language to express this has been tricky. I'll try to make some alternate suggestion. > > >> Route Error (RERR) >> A RERR message is used to indicate that a DYMO router does not >> have a forwarding route to one or more particular addresses. >> >> Route Reply (RREP) >> A RREP message is used to disseminate routing information about >> the RREP OrigNode to the RREP TargetNode and the DYMO routers >> between them. >> >> Route Request (RREQ) >> A RREQ message is issued to discover a valid route to a particular >> destination address, called the RREQ TargetNode. When a DYMO >> router processes a RREQ, it learns routing information on how to >> reach the RREQ OrigNode. >> >> Target Node (TargetNode) >> The TargetNode is the ultimate destination of a message. >> >> This Node (ThisNode) >> ThisNode corresponds to the DYMO router process currently >> performing a calculation or attending to a message. > > So "Node corresponds to DYMO router" - just use router in place of node > and be done with it. The intention is to have "ThisNode" as a way to reference the particular AODVv2 router currently dealing with the mssage even when other router addresses need to be discussed. I also feel the terminology is stilted, but I don't have a better suggestion just at the moment. >> 4.1. Route Table Entry >> >> The route table entry is a conceptual data structure. >> Implementations may use any internal representation that conforms to >> the semantics of a route as specified in this document. > > I am not sure what "semantics of a route" means. I think you mean to say > that an implementation may use any internal representation, so long as > it provides access to the same information as specified in the below. Thanks, I used your formulation and eliminated "semantics". >> Conceptually, a route table entry has the following fields: >> > >> Route.NextHopAddress >> The IP address of the adjacent DYMO router on the path toward the >> Route.Address. >> > Is that any IP addresses of the adjacent DYMO router, or the IP address > of a specific interface on the DYMO router? It is the IP address that ThisNode believes serves as the next hop. This question has been raised by others. I think the language is pretty clear, but I will change "The IP address" to "An IP address" >> Route.NextHopInterface >> The interface used to send packets toward the Route.Address. >> >> Route.Forwarding >> A flag indicating whether this Route can be used for forwarding >> data packets. This flag MAY be provided for management and >> monitoring. >> >> Route.Broken >> A flag indicating whether this Route is broken. This flag is set >> to true if the next-hop becomes unreachable or in response to >> attending to a RERR (see Section 5.5.4). >> > If I understand it right, then if Route.Forwarding and Route.Broken > are inverse, i.e. if one is set the other is cleared. Which leaves the > question, why are there both? I have eliminated Route.Forwarding. Thanks for your suggestion. > Route.Broken I can understand -- Route.Forwarding is somewhat odd: what > would a route be used for if not forwarding data packets? > >> The following field is optional: >> >> Route.Dist >> A metric indicating the distance traversed before reaching the >> Route.Address node. >> >> Not including optional information may cause performance degradation, >> but it will not cause the protocol to operate incorrectly. > > I would suggest "...will not prohibit the protocol from discovering > valid routes"? Thanks, I have used your formulation. >> In addition to a route table data structure, each route table entry >> may have several timers associated with the information. These >> timers/timeouts are discussed in Section 5.2.3. >> > As this section describes the conceptual data structures, I would prefer > to have also the timers presented in this section, to minimize the > flipping through the document. Let's discuss this further. I am O.K. to do this, but I need to study it to make sure. >> 4.2. DYMO Messages >> >> When describing DYMO protocol messages, it is necessary to refer to >> fields in several distinct parts of the overall packet. These >> locations include the IP header, the UDP header, and fields from >> [RFC5444]. This document uses the following notation conventions. >> > > This is where I think the confusion with 5444 terminology manifests > itself. If 5444 is used, then a "message" is a well-defined entity, > which is part of a "packet" and possibly contained in an "IP datagram". > A DYMO protocol message should, thus, be an instance of a 5444 message > and described as such. I agree that the terminology needs to be clarified in many places. >> >> Information found in the table. > I believe that the above sentence is orphaned? I fixed that, thanks. > >> +---------------------------+-------------------+ >> | Information Location | Notational Prefix | >> +---------------------------+-------------------+ >> | IP header | IP. | >> | UDP header | UDP. | >> | RFC5444 message header | MsgHdr. | >> | RFC5444 message TLV | MsgTLV. | >> | RFC5444 address blocks | AddBlk. | >> | RFC5444 address block TLV | AddTLV. | >> +---------------------------+-------------------+ >> >> Table 1 >> > I am also a little worried about the IP. and, especially, UDP. > notations, specifically if the subsequent processing is transport > dependent. I would suggest that a brief section should allow factoring > this out, and that the remainder of the spec be transport independent > (i.e. you could run this over ICMP, for example, if desired?) I > understand that somewhere it needs to be said that "DYMO control > messages can be sent either using the ' manet' protocol number or the > 'manet' UDP well-known port number, as specified in [RFC5498].", but and > that we can assume to have IP somewhere, of course, for addresses - but > beyond that I think it should be factorable. Here I am not very sure. The first thing will be to make the RFC5444 terminology correspond correctly to RFC 5444. Getting rid of "IP." and "UDP." could have some downsides in the rest of the specification. I'm not yet visualizing the refactored document structure -- if you have a more concrete suggestion that would be appreciated. > >> 4.2.1. Generalized Packet and Message Structure >> >> DYMO messages conform to the generalized packet and message format as >> described in [RFC5444]. Here is a brief description of the format. >> A packet is made up of messages. A message is made up of a message >> header, message TLV block, and zero or more address blocks. Each of >> the address blocks may also have an associated address TLV block. >> >> For interoperability with other DYMO routers, all DYMO messages >> specified in this document SHOULD sent using the IP protocol number >> (138) reserved for manet protocols [RFC5498]; or the UDP destination >> port (269) reserved for manet protocols [RFC5498] and IP protocol >> number for UDP. >> >> Most DYMO messages are sent with the IP destination address set to >> the link-local multicast address LL-MANET-Routers [RFC5498] unless >> otherwise stated. Therefore, all DYMO routers SHOULD subscribe to >> LL-MANET-Routers [RFC5498] for receiving control packets. Note that >> multicast packets MAY be sent via unicast. For example, this may >> occur for certain link-types (non broadcast mediums), improved >> robustness, or manually configured router adjacencies. >> > Suggest that the above two paragraphs be factored out, along with the > comment above, to a separate section (possibly top-level) somewhere. If not here, then the information could be instead presented at the end of the "Overview" section. Another alternative would be a short section after the Applicability section. >> Unicast DYMO messages (e.g. RREP) unless otherwise specified in this >> document are sent with the IP destination set to the >> Route.NextHopAddress of the route to the TargetNode. >> >> The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO >> messages is set to 255. If a packet is received with a value other >> than 255, it is discarded. This mechanism helps to ensures that >> packets have not passed through any intermediate routers, and it is >> known as GTSM [RFC5082]. > There is an issue here, regarding co-existance of different protocols > using RFC5444 on the same router. "Piggybacking" multiple messages (5444 > sense) from different protocols into the same packet (5444 sense) is a > core feature that should be supported; e.g. for running NHDP and DYMO on > the same router and take advantage of piggybagging of HELLOs and RREQs > (for example) into the same transmission. > > Making a requirement from DYMO that the IP header fields have specific > values effectively prohibits coexistence with other protocols if these > make contradictory such requirements -- and is a layer violation. DYMO > should, in order to employ RFC5444 appropriately and so as to not > preclude coexistence among protocols, be concerned only with messages > (again, RFC5444) and their header and payload fields. > > Imposing this constraint effectively precludes other protocols from > co-existing on a router where DYMO is running. > > I feel rather strongly about this point, as a lot of the exercise of > RFC5498 and RFC5444 was to, exactly, ensure correct and efficient > co-existence of multiple protocols or protocol instances on the same > router, and I would want to see this addressed - it's a deal-breaker to > get this right. I notice that a lot of this was brought on by RFC5498, > of which one of the authors of DYMO is author. Yes, Ulrich has pointed this out. To fully enable the piggybacking in the general case would preclude the use of GTSM. I'd prefer to get some more feedback from the working group about whether or not the piggybacking is worth the loss of whatever improvement GTSM can offer. I am O.K. either way, but if there is experience showing that the piggybacking offers improvement in real life I would prefer to enable the better performance. ... >> or to >> improve performance by using jitter [RFC5148]. > I would surmise that this is by way of reducing collisions, and could be > stated explicitly. >> DYMO control packets SHOULD be given priority queuing and channel >> access. > > What is a DYMO control packet? A DYMO control message? A Routing Message? This was supposed to have the conventional meaning. I've reworded it. >> AddBlk.TargetNode.Address >> The IP address of the message TargetNode. In a RREQ the >> TargetNode is the destination address for which route discovery is >> being performed. In a RREP the TargetNode is the RREQ OrigNode >> address. The TargetNode address is the first address in a routing >> message. > "The IP address of the message TargetNode" - TargetNode is defined to be > a "node", not a message. Fixed. >> >> AddBlk.AdditionalNode.Address >> The IP address of an additional node that can be reached via the >> DYMO router adding this information. Each AdditionalNode.Address >> MUST include its prefix. Each AdditionalNode.Address MUST also >> have an associated Node.SeqNum in the address TLV block. >> > What is an "additional node that can be reached via the DYMO router > adding this information"? This was essentially inherited from DSR and is a way to include source route information in an RREP. I have moved this functionality into a new section for "Optional Features". >> IP.DestinationAddress >> For multicast RERR messages, The IP address is set to LL-MANET- > The -> the >> Routers [RFC5498]. For unicast RERR messages, the IP address is >> set to the NextHopAddress. Fixed. >> >> IP.ProtocolNumber and UDP.DestinationPort >> The IP Protocol Number 138 (manet) has been reserved for MANET >> protocols [RFC5498]. In addition to using this IP protocol >> number, DYMO may use the UDP port 269 (manet) [RFC5498] in >> conjunction with the IP Protocol Number 17 (UDP). > Suggest factoring this to a separate section, as indicated above. > > >> Example IPv4 RERR >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> IP Header >> +-+-+-+-+-+-+-+-+ >> | IP.Proto = UDP| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IP.SourceAddress | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IP.DestinationAddress = LL-MANET-Routers | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IP.TTL/HopLimit = 255 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> UDP Header >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Destination Port = manet | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Message Header >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | RERR-type |0|1|0|0| MAL=3 | msg-size=15 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | msg-hoplimit | >> +-+-+-+-+-+-+-+-+ >> Message TLV Block >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | msg-tlv-block-size=0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Message Body - Address Block >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |Number Addrs=1 |0|0|0|0|0| Rsv | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | UnreachableNode.Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Message Body - Address Block TLV Block >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV-blk-size=0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 2 > I will take this issue here, although I think it applies elsewhere. This > too is an RFC5444-usage-issue, and I think it's a very very important > one too. > > For extensibility reasons, any address in an address block should / is > recommended to be associated with an address block TLV, indicating its > usage. Doing so enables internal extensibility (a protocol extension can > add addresses and associated TLVs to a DYMO message, without a stock > DYMO thinking that it should affix semantics to the address), not doing > so leads to a design with very limited extensibility. > > I would recommend thinking about it this way: just as message types > allow "handing off incoming messages to the appropriate protocol > implementations and indicate large-scale processing", address-block TLVs > allows to specify "which specific processing action for which specific > address" to undertake by a protocol. Thinking about it this way, the > logical conclusion for an address without an associated TLV is "don't > process at all". > > Unless you are absolutely certain (and can convincingly argue so) that > there never will be a need to for protocol extensions, I would recommend > that the above be applied through all DYMO control messages in a > systematic fashion. Ooof. I can't do that before the submission deadline of today. I'll try to have this done before the IETF meeting and make a report. > >> 5.1.3. OwnSeqNum Rollover >> >> Incrementing an OwnSeqNum whose value is the largest largest possible >> number representable as a 16-bit unsigned integer (i.e., 65,535), >> SHOULD be set to one (1). In other words, the sequence number after >> 65,535 is 1. >> > Generally, when such wrap-around happens, I worry if there are any > transient situations that can happen. A router receiving a message with > seq# 65000, then a message with seq# 30000, does it assume that this > message is old, or is wrapped-around (and that messages in between > 65000->1->39999 have been lost? I think that specifying the arithmetic operation as signed 16-bit was intended to make this precise. Since 65000 - 30000 is > 0, the router would assume the #30000 message was old, and that it had not received messages #30000-#64999. That doesn't mean the messages were lost. > > I would like to see this specified explicitly (and if it is not a > problem either way, I'd like to see why). Here seems the good place to > do so. What do you think about signed arithmetic? >> 5.1.4. Actions After OwnSeqNum Loss >> >> A DYMO router SHOULD maintain its sequence number in persistent >> storage. > I would suggest that this should be stated in the "Applicability > Statement", that "Proper operation of DYMO requires that routers have > persistent storage available", as this seems to be a notable condition > for those wanting to deploy an ad hoc network on hardware which may not > have persistent storage, available outside of a flashing-process (such > as e.g. embedded devices). This was answered above. However, I added language to the Applicability statement to explain why persistent storage would be useful. > >> If a DYMO router's OwnSeqNum is lost, it MUST take certain actions to >> avoid creating routing loops. To prevent this possibility after >> OwnSeqNum loss a DYMO router MUST wait for at least >> ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing >> protocol. If a DYMO control message is received during this waiting >> period, the DYMO router SHOULD handle it normally but MUST NOT > "handle it" - previously it was called "attend to"; suggest being > specific, especially..... Done. >> transmit or retransmit any DYMO messages. If a data packet is > .....it is allowed to receive and process DYMO messages, but it is not > allowed to forward and generate DYMO messages. >> received for forwarding to another destination during this waiting >> period, the DYMO router MUST generate a RERR message > And here is the contradiction, as it is said above that it "...MUST NOT > transmit .... any DYMO message" -- and here, it is "MUST generate a RERR > message" [I assume that the RERR is also transmitted, otherwise > generating it would be useless]. It appears that there is an internal > contradiction in the specification at this point. Fixed. > > I note the terminology issue between "generate" and "transmit" here, > which should be consistent if they are the same, appear in terminology > if they are different. Here the meaning is the same, so I used "transmit" instead. >> 5.2.2. Creating or Updating a Route Table Entry with Received Superior >> Routing Information >> >> The route table entry is populated with the following information: >> >> 1. the Route.Address is set to Node.Address, >> >> 2. the Route.Prefix is set to the Node.Prefix. >> >> 3. the Route.SeqNum is set to the Node.SeqNum, >> >> 4. the Route.NextHopAddress is set to the node that transmitted this >> DYMO RM packet (i.e., the IP.SourceAddress), >> > "The node that transmitted this DYMO RM packet" -- originally, or the > last retransmitter? Applies in multiple places. I inserted "last". I didn't find the other places though. >> 5. the Route.NextHopInterface is set to the interface that this DYMO >> packet was received on, >> >> 6. the Route.Broken flag is set to false, >> >> 7. if known, the Route.Dist is set to the Node.Dist, >> >> Fields without known values are not populated with any value. >> > So in that case, what is their value? How is it identified, upon reading > an entry, if it is "populated with a value" or not? Generally, when > allocating a data structure, it is preferential to have known default > values for all fields, so as to be able to determine this. I was also puzzled by this, and it was mentioned by others. It would be better for all fields to be populated by default values. I will make this change, even if I don't find every instance before today's draft submission deadline. >> The timer for the minimum delete timeout (ROUTE_AGE_MIN) is set to >> ROUTE_AGE_MIN_TIMEOUT. The timer for the maximum delete timeout >> (ROUTE_SEQNUM_AGE_MAX) is set to Node.AddTLV.VALIDITY_TIME [RFC5497] >> if included; otherwise, ROUTE_SEQNUM_AGE_MAX is set to >> ROUTE_SEQNUM_AGE_MAX_TIMEOUT. The usage of these timers and others >> are described in Section 5.2.3. >> >> At this point, a forwarding route has been created and the >> Route.Forwarding flag set. Afterward, the route can be used to send >> any queued data packets and forward any incoming data packets for >> > This is the only occurrence of "queued data packets" in the > specification - it is called "buffered" below in 5.4. Fixed. >> Route.Address. This route also fulfills any outstanding route >> discovery attempts for Node.Address. >> >> >> >> 5.3.2. RREP Creation >> >> First, the AddBlk.TargetNode.Address is added to the RREP. The >> TargetNode is the ultimate destination of this RREP; the RREQ > Editorially, I think "ultimate destination" is a bit strange. We're used > to an IP datagram to be delivered to the destination (after which it is > no longer forwarded - or dropped), any intermediary is not the destination. I'll be on the lookout for better terminology, but at least it's not misleading. >> The IP.DestinationAddress for RREP is set to the IP address of the > See comments regarding "Layer Violation" above. Here is the tradeoff between packet size and message aggregation that needs to be considered. >> 5.3.4. RM Handling >> >> First, ThisNode examines the RM to ensure that it contains the >> required information: MsgHdr.HopLimit, AddBlk.TargetNode.Address, >> AddBlk.OrigNode.Address, and OrigNode.AddTLV.SeqNum. If the required >> information do not exist, the message is discarded and further >> processing stopped. >> >> Next, ThisNode decides whether to attend to this message. If the >> message contains a MsgTLV.DID it SHOULD match ThisNode.DID's value. >> If the message does not contain a MsgTLV.DID it is assumed to be zero >> (0) and SHOULD be discarded if ThisNode.DID's value is not zero (0). >> Next, ThisNode MAY selectively attend to messages based upon >> information in the message. ThisNode SHOULD only handle messages >> from adjacent DYMO routers. If ThisNode chooses not to handle this >> message, the message is discarded and further processing stopped. >> >> ThisNode checks if the AddBlk.OrigNode.Address is a valid multihop- >> capable (e.g. site or global scope) unicast address. If the address >> is not a valid unicast address, the message is discarded and further >> processing stopped. >> >> ThisNode also checks whether AddBlk.OrigNode.Address is an address >> handled by this DYMO router. If this node is the originating DYMO >> router, the RM is dropped. >> > > Is "dropped" different from "discarded and further processing stopped"? > Are messages forwarded in either of these cases? In those cases the messages are not forwarded. According to previous discussion, perhaps "ignored and not forwarded" is better than "dropped". >> If the routing information for an AdditionalNode.Address is not >> considered superior, then it is removed from the RM. Removing this >> information ensures that the information is not propagated. > I think that this is an important point to call out: RMs are thus, > presumably, mutable beyond well-known header fields while in transit - > yes? If so, I would suspect that this poses problems regarding > authentication and integrity verification for messages relayed with > mutated contend/payload - or, alternatively, a specific set of security > mechanisms are envisioned. In either case, this should be called out in > the security considerations section, possibly also applicability section > as it seems to preclude (some) deployments due to inability to properly > secure the protocol? Yes, mutable fields affect security algorithms for protocol messages. I believe this also requires discussion in the Security Considerations. It could be that some approaches to security would preclude mutability, and if that matters then the mutable fields should be specified to be optional so that the base protocol is not affected. > >> At this point, if the routing information for the OrigNode was not >> superior then this RM SHOULD be discarded and no further processing >> of this message SHOULD be performed. > Can it be forwarded? At the cost of additional useless network load, so I'd say not. >> If the ThisNode is the DYMO router responsible for the TargetNode and >> this RM is a RREQ, then ThisNode responds with a RREP to the RREQ >> OrigNode (the new RREP's TargetNode). The procedure for issuing a >> new RREP is described in Section 5.3.2. At this point, ThisNode need >> not perform any more operations for the RM being processed. >> >> As an alternative to issuing a RREP, ThisNode MAY choose to >> distribute routing information about ThisNode (the RREQ TargetNode) >> more widely. That is, ThisNode MAY optionally perform a route >> discovery; by issuing a RREQ with ThisNode listed as the TargetNode, >> using the procedure in Section 5.3.1. At this point, ThisNode need >> not perform any more operations for the RM being processed. > The above paragraph doesn't parse by me. It appears that a router is > trying to discover a path to itself, which should be trivial. I think > that the intent is that as RREQs also cause installation of routes, a > RREQ can be sent in place of a RREP; this begs the question of when one > would chose to do an RREP over an RREQ in response to an RREQ. If they > can be used indiscriminately, then one should be eliminated, if not then > it should be specified when each should be used. I think this was an attempt to enable broadcast/multicast RREP which was done for various reasons in the past. For one thing, it allows utilization of unidirectional components in the routing path. >> Some examples of why ThisNode might choose to not re-issue a RM are: >> if ThisNode does not want to advertise routing for the contained >> addresses because it is already heavily loaded; if ThisNode has >> already issued nearly identical routing information (e.g. ThisNode >> had recently issued a RM with nearly the same distance); > > And "nearly" is determined how? This is a good question. I will delete that word. But it is an interesting point to think about whether there are cases where small differences should be tolerated. This is especially true for other route metrics. >> Data packets awaiting a route SHOULD be buffered by the source's DYMO >> router. This buffer SHOULD have a fixed limited size >> (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES) and older data packets >> SHOULD be discarded first. >> >> Buffering of data packets can have both positive and negative >> effects, and therefore buffer settings (BUFFER_DURING_DISCOVERY) >> SHOULD be administratively configurable or intelligently controlled. >> > Maybe it is a decent idea to stipulate if intermediate routers are > allowed or discouraged from buffering traffic? Would you like to suggest some text? There are a lot of considerations, and anyway it only matters for intermediate route repair operations. > >> If a route discovery attempt has failed (i.e. an attempt or multiple >> attempts have been made without receiving a RREP) to find a route to >> the TargetNode, any data packets buffered for the corresponding >> TargetNode are dropped and a Destination Unreachable ICMP message >> SHOULD be delivered to the source. >> > Presumably, the source of the data packet(s)? Yes. I will make that clarification. >> 5.5.4. RERR Handling ... >> If any UnreachableNode was removed, all other information (AddTLVs) >> associated with the removed address(es) MUST also be removed. >> > Same issue as above; RERR are mutable in-transit (beyond their header > fields), which severely constrains the ability to secure the protocol, > and this should be called out explicitly in the security considerations > section. I guess that the security requirement for RERR is anyway a little less strict than, say, for RREP. >> 5.6. DYMO Identifier (DID) >> >> Each DYMO routing protocol process MUST have an associated DYMO >> Identifier (DID). The DID allows multiple DYMO routing protocol >> processes to operate over the same links and on the same device >> independently. This function may also be used to administratively >> separate DYMO processes with incompatible options, timers, or >> extensions. >> >> The DID is similar in function to OSPF Instance ID [RFC5340] >> [I-D.ietf-ospf-multi-instance], OSPF Area ID [RFC2328] [RFC5340], >> and/or the MANET_ID TLV [I-D.chakeres-manet-manetid]. > Do you intend to cite I-D.chakeres-manet-manetid? IIRC, it is expired > and hasn't been renewed in a while (in the References section, since 2008)? I have deleted this section. It seems to have no defenders. >> 5.7. Unknown Message & TLV Types >> >> If a message with an unknown type is received, the message is >> discarded. > This will, by definition, never happen. By definition because it is > explicitly specified in RFC5444 that a protocol only gets message types > which it "owns" and, hence, "knows". This relates closely to the general > relationship between this specification and RFC5444, which appears to be > not cleanly used. Sometimes things happen that protocol mandates should not happen, isn't that possible? Or did I misunderstand your point? >> For handling of messages that contain unknown TLV types, the default >> behavior is to leave the information in control messages unmodified. >> Although, this behavior (UNKNOWN_TYPES) MAY be administratively >> controlled. > And, this behavior would be universally applied for all unknown TLVs > arriving on a given router in a DYMO message. Notice that here the > document is potentially (if the default behavior for unknown types > becomes anything other than "ignore for processing, preserve for > forwarding") severely restricting ability for protocol extensions. > > Would STRONGLY recommend to not specify that this behavior can be > administratively controlled. O.K. I have deleted that sentence and the administrative knob. >> 5.9. Simple Internet Attachment >> >> Simple Internet attachment consists of a stub network of DYMO routers >> connected to the Internet via a single Internet DYMO router (IDR). >> >> DYMO routers, and hosts behind these routers, wishing to be reachable >> from hosts on the Internet MUST have IP addresses within the IDR's >> routable and topologically correct prefix (e.g. 192.0.2.0/24). >> >> The IDR is responsible for generating RREQ to find nodes within the >> DYMO Region on behalf of nodes on the Internet, as well as responding >> to route requests from the DYMO region on behalf of the nodes on the >> Internet. >> > But how does this work in the opposite direction? Will a DYMO router > have to maintain explicit entries for all hosts on the Internet, with > which it wishes to connect? Presumably an AODVv2 router would have routes to the Internet. If it gets an RREQ for an Internet address, it can "assume" that the TargetNode is reachable and send back an RREP for that node. The initial metric might be more than 1 for that target. > > It would appear (from the explanation below) to me that a "default > gateway" entry would not work, and is not used, because if one is > present in the routing table then -- by definition -- the routing table > would contain a prefix matching any IP Address, and so that indeed > explicit entries for all host on the Internet are required. It can be made to work, and if some small assumptions are made then it can work pretty well. You have a great deal of experience with this, I am sure, based on your position of chair of the [autoconf] working group. But certainly per-host explicit entries are not needed, and not scalable. >> 7. IANA Considerations >> >> In its default mode of operation, DYMO uses the UDP port MANET >> [RFC5498] to carry protocol packets. DYMO also uses the link-local >> multicast address LL-MANET-Routers [RFC5498]. >> >> This section specifies several message types, message tlv-types, and >> address tlv-types. >> > General comment: I believe that it should be called out, such that IANA > is instructed what to do, explicitly from which registries and intervals > the various TLV types should be allocated. Point noted. Work to do. >> DYMO Message Types >> >> +------------------------+----------+ >> | Name | Type | >> +------------------------+----------+ >> | Route Request (RREQ) | 10 - TBD | >> | Route Reply (RREP) | 11 - TBD | >> | Route Error (RERR) | 12 - TBD | >> +------------------------+----------+ >> >> Table 6 >> > > I direct the authors attention on RFC5444, section 6.4.1, wherein it says: > > 6.4.1. Message TLV Type Extension Registry Creation > > If a Message TLV Type is registered, then a new registry for type > extensions of that type must be created. A document that defines a > Message TLV Type MUST also specify the mechanism by which its type > extensions are allocated, from among those in [BCP26]. > > I therefore believe this section to be incomplete. Work to do. > >> 7.2. Message and Address Block TLV Type Specification >> >> Message TLV Types >> >> +-------------------+------+--------+-------------------------------+ >> | Name | Type | Length | Value | >> +-------------------+------+--------+-------------------------------+ >> | Unicast Response | 10 - | 0 | Indicates to the processing | >> | Request | TBD | octets | node that the previous hop | >> | | | | (IP.SourceAddress) expects a | >> | | | | unicast message within | >> | | | | UNICAST_MESSAGE_SENT_TIMEOUT. | >> | | | | Any unicast packet will serve | >> | | | | this purpose, and it MAY be | >> | | | | an ICMP REPLY message. If a | >> | | | | message is not sent, then the | >> | | | | previous hop can assume that | >> | | | | the link is unidirectional | >> | | | | and MAY blacklist the link to | >> | | | | this node. | >> +-------------------+------+--------+-------------------------------+ >> >> Table 7 >> >> >> >> >> > I direct the authors attention on RFC5444, section 6.5, wherein it says: > > Allocation policies for Message-Type-specific Address Block TLV Types > MUST be specified when creating the registry associated with the > containing Message Type, see Section 6.2.1. > > 6.5.1. Address Block TLV Type Extension Registry Creation > > When an Address Block TLV Type is registered, then a new registry for > type extensions of that type must be created. A document that > defines a Message TLV Type MUST also specify the mechanism by which > its type extensions are allocated, from among those in [BCP26]. > > > I therefore believe this section to be incomplete. > >> Chakeres & Perkins Expires January 11, 2011 [Page 36] >> >> Internet-Draft DYMO July 2010 >> >> >> 7.3. Address Block TLV Specification >> >> Address Block TLV Types >> >> +---------------+-----------+-----------+---------------------------+ >> | Name | Type | Length | Value | >> +---------------+-----------+-----------+---------------------------+ >> | DYMO | 9 - TBD | DID | ThisNode.DID's value. | >> | Identifier | | length | More information can be | >> | (DID) | | | found in Section 5.6 | > Is DID an Address Block TLV? Section 3 and elsewhere says otherwise. > >> | DYMO Sequence | 10 - TBD | up to 2 | The DYMO sequence num | >> | Number | | octets | associated with this | >> | (DYMOSeqNum) | | | address. The sequence | >> | | | | number may be the last | >> | | | | known sequence number. | >> | Distance | 11 - TBD | up to 2 | A metric of the distance | >> | | | octets | traversed by the | >> | | | | information associated | >> | | | | with this address. | >> | VALIDITY_TIME | TBD | | The maximum amount of | >> | | [RFC5497] | | time that information can | >> | | | | be maintained before | >> | | | | being deleted. The | >> | | | | VALIDITY_TIME TLV is | >> | | | | defined in [RFC5497]. | > > I would insist that VALIDITY_TIME is *not* "TBD" As RFC5497 defines this > already. Consequently, I think it should not be listed in the IANA > considerations section? O.K. I need to fix this. >> +---------------+-----------+-----------+---------------------------+ >> >> Table 8 >> >> >> 8. Security Considerations >> >> The objective of the DYMO protocol is for each router to communicate >> reachability information to addresses for which it is responsible. >> Positive routing information (i.e. a route exists) is distributed via >> RMs and negative routing information (i.e. a route does not exist) >> via RERRs. DYMO routers that handle these messages store the >> contained information to properly forward data packets, and they >> generally provide this information to other DYMO routers. >> >> This section does not mandate any specific security measures. >> Instead, this section describes various security considerations and >> potential avenues to secure DYMO routing. >> >> The most important security mechanisms for DYMO routing are >> integrity/authentication and confidentiality. >> >> In situations where routing information or router identity are >> suspect, integrity and authentication techniques SHOULD be applied to >> DYMO messages. In these situations, routing information that is >> distributed over multiple hops SHOULD also verify the integrity and >> identity of information based on originator of the routing >> information. > This is really difficult to do, in case messages are mutable in-transit, > which appears to be the case for RERR and RM's; i.e. for all DYMO > messages. For that reason, using SHOULD is - imo - dangerous here. Also, > for that reason, I think that this issue of mutable messages deserves > being called out explicitly in this section, especially if there are > known or recommended ways of handling this (as is the case, for example, > in the security considerations section of RFC5444 regarding the mutable > header fields for hop-count/hop-limit of messages. This is a highly nontrivial point, and I need to review various things about RFC 5444 that I have not looked at lately. Nevertheless, I didn't see how "SHOULD" would be "dangerous" in context (i.e., "In these situations"). -- Regards, Charlie P. From sratliff@cisco.com Mon Oct 22 13:02:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2F21F87AA for ; Mon, 22 Oct 2012 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVITC+7622fW for ; Mon, 22 Oct 2012 13:02:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 99CC921F869C for ; Mon, 22 Oct 2012 13:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8091; q=dns/txt; s=iport; t=1350936132; x=1352145732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xr99VjL8uBlpMLQ4O0cyLH+aGwAHocpcj63KrwhDYJo=; b=lAIsMQtcznR261Qyp11xgyiFgPYWCOp+iIRWwuQz7l7fgxdM+k7OUQEe 6fnO0VbukjMwJV4RBQiwUtk6yZx0QhG0aZaRBHSanWh16heZiW61uZZre xsy9IbnfUfa47f+Tho7eLG3SWcFRGKmtJFsPnro2WbFPXhrCKREtmrpnA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIHALekhVCtJV2Y/2dsb2JhbABFgkqGKaZhiHKGJYJBgQiCIQEBBAEBAQ8BWwsQAgEIIh0HJwsUEQEBBAoEBQgah2ILm36gD4tfhg9gA5cIjTeBa4EugUGCGA X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208,217";a="134223296" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 22 Oct 2012 20:02:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MK2CSn022445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 20:02:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 15:02:11 -0500 From: "Stan Ratliff (sratliff)" To: "Ivancic, William D. (GRC-RHN0)" Thread-Topic: [manet] DLEP and modem Link Property Advertisements Thread-Index: Ac2wiOW/eBU1uMoeQi6P2m8wxbwm4AAMSHAA Date: Mon, 22 Oct 2012 20:02:10 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21D@xmb-aln-x03.cisco.com> References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> In-Reply-To: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--34.112600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21Dxmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:02:13 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21Dxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will, If you have some time, I'd like to meet with you and discuss "DLEP-lite". Regards, Stan On Oct 22, 2012, at 3:10 PM, Ivancic, William D. (GRC-RHN0) wrote: A few months ago (time flies), the authors of modemLPA have been in disc= ussion with the authors of "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] to determine if DLEP will fullfil the needs that ModemLPA is targeted at. DLEP is currently a client/server session oriented protocol that provides link layer information to directly connected devices - generally routers. The Modem Link Property Advertisment protocol broadcasts link status notifications to directly-attached devices and devices or applications that may be multiple hops away from the modem (or other sending device). It should be possible to use the DLEP message formats without all the signalling required for the DLEP client/server session to perform the functions addressed in this draft. The modem would simply provide link states out via multicast or unicast UDP datagrams (DLEP-Lite). Whether or not this is a good idea, or acceptable to the manet group, is yet to be determined. In the mean time, This modemLPA document was originally submitted to the IR= TF mobopts research group as an individual submission draft-ivancic-mobopts= -modemlpa-01. That research group as recently closed down. I am looking f= or a new place to put updates until a decision is made on DLEP-Lite. Is the= manet group the right place? I really don't know if this is the right gro= up or if someplace else may be more appropriate. I see no other working gr= oups or research groups really looking at layer-2 triggers. Finally: A PERL script, modem-LPA-packetgen.pl, h= as been placed in sourceforge as open source software. The PERL script generates modemLPA packets base on the modem link property advertisement draft, "draft-ivancic-mobopts-modemlpa-01". The script was used to demonstrate modemLPA by controlling the rate on a file transfer protocol. The file transfer protocol used was Saratoga and is implemented in a PERL script. The Saratoga PERL script is available on SourceForge. Search for saratoga and the script will be in the directory saratoga-v1-perl. This script and the Saratoga implementation currently use a multicast address of 226.1.1.2. The all routers address of 224.0.0.2 is suppose to be used, but the particular Linux machines we where running on did not want to pass 224.0.0.2 and we did not have sufficient time to determine why. Eventually, we hope to include code for GNU radios that implement modemLPA (Or perhap DLEP-lite). Code is available for modemLPA from http://sourceforge.net/projects/modemlpa/ Code is available for Saratoga from http://saratoga.cvs.sourceforge.net/viewvc/saratoga/ I am currently planning on attending the IETF meetings in Atlanta. - Will Ivancic _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21Dxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0F86B6B50B50FE48A7D75A44F75CCF35@cisco.com> Content-Transfer-Encoding: quoted-printable Will, 

If you have some time, I'd like to meet with you and discuss "DLE= P-lite".

Regards,
Stan

On Oct 22, 2012, at 3:10 PM, Ivancic, William D. (GRC-RHN0) wrote: 
   A few months ago (time flies), the authors of modemLPA have been in=
 discussion with the authors of
   "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] =
to
   determine if DLEP will fullfil the needs that ModemLPA is targeted
   at.  DLEP is currently a client/server session oriented protocol that
   provides link layer information to directly connected devices -
   generally routers.  The Modem Link Property Advertisment protocol
   broadcasts link status notifications to directly-attached devices and
   devices or applications that may be multiple hops away from the modem
   (or other sending device).

   It should be possible to use the DLEP message formats without all the
   signalling required for the DLEP client/server session to perform the
   functions addressed in this draft.  The modem would simply provide
   link states out via multicast or unicast UDP datagrams (DLEP-Lite).
   Whether or not this is a good idea, or acceptable to the manet group,
   is yet to be determined.
In the mean time, This modemLPA document was originally submitted =
;to the IRTF mobopts research group as an individual submission draft-=
ivancic-mobopts-modemlpa-01.  That research group as recently closed down. =
 I am looking for a new place to put updates until a decision is made on DL=
EP-Lite. Is the manet group the right place?  I really don't know if this i=
s the right group or if someplace else may be more appropriate.  I see no o=
ther working groups or research groups really looking at layer-2 triggers. =


Finally:
   A PERL script, modem-LPA=
-packetgen.pl, has been placed in sourceforge
   as open source software.  The PERL script generates modemLPA packets
   base on the modem link property advertisement draft,
   "draft-ivancic-mobopts-modemlpa-01". =20

   The script was used to demonstrate modemLPA by controlling the rate
   on a file transfer protocol.  The file transfer protocol used was
   Saratoga and is implemented in a PERL script.  The Saratoga PERL
   script is available on SourceForge.  Search for saratoga and the
   script will be in the directory saratoga-v1-perl.

   This script and the Saratoga implementation currently use a multicast
   address of 226.1.1.2.  The all routers address of 224.0.0.2 is
   suppose to be used, but the particular Linux machines we where
   running on did not want to pass 224.0.0.2 and we did not have
   sufficient time to determine why.

   Eventually, we hope to include code for GNU radios that implement
   modemLPA (Or perhap DLEP-lite).

   Code is available for modemLPA from
   http://sourceforge=
.net/projects/modemlpa/

   Code is available for Saratoga from
   http://=
saratoga.cvs.sourceforge.net/viewvc/saratoga/

I am currently planning on attending the IETF meetings in Atlanta.

- Will Ivancic






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

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21Dxmbalnx03ciscoc_-- From internet-drafts@ietf.org Mon Oct 22 13:59:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD7F1F0C59; Mon, 22 Oct 2012 13:59:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srmM-qzVhWY7; Mon, 22 Oct 2012 13:59:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984901F0429; Mon, 22 Oct 2012 13:59:17 -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: 4.34 Message-ID: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 13:59:17 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:59:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Security Threats for NHDP Author(s) : Ulrich Herberg Jiazi Yi Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-sec-threats-01.txt Pages : 16 Date : 2012-10-22 Abstract: This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 16:50:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB811E812E; Mon, 22 Oct 2012 16:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzb4intYC8cJ; Mon, 22 Oct 2012 16:50:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6B111E8124; Mon, 22 Oct 2012 16:50: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: 4.34 Message-ID: <20121022235026.5562.34034.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:50:26 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dymo-23.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:50:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Ian D Chakeres Filename : draft-ietf-manet-dymo-23.txt Pages : 39 Date : 2012-10-22 Abstract: The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dymo There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dymo-23 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-23 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From axel-ietf@axelcdv.com Mon Oct 22 17:04:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F53C21F8943 for ; Mon, 22 Oct 2012 17:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua+9vhGJ9q4i for ; Mon, 22 Oct 2012 17:03:59 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 458D521F8612 for ; Mon, 22 Oct 2012 17:03:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id BA6D6558C5B for ; Mon, 22 Oct 2012 17:03:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0634A1C03E3 for ; Mon, 22 Oct 2012 17:03:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.1.1.206] (Cs-136-214.CS.UCLA.EDU [131.179.136.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D9A931C03BD for ; Mon, 22 Oct 2012 17:03:56 -0700 (PDT) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> Date: Mon, 22 Oct 2012 17:03:58 -0700 To: manet@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 00:04:00 -0000 Dear all, we have updated LOADng, to make it clear that it is in scope and charter = for MANET. Unfortunately, it is only a minor revision of the technical = content, since we have been in discussions with the DYMO authors and the = WG leadership for several months on how to proceed with the reactive = protocol in MANET. The chairs will likely reply very soon to the list = with an outcome of the discussion. Best regards, Axel Colin de Verdiere From boberry@cisco.com Mon Oct 22 18:39:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AF81F0429 for ; Mon, 22 Oct 2012 18:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HKzGqUzRLxq for ; Mon, 22 Oct 2012 18:39:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C84BB1F0C67 for ; Mon, 22 Oct 2012 18:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1824; q=dns/txt; s=iport; t=1350956379; x=1352165979; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HGFq7zFF52Wlc52qG2YVvAt3GNdmDJbMWjbtsRH89K4=; b=WibUwMm8FCzeVnSUHDaUrrG+JUVmQKisnvAAHvHhRby2gDpcGwoLMSu/ 1u2dvnU7qM0IgHgB8LR5vuKmdcDdOq5GsSH4JLzIL7Roa/hCr78S+yMzA OBYe0Qdc1DPgD2Pqsl/pT+oqaGk4yEp6AicQm9Jl/klDTsqelxdcGt/Wr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHX0hVCtJV2a/2dsb2JhbABEwWCBCIIgAQEBAwEBAQEPAVsLBQsLRicwBhMih1wGC5wnoC4Ei1gbhXRgA5VxhWSIaoFrgws X-IronPort-AV: E=Sophos;i="4.80,632,1344211200"; d="scan'208";a="134307313" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 23 Oct 2012 01:39:39 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-111.cisco.com [10.81.230.111]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9N1dcDp005174; Tue, 23 Oct 2012 01:39:39 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> Date: Mon, 22 Oct 2012 21:39:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> To: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 01:39:40 -0000 Hi Alex For those of us that have not have the opportunity to follow the Loadng discussions, could you please describe the similarities=20 and the unique differences of Loadng relative to Dymo. I'm aware=20 of the discussions about lousy nets and manets, but less between=20 the two protocols.=20 I think this would help everyone on the WG understand the benefits. Looking at the Tools page, the draft was first submitted October 24, = 2011, draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc=20= Distance-vector Routing Protocol - Next Generation (LOADng)." The abstract included the statement "The protocol is derived=20 from AODV and extended for use in LLNs". Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the line "The protocol is derived from AODV (RFC3561) and extended for=20 use in LLNs." was removed. This version also supported RFC 5444.=20 The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)."=20 Thanks -Bo On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote: > Dear all, >=20 > we have updated LOADng, to make it clear that it is in scope and = charter for MANET. Unfortunately, it is only a minor revision of the = technical content, since we have been in discussions with the DYMO = authors and the WG leadership for several months on how to proceed with = the reactive protocol in MANET. The chairs will likely reply very soon = to the list with an outcome of the discussion. >=20 > Best regards, >=20 > Axel Colin de Verdiere >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Oct 22 19:49:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70711E80A2 for ; Mon, 22 Oct 2012 19:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.87 X-Spam-Level: X-Spam-Status: No, score=-2.87 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OOfm2EowoF4 for ; Mon, 22 Oct 2012 19:49:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBF01F0C88 for ; Mon, 22 Oct 2012 19:49:43 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4058479vcb.31 for ; Mon, 22 Oct 2012 19:49:42 -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=AvKsczfxaG9jtqGmeHOgh6bunMJlOm7iU5anbMB1Afk=; b=fn5UdQbGlaG77EU8itzAnSY0shZwTmcqJBmAVzdOXhL2sc4pTd3ZWVfSnXgM8pmaEt ztyNFChbwUBYSHNOYwhejYDV1oqaryC0zkePr0ZkXbb3Uzji/l/2Y5DFTdEmWw6NKCuy 3WeaBeAXULTcikcW15XVixTDvLzTsODkjtIXg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AvKsczfxaG9jtqGmeHOgh6bunMJlOm7iU5anbMB1Afk=; b=d4rO9w6UkDl+WC1w1UrxuZMGTftfjgauH7fNQtX8m6ZAb8NEEOiGx36Q94ikLd/rTF DnqEHP9uiVi+0oe6zimAENwgiMy/JEkYhan/7loOXCbBrMq3xxWQc96FBbRcHAsgYMa4 +XRjWUPhUHD2negwkuJ0xeuiNKR34VnudD2B26J0fZOjGvzgXisNuqkWW+/fXxlyhTYe wTXPZ1Ow6S+/kPQLJ/JzBX35vu+A7n9s6xmwoZhLCHPM58sCI4629ZKHAYq4nCSZW80R HmIm1HvX0Wn385XwZnkhAdzcgNReUErT+mfkbqK9OsNOL1xuevntzf98CJfW/hVD+8Io 8J4A== MIME-Version: 1.0 Received: by 10.52.66.10 with SMTP id b10mr14775280vdt.71.1350960582628; Mon, 22 Oct 2012 19:49:42 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Mon, 22 Oct 2012 19:49:42 -0700 (PDT) In-Reply-To: <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> Date: Mon, 22 Oct 2012 19:49:42 -0700 Message-ID: From: Ulrich Herberg To: Bo Berry Content-Type: multipart/alternative; boundary=20cf3071cf1ea2138604ccb10597 X-Gm-Message-State: ALoCoQlxuReYtccVrI28mW9Ek1wApxaXErC3RB5koe6Iaqyvu18aj4T3jTYT4mLGndnA76SNIJXF Cc: manet@ietf.org Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 02:49:45 -0000 --20cf3071cf1ea2138604ccb10597 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bo, On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry wrote: > Hi Alex > > For those of us that have not have the opportunity to follow > the Loadng discussions, could you please describe the similarities > and the unique differences of Loadng relative to Dymo. I'm aware > of the discussions about lousy nets and manets, but less between > the two protocols. > > I think this would help everyone on the WG understand the benefits. > I agree with that, and it is a fair question to ask. Let me try to list a few differences, others may chime in with more. First the commonalities: - Both are reactive protocols, based on AODV, with the intended status of "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that the WG has to come up with a std. track reactive protocol. Essentially, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and no route exists for the destination of the data packet). Therefore, you will see similar message types in both protocols (Route Requests, Route Replies, and Route Errors), and essentially the same basic mechanism. - Both are applicable to MANETs (see also below for your next question), and both support RFC5444. LOADng is decoupling the mechanism from the message format; RFC5444 is mapped to the mechanism, but other message formats could easily be specified (e.g., with a more compressed message format for extremely limited links in terms of bandwidth). Now some differences: - Most importantly: LOADng has achieved what DYMO failed to do: to gather broad industrial support from several large companies, several large-scale deployments with several thousands of nodes, LOADng has an updated MIB document, and documented interoperability test of at least four recent implementations. - Part of the reason, I believe, is that the writing style is very different. LOADng has a more algorithmic way of writing. That's immediate to see when you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that an undergrad student could take the spec, spend a few days implementing it and have a reasonable and interoperable implementation. I have implemented LOADng in one day, based on the specification. - There are multiple optional features in DYMO that have deliberately not been included in LOADng (expanding ring multicasts, intermediate RREPs, precursor lists etc). The reason was the following: in an experimental protocol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that experience now with AODV. For some of the options, such as iRREP, it has not been shown over the last decade that they are of general use. In some cases, they may be beneficial, but not in general. Also, they make it very hard to provide end-to-end security. LOADng kept the mantra of a small, slim, and efficient protocol. Having many options makes it hard to assure interoperable devices out of the box, in particular if there is no negotiation of capabilities. Moreover, reactive protocols are often used in cases where memory is an extremely scarce resource, and where proactive protocols cannot be used. That makes a slim design preferable, IMO, for such protocols. - LOADng may be used in other layers as L3, e.g. as mesh-under protocol. - LOADng supports optimized broadcasting mechanisms such as MPR flooding - There is no Route Reply ACK in DYMO; this is part of LOADng to verify bidirectionality of links; as in wireless channels, links are rarely symmetric. > > Looking at the Tools page, the draft was first submitted October 24, 2011= , > draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc > Distance-vector Routing Protocol - Next Generation (LOADng)." The > abstract included the statement "The protocol is derived > from AODV and extended for use in LLNs". > > Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the > line "The protocol is derived from AODV (RFC3561) and extended for > use in LLNs." was removed. This version also supported RFC 5444. > > The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, > for the most part changes "Low power and Lossy Networks (LLN)" > references to "Mobile Ad hoc NETworks (MANETs)." > The draft started out from where the deployments exist, which some call LLNs. However, as a basic reactive protocol, LOADng also covers the more general MANET case that includes a wider ranger of resources (from extremely constrained to not-so-constrained) and mobility. In particular, by supporting RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimizations and TLVs etc. for RFC5444. I hope I could shed some light on that question. I invite you to read both drafts, there is probably more to say here. I won't go into details here, but most of the discussions we had were not so much about technical issues, but about procedural. LOADng has started when DYMO was stalled for more than 2 years. I think we have a well mature document, supported by strong industry backing and running code. The latter is crucial in the IETF. Best regards Ulrich > > Thanks > -Bo > > > > On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote: > > > Dear all, > > > > we have updated LOADng, to make it clear that it is in scope and charte= r > for MANET. Unfortunately, it is only a minor revision of the technical > content, since we have been in discussions with the DYMO authors and the = WG > leadership for several months on how to proceed with the reactive protoco= l > in MANET. The chairs will likely reply very soon to the list with an > outcome of the discussion. > > > > Best regards, > > > > Axel Colin de Verdiere > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf3071cf1ea2138604ccb10597 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, = Bo Berry <boberry@cisco.com> wrote:
Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities
and the unique differences of Loadng relative to Dymo. =A0I'm aware
of the discussions about lousy nets and manets, but less between
the two protocols.

I think this would help everyone on the WG understand the benefits.


I agree with that, and it is a = fair question to ask. Let me try to list a few differences, others may chim= e in with more.=A0

First the commonalities:
=A0- Both are reacti= ve protocols, based on AODV, with the intended status of "Proposed Sta= ndard" (AODV is "Experimental"). The MANET charter lists tha= t the WG has to come up with a std. track reactive protocol. Essentially, i= n a reactive protocol, routes are requested "on-demand" (i.e. whe= n there is data traffic and no route exists for the destination of the data= packet). Therefore, you will see similar message types in both protocols (= Route Requests, Route Replies, and Route Errors), and essentially the same = basic mechanism.
- Both are applicable to MANETs (see also below for your next question= ), and both support RFC5444. LOADng is decoupling the mechanism from the me= ssage format; RFC5444 is mapped to the mechanism, but other message formats= could easily be specified (e.g., with a more compressed message format for= extremely limited links in terms of bandwidth).

Now some differences:
- Most importantly: LOA= Dng has achieved what DYMO failed to do: to gather broad industrial support= from several large companies, several large-scale deployments with several= thousands of nodes, LOADng has an updated MIB document, and documented int= eroperability test of at least four recent implementations.
- Part of the reason, I believe, is that the writing style is very dif= ferent. LOADng has a more algorithmic way of writing. That's immediate = to see when you compare section 5.3 of DYMO with section 12 of LOADng. It i= s, IMO, much harder to implement DYMO. The goal for LOADng was to make it s= o straight forward to implement that an undergrad student could take the sp= ec, spend a few days implementing it and have a reasonable and interoperabl= e implementation. I have implemented LOADng in one day, based on the specif= ication.
- There are multiple optional features in DYMO that have deliberately = not been included in LOADng (expanding ring multicasts, intermediate RREPs,= precursor lists etc). The reason was the following: in an experimental pro= tocol (AODV) it is fine to have many options, in order to explore whether t= hey are useful. We have that experience now with AODV. For some of the opti= ons, such as iRREP, it has not been shown over the last decade that they ar= e of general use. In some cases, they may be beneficial, but not in general= . Also, they make it very hard to provide end-to-end security. LOADng kept = the mantra of a small, slim, and efficient protocol. Having many options ma= kes it hard to assure interoperable devices out of the box, in particular i= f there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is a= n extremely scarce resource, and where proactive protocols cannot be used. = That makes a slim design preferable, IMO, for such protocols.
- LOADng may be used in other layers as L3, e.g. as mesh-under protocol.
- LOADng supports optimized broadcasting mechanisms such as MPR flo= oding
- There is no=A0Route Reply ACK in DYMO; this is part of LO= ADng to verify bidirectionality of links; as in wireless channels, links ar= e rarely symmetric.=A0
=A0

Looking at the Tools page, the draft was first submitted October 24, 2011,<= br> draft-clausen-lln-loadng-00. =A0The title was, "The LLN On-demand Ad h= oc
Distance-vector Routing Protocol - Next Generation (LOADng)." =A0The abstract included the statement "The protocol is derived
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for
use in LLNs." was removed. =A0This version also supported RFC 5444.
The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)."
=


The draft started out from where the dep= loyments exist, which some call LLNs. However, as a basic reactive protocol= , LOADng also covers the more general MANET case that includes a wider rang= er of resources (from extremely constrained to not-so-constrained) and mobi= lity. In particular, by supporting RFC5444 it fits well in the MANET archit= ecture and the surrounding security extensions, flooding optimizations and = TLVs=A0etc. for RFC5444.

I hope I could shed some light on that question. I invi= te you to read both drafts, there is probably more to say here.
<= br>
I won't go into details here, but most of the discussions= we had were not so much about technical issues, but about procedural. LOAD= ng has started when DYMO was stalled for more than 2 years. I think we have= a well mature document, supported by strong industry backing and running c= ode. The latter is crucial in the IETF.

Best regards
Ulrich

=
=A0

Thanks
-Bo



On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote:

> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and chart= er for MANET. Unfortunately, it is only a minor revision of the technical c= ontent, since we have been in discussions with the DYMO authors and the WG = leadership for several months on how to proceed with the reactive protocol = in MANET. The chairs will likely reply very soon to the list with an outcom= e of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf3071cf1ea2138604ccb10597-- From abdussalambaryun@gmail.com Mon Oct 22 23:41:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AFF21F897C for ; Mon, 22 Oct 2012 23:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0eMdQWeaKWN for ; Mon, 22 Oct 2012 23:41:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C88121F8504 for ; Mon, 22 Oct 2012 23:41:12 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4235493vbb.31 for ; Mon, 22 Oct 2012 23:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SgIvEZrhJI/DHOLdDU4q8nFdbE00RIC7mKvtRnxXEHU=; b=OumrEKib5Ey5pi2mrXcdhPktn+1O2qiwl6pCMl8B/21232hIhYv6sgyO+4IW/AYBfs DsTP8Ob/oiFF8TsShfH8tse9T0CKxVOGrhAtIMjBSIduwS3HVUDXwFqGW3wxu9xVydov 66lZj74CX34WsdpGWQw+v3pRPfw+EmYSYGG47hEPlnCkTTGJQ14SdFcVbAe+PPw9J2mD iDwEG6k7QVd6jY1ijge20OIJyLzq0xOMZl7MropKVFbuGAq4GUWiId/Zy7FdYL61h2DZ EhBiNDIr3DNC89fyox1+GDPUzK5JCThJF7qjlfTfV4H+9YWJiDdm7AmWHMG+242YeWbt i5aQ== MIME-Version: 1.0 Received: by 10.220.40.16 with SMTP id i16mr496915vce.31.1350974472199; Mon, 22 Oct 2012 23:41:12 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 22 Oct 2012 23:41:12 -0700 (PDT) In-Reply-To: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> Date: Tue, 23 Oct 2012 08:41:12 +0200 Message-ID: From: Abdussalam Baryun To: =?ISO-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 06:41:13 -0000 Hi Axel, I hope the LOAD team answers to my inputs of previous months regarding their individual work. I will never review/comment on such work, until you answer to previous recommendations. Please note that we should never ignore the WG-list's comments. If this individual-work is presented to meeting again without replying to MANET-list I will send complain. AB On 10/23/12, Axel Colin de Verdi=E8re wrote: > Dear all, > > we have updated LOADng, to make it clear that it is in scope and charter = for > MANET. Unfortunately, it is only a minor revision of the technical conten= t, > since we have been in discussions with the DYMO authors and the WG > leadership for several months on how to proceed with the reactive protoco= l > in MANET. The chairs will likely reply very soon to the list with an outc= ome > of the discussion. > > Best regards, > > Axel Colin de Verdiere > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From henning.rogge@fkie.fraunhofer.de Tue Oct 23 00:06:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB1A21F8A83 for ; Tue, 23 Oct 2012 00:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzPX3eqZ1BQv for ; Tue, 23 Oct 2012 00:06:40 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7825721F8A6E for ; Tue, 23 Oct 2012 00:06:35 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TQYZO-00010Y-FB for manet@ietf.org; Tue, 23 Oct 2012 09:06:34 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TQYZO-0001Wv-CZ for manet@ietf.org; Tue, 23 Oct 2012 09:06:34 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 09:06:34 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Oct 2012 09:06:33 +0200 Message-ID: <508641F2.9050100@fkie.fraunhofer.de> Date: Tue, 23 Oct 2012 09:06:26 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> In-Reply-To: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060201090900060901090406" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 23 Oct 2012 07:06:34.0207 (UTC) FILETIME=[EF978EF0:01CDB0EC] X-Virus-Scanned: yes (ClamAV 0.97.5/15492/Tue Oct 23 04:31:45 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 3323e5da4f65bad0ae85b235b9833247 Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:06:41 -0000 --------------ms060201090900060901090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 10/22/2012 09:10 PM, Ivancic, William D. (GRC-RHN0) wrote: > It should be possible to use the DLEP message formats without all > the signalling required for the DLEP client/server session to perform > the functions addressed in this draft. The modem would simply > provide link states out via multicast or unicast UDP datagrams > (DLEP-Lite). Whether or not this is a good idea, or acceptable to the > manet group, is yet to be determined. I have an implementation that does this with a RFC5444 compliant=20 protocol (was written in April this year). > In the mean time, This modemLPA document was originally submitted to > the IRTF mobopts research group as an individual submission > draft-ivancic-mobopts-modemlpa-01. That research group as recently > closed down. I am looking for a new place to put updates until a > decision is made on DLEP-Lite. Is the manet group the right place? I > really don't know if this is the right group or if someplace else may > be more appropriate. I see no other working groups or research > groups really looking at layer-2 triggers. The concept of my "stateless-rfc5444-dlep" was to create a 'core set' of = functionality that allow simplified use cases like you describe. In the most simple one, the Radio just sends out two types of messages=20 via multicast or unicast in regular intervals. The Router just listens=20 to the messages and updates its internal databases according the them. One message contains information about the network the radio is attached = to, the second message contains information about the known neighbors of = the radio. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060201090900060901090406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMjMwNzA2MzFaMCMGCSqGSIb3DQEJBDEWBBT26Svj2Fx9yLdbstN6sHzUMp6ZdzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAOj1ZwpwywmSppb71qw40wBbwDU5GQ78YJSYiLsw24fU7 w8UY/lj2auPqwMSu/LMxL9N/AltqvINh4aV9nPRO3K/hqNqdGFSwNYr0+0Q7BYPxr8ymsPpq tTVL0DXLu5N4zQ32iRY/rgo12pX1QArm+aYDqhV9zmLuNaPBuzrdmlJjJYxWtf0Gel8lcb4X V76205vcYv3ejz5AQwnuWXxVQme5WP5wu93GP3QoGcgW+ixvggd9jqwcDEDd5vpphgsQNPhF /0qkQ6o8m7X+lH1qtskbvaeIo1QWfjQSdpLRomwtGuZzPzt9b4c7LM0C5g9NE5SdzBBdGgVE pR2kKz2nzwAAAAAAAA== --------------ms060201090900060901090406-- From ietf@thomasclausen.org Tue Oct 23 00:34:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D4A21F85AC for ; Tue, 23 Oct 2012 00:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJbNAAX7QG9V for ; Tue, 23 Oct 2012 00:34:57 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 38BDD21F851A for ; Tue, 23 Oct 2012 00:34:57 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id CD42F558A3B for ; Tue, 23 Oct 2012 00:34:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 721EA1C08A7; Tue, 23 Oct 2012 00:34:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1AA391C0757; Tue, 23 Oct 2012 00:34:51 -0700 (PDT) References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Tue, 23 Oct 2012 09:34:48 +0200 To: Abdussalam Baryun Cc: "manet@ietf.org" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:34:58 -0000 I sent an email to you & the list on October 2. I believe what I said therei= n to, still, be true. But please do go ahead and "send complain[t]". Even better: go ahead and participate constructively in the activity of some= WG. Sent from my iPad On 23 oct. 2012, at 08:41, Abdussalam Baryun wr= ote: > Hi Axel, >=20 > I hope the LOAD team answers to my inputs of previous months regarding > their individual work. I will never review/comment on such work, until > you answer to previous recommendations. Please note that we should > never ignore the WG-list's comments. If this individual-work is > presented to meeting again without replying to MANET-list I will send > complain. >=20 > AB >=20 > On 10/23/12, Axel Colin de Verdi=C3=A8re wrote: >> Dear all, >>=20 >> we have updated LOADng, to make it clear that it is in scope and charter f= or >> MANET. Unfortunately, it is only a minor revision of the technical conten= t, >> since we have been in discussions with the DYMO authors and the WG >> leadership for several months on how to proceed with the reactive protoco= l >> in MANET. The chairs will likely reply very soon to the list with an outc= ome >> of the discussion. >>=20 >> Best regards, >>=20 >> Axel Colin de Verdiere >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From yi.jiazi@gmail.com Tue Oct 23 01:29:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6221F85C4 for ; Tue, 23 Oct 2012 01:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dhnCj+n7sPw for ; Tue, 23 Oct 2012 01:29:53 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D99BA21F85A2 for ; Tue, 23 Oct 2012 01:29:52 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2177339wey.31 for ; Tue, 23 Oct 2012 01:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:message-id:mime-version:subject:date :references:to:in-reply-to:x-mailer; bh=pVGv924SrRZ7ajH1Dy/9IH0dqu++IJ1DIvVTToxE2uQ=; b=VdcA67tSGn0PnJ2keWOnYqX9lk57vD7+0PgT3Zvjk2mkTisinlmnaLZtR7Pbf+nMuL 2fP+bjTXHJrpZrq8sRi7D8YaW1upWTyMlhF6isw6PTHbw28CeZ5WHq+UMUZ5wIE6jgOw FVd4Be7/XCzG3wcrLua/iSB94FmD9YA+tcgMWmoN213yjybE9b+ruFaI7IAr6ajy4010 y9S+dBkFELGIoZCUcsieKhlDPVfRWjTfo6Hnf6SB09ACqSkkcE7wo4ABAt4Tkryx1fpz A/Idfb2lTTdRy9XZm6zaCgrIaiS8BdrsxR/Zbp8yYGLb/ydRxgxe1zt695GmIY8oQN3G PVPQ== Received: by 10.180.87.132 with SMTP id ay4mr27220027wib.5.1350980991857; Tue, 23 Oct 2012 01:29:51 -0700 (PDT) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id cu1sm55191554wib.6.2012.10.23.01.29.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 01:29:51 -0700 (PDT) Sender: Jiazi YI From: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_C808018A-C8FF-4783-A633-C804C58E5465" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Tue, 23 Oct 2012 10:29:51 +0200 References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> To: " List" In-Reply-To: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1499) Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:29:54 -0000 --Apple-Mail=_C808018A-C8FF-4783-A633-C804C58E5465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all,=20 The new revision of the WG document draft-ietf-manet-nhdp-sec-threats = has addressed most of the comments from the WG.=20 The main changes include: o Take the misconfiguration of NHDP routers into consideration.=20= o Added a sub-section of Denial of service attack.=20 o Removed sub-section Sequence Number Attack, which should be = more related to OLSRv2.=20 o some text on the assumption & scope of the document.=20 I would like to thank again for the comments from the WG. Further = comments are always appreciated. best Jiazi On Oct 22, 2012, at 10:59 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. >=20 > Title : Security Threats for NHDP > Author(s) : Ulrich Herberg > Jiazi Yi > Thomas Heide Clausen > Filename : draft-ietf-manet-nhdp-sec-threats-01.txt > Pages : 16 > Date : 2012-10-22 >=20 > Abstract: > This document analyses common security threats of the Neighborhood > Discovery Protocol (NHDP), and describes their potential impacts on > MANET routing protocols using NHDP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_C808018A-C8FF-4783-A633-C804C58E5465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all, 
o Take the misconfiguration of = NHDP routers into consideration. 
o Added a = sub-section of Denial of service attack. 
o Removed = sub-section Sequence Number Attack, which should be more related to = OLSRv2. 
o some text on the assumption = & scope of the document. 

I would like = to thank again for the comments from the WG. Further comments are always = appreciated.

best
Jiazi


On Oct 22, 2012, at 10:59 PM, internet-drafts@ietf.org = wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Mobile = Ad-hoc Networks Working Group of the IETF.

Title =           : Security = Threats for NHDP
Author(s) =       : Ulrich Herberg
=             &n= bsp;           &nbs= p;Jiazi Yi
=             &n= bsp;           &nbs= p;Thomas Heide Clausen
Filename =        : = draft-ietf-manet-nhdp-sec-threats-01.txt
Pages =           : = 16
= Date =            : = 2012-10-22

Abstract:
  This document analyses = common security threats of the Neighborhood
  Discovery = Protocol (NHDP), and describes their potential impacts on
=   MANET routing protocols using NHDP.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-01
=
A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threat= s-01


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

________________________= _______________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= /blockquote>

= --Apple-Mail=_C808018A-C8FF-4783-A633-C804C58E5465-- From jvasseur@cisco.com Tue Oct 23 02:12:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE85321F85A6 for ; Tue, 23 Oct 2012 02:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1byedVheVkib for ; Tue, 23 Oct 2012 02:12:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EB6DC21F8661 for ; Tue, 23 Oct 2012 02:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21369; q=dns/txt; s=iport; t=1350983566; x=1352193166; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jwjElL4hxNPf47jQfcYooBJmL/oYaru3sOpdadE8hVs=; b=USUWMLylG5Rs3DS6FrWuQhQq0ZfRAKLfK10F4dkEYWdE/fqUKauDCan/ jz3uZLzMegiYY31rapvkqNsx0knyRzDPoPeT/m7v75rRIuNR0fg/RDdj0 CQuhBurTL1Mffiy6MOyIZCF3do0NrV+8S11VTf69V+9Q1XcrSI90IkWgv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAHpehlCtJXG+/2dsb2JhbABEuHsBiGeBCIIeAQEBAwEBAQEPAVsBCgULAgEIEhAdBycLFAMOAgQOBQgah1wGC5xTj1yQSItfFAeFY2ADkj+ESY03gWuCb4FaCRce X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208,217";a="134392028" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2012 09:12:45 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9N9CjVO024577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 09:12:45 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 04:12:44 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] LOADng-06 Thread-Index: AQHNsP6PoCdWGOst6kOKVbo4pjGngA== Date: Tue, 23 Oct 2012 09:12:44 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722014627@xmb-rcd-x02.cisco.com> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--48.240200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722014627xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" , "Bo Berry \(boberry\)" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:12:48 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722014627xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Ulrich, Let me chine in since I do not think that we are in agreement with your con= clusions here - see below On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote: Hi Bo, On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry > wrote: Hi Alex For those of us that have not have the opportunity to follow the Loadng discussions, could you please describe the similarities and the unique differences of Loadng relative to Dymo. I'm aware of the discussions about lousy nets and manets, but less between the two protocols. I think this would help everyone on the WG understand the benefits. I agree with that, and it is a fair question to ask. Let me try to list a f= ew differences, others may chime in with more. First the commonalities: - Both are reactive protocols, based on AODV, with the intended status of = "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that = the WG has to come up with a std. track reactive protocol. Essentially, in = a reactive protocol, routes are requested "on-demand" (i.e. when there is d= ata traffic and no route exists for the destination of the data packet). Th= erefore, you will see similar message types in both protocols (Route Reques= ts, Route Replies, and Route Errors), and essentially the same basic mechan= ism. JP> It is worth that MANET has already a WG document, DYMO, which has been = discussed extensively in the WG. - Both are applicable to MANETs (see also below for your next question), an= d both support RFC5444. LOADng is decoupling the mechanism from the message= format; RFC5444 is mapped to the mechanism, but other message formats coul= d easily be specified (e.g., with a more compressed message format for extr= emely limited links in terms of bandwidth). Now some differences: - Most importantly: LOADng has achieved what DYMO failed to do: to gather b= road industrial support from several large companies, several large-scale d= eployments with several thousands of nodes, LOADng has an updated MIB docum= ent, and documented interoperability test of at least four recent implement= ations. JP> If I may, this is more of a Marketing comment though. I do not think th= at DYMO failed in any way. It turns out that the timing was different, that= 's all. - Part of the reason, I believe, is that the writing style is very differen= t. LOADng has a more algorithmic way of writing. That's immediate to see wh= en you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, m= uch harder to implement DYMO. The goal for LOADng was to make it so straigh= t forward to implement that an undergrad student could take the spec, spend= a few days implementing it and have a reasonable and interoperable impleme= ntation. I have implemented LOADng in one day, based on the specification. JP> I personally saw several implementations of DYMO, and if we require mor= e algorithmic details about DYMO, let's provide comments to the DYMO authors. - There are multiple optional features in DYMO that have deliberately not b= een included in LOADng (expanding ring multicasts, intermediate RREPs, prec= ursor lists etc). The reason was the following: in an experimental protocol= (AODV) it is fine to have many options, in order to explore whether they a= re useful. We have that experience now with AODV. For some of the options, = such as iRREP, it has not been shown over the last decade that they are of = general use. In some cases, they may be beneficial, but not in general. Als= o, they make it very hard to provide end-to-end security. LOADng kept the m= antra of a small, slim, and efficient protocol. Having many options makes i= t hard to assure interoperable devices out of the box, in particular if the= re is no negotiation of capabilities. Moreover, reactive protocols are often used in cases where memory is an ext= remely scarce resource, and where proactive protocols cannot be used. That = makes a slim design preferable, IMO, for such protocols. JP> We can discuss further in Atlanta, but several of these options are IMO= quite useful. - LOADng may be used in other layers as L3, e.g. as mesh-under protocol. JP> Another concern =85 If you plan using LOAD-ng as a mesh under protocol,= this requires much more discussion (not sure that such discussions should take place at the IETF, but because this would be an IETF work, we w= ould need to discuss it further). Indeed, proposing to standardize a mesh-under protocol is not just a matter of manipulating MAC addresses inst= ead of IP addresses: there are tons of implications of the architecture, as described in details in http://tools.ietf.org/html/draft-routing-archite= cture-iot-00 - LOADng supports optimized broadcasting mechanisms such as MPR flooding - There is no Route Reply ACK in DYMO; this is part of LOADng to verify bid= irectionality of links; as in wireless channels, links are rarely symmetric= . JP> Let's discuss further about these optimizations, which if needed, could= be added to DYMO. Looking at the Tools page, the draft was first submitted October 24, 2011, draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)." The abstract included the statement "The protocol is derived from AODV and extended for use in LLNs". Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the line "The protocol is derived from AODV (RFC3561) and extended for use in LLNs." was removed. This version also supported RFC 5444. The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)." The draft started out from where the deployments exist, which some call LLN= s. JP> As pointed out earlier, then I have two major concerns: 1) If the reactive routing protocol deals with LLNs, especially "hard const= rained" LLNs as pointed out in this mailing list, then I would strongly suggest to run the document by the two WGs, MANET and= ROLL. Let's see what the chairs decides. 2) ROLL co-chair hat-off, I do see a number of issues using reactive routin= g in hard constrained LLNs such as AMI PLC, years of experience in routing in such networks show us that there are majo= r scalability issues (I am not referring to the number of nodes, but also user traffic since depending on the user traffic this ma= y lead to massive control plane traffic churn to mention one of the many issues). However, as a basic reactive protocol, LOADng also covers the more general = MANET case that includes a wider ranger of resources (from extremely constr= ained to not-so-constrained) and mobility. In particular, by supporting RFC= 5444 it fits well in the MANET architecture and the surrounding security ex= tensions, flooding optimizations and TLVs etc. for RFC5444. I hope I could shed some light on that question. I invite you to read both = drafts, there is probably more to say here. I won't go into details here, but most of the discussions we had were not s= o much about technical issues, but about procedural. LOADng has started whe= n DYMO was stalled for more than 2 years. I think we have a well mature doc= ument, supported by strong industry backing and running code. JP> I do not make this email took polemical but you also have strong indust= ry disagreement in using such protocols for extremely constrained LLNs to say the least. Thanks. JP. The latter is crucial in the IETF. Best regards Ulrich Thanks -Bo On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote: > Dear all, > > we have updated LOADng, to make it clear that it is in scope and charter = for MANET. Unfortunately, it is only a minor revision of the technical cont= ent, since we have been in discussions with the DYMO authors and the WG lea= dership for several months on how to proceed with the reactive protocol in = MANET. The chairs will likely reply very soon to the list with an outcome o= f the discussion. > > Best regards, > > Axel Colin de Verdiere > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722014627xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <58DED1310BDDB24F8589C66581AF4C26@cisco.com> Content-Transfer-Encoding: quoted-printable Dear Ulrich,

Let me chine in since I do not think that we are in agreement with you= r conclusions here - see below

On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote:

Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry <boberry@cisco.co= m> wrote:
Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities
and the unique differences of Loadng relative to Dymo.  I'm aware
of the discussions about lousy nets and manets, but less between
the two protocols.

I think this would help everyone on the WG understand the benefits.


I agree with that, and it is a fair question to ask. Let me try to lis= t a few differences, others may chime in with more. 

First the commonalities:
 - Both are reactive protocols, based on AODV, with the intended = status of "Proposed Standard" (AODV is "Experimental").= The MANET charter lists that the WG has to come up with a std. track react= ive protocol. Essentially, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and n= o route exists for the destination of the data packet). Therefore, you will= see similar message types in both protocols (Route Requests, Route Replies= , and Route Errors), and essentially the same basic mechanism.

JP> It is worth that MANET has already a WG document, DYMO, which h= as been discussed extensively in the WG.

- Both are applicable to MANETs (see also below for your next question= ), and both support RFC5444. LOADng is decoupling the mechanism from the me= ssage format; RFC5444 is mapped to the mechanism, but other message formats= could easily be specified (e.g., with a more compressed message format for extremely limited links in terms= of bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to gat= her broad industrial support from several large companies, several large-sc= ale deployments with several thousands of nodes, LOADng has an updated MIB = document, and documented interoperability test of at least four recent implementations.

JP> If I may, this is more of a Marketing comment though. I do not = think that DYMO failed in any way. It turns out that the timing was differe= nt, that's all.

- Part of the reason, I believe, is that the writing style is very dif= ferent. LOADng has a more algorithmic way of writing. That's immediate to s= ee when you compare section 5.3 of DYMO with section 12 of LOADng. It is, I= MO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that a= n undergrad student could take the spec, spend a few days implementing it a= nd have a reasonable and interoperable implementation. I have implemented L= OADng in one day, based on the specification.

JP> I personally saw several implementations of DYMO, and if we req= uire more algorithmic details about DYMO, let's provide comments to the DYM= O
authors.

- There are multiple optional features in DYMO that have deliberately = not been included in LOADng (expanding ring multicasts, intermediate RREPs,= precursor lists etc). The reason was the following: in an experimental pro= tocol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that ex= perience now with AODV. For some of the options, such as iRREP, it has not = been shown over the last decade that they are of general use. In some cases= , they may be beneficial, but not in general. Also, they make it very hard to provide end-to-end security. L= OADng kept the mantra of a small, slim, and efficient protocol. Having many= options makes it hard to assure interoperable devices out of the box, in p= articular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is a= n extremely scarce resource, and where proactive protocols cannot be used. = That makes a slim design preferable, IMO, for such protocols.

JP> We can discuss further in Atlanta, but several of these options= are IMO quite useful.

- LOADng may be used in other layers as L3, e.g. as mesh-under protoco= l.

JP> Another concern =85 If you plan using LOAD-ng as a mesh under p= rotocol, this requires much more discussion (not sure that such discussions=
should take place at the IETF, but because this would be an IETF work,= we would need to discuss it further). Indeed, proposing to standardize a
mesh-under protocol is not just a matter of manipulating MAC addresses= instead of IP addresses: there are tons of implications of the architectur= e,

- LOADng supports optimized broadcasting mechanisms such as MPR floodi= ng
- There is no Route Reply ACK in DYMO; this is part of LOADng to = verify bidirectionality of links; as in wireless channels, links are rarely= symmetric. 
 

JP> Let's discuss further about these optimizations, which if neede= d, could be added to DYMO.


Looking at the Tools page, the draft was first submitted October 24, 2011,<= br> draft-clausen-lln-loadng-00.  The title was, "The LLN On-demand A= d hoc
Distance-vector Routing Protocol - Next Generation (LOADng)."  Th= e
abstract included the statement "The protocol is derived
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for
use in LLNs." was removed.  This version also supported RFC 5444.=

The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)."


The draft started out from where the deployments exist, which some cal= l LLNs.

JP> As pointed out earlier, then I have two major concerns:
1) If the reactive routing protocol deals with LLNs, especially "= hard constrained" LLNs as pointed out in this mailing list,
then I would strongly suggest to run the document by the two WGs, MANE= T and ROLL. Let's see what the chairs decides.
2) ROLL co-chair hat-off, I do see a number of issues using reactive r= outing in hard constrained LLNs such as AMI PLC,
years of experience in routing in such networks show us that there are= major scalability issues (I am not referring to the number
of nodes, but also user traffic since depending on the user traffic th= is may lead to massive control plane traffic churn to mention
one of the many issues).

However, as a basic reactive protocol, LOADng also covers the more gen= eral MANET case that includes a wider ranger of resources (from extremely c= onstrained to not-so-constrained) and mobility. In particular, by supportin= g RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimizatio= ns and TLVs etc. for RFC5444.

I hope I could shed some light on that question. I invite you to read = both drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had were = not so much about technical issues, but about procedural. LOADng has starte= d when DYMO was stalled for more than 2 years. I think we have a well matur= e document, supported by strong industry backing and running code.

JP> I do not make this email took polemical but you also have stron= g industry disagreement in using such protocols for extremely
constrained LLNs to say the least.

Thanks.

JP.

The latter is crucial in the IETF.

Best regards
Ulrich


 

Thanks
-Bo



On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote:

> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and chart= er for MANET. Unfortunately, it is only a minor revision of the technical c= ontent, since we have been in discussions with the DYMO authors and the WG = leadership for several months on how to proceed with the reactive protocol in MANET. The chairs will likely rep= ly very soon to the list with an outcome of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

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

--_000_03B78081B371D44390ED6E7BADBB4A7722014627xmbrcdx02ciscoc_-- From Chris.Dearlove@baesystems.com Tue Oct 23 02:42:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288A021F8618 for ; Tue, 23 Oct 2012 02:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1Z-5aeY2hBx for ; Tue, 23 Oct 2012 02:42:07 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5334021F8645 for ; Tue, 23 Oct 2012 02:42:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,634,1344207600"; d="scan'208";a="238188803" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Oct 2012 10:42:03 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9N9g3Kj028515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 10:42:03 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Tue, 23 Oct 2012 10:42:03 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Henning Rogge Thread-Topic: [manet] status of components DLEP and consensus on them Thread-Index: AQHNrIswe+sGTvqD/EmoU6f+wmIG35fGqRLg Date: Tue, 23 Oct 2012 09:42:02 +0000 Message-ID: References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [manet] status of components DLEP and consensus on them X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:42:08 -0000 (The last comment is Stan, I think before that it is Henning and Thomas Hen= derson.) >>> - RFC 5444 or not? >=20 >> My suggestion would be to postpone this question until the basic protoco= l mechanisms are well defined. > Hmmm. I consider the issue to be settled, and the answer is "not". At lea= st for this draft. If someone would like to come along behind DLEP and crea= te a "DLEP over 5444" draft... I'm currently maintaining a strictly neutral position on what should be the= case here. But I'm afraid I've seen nothing on the list that looks like a = consensus agreement that this is settled. The fact that someone not involve= d in the discussion then reviewed the discussion and listed this among othe= r items as not settled would support that. The idea of "DLEP over 5444" as an alternative draft seems poor to me. DLEP= as you are specifying it includes message formats. In order for this idea = to be meaningful, you'd have to specify DLEP messages in abstract terms, th= en have alternative formats one based on specialised formats. one based on = 5444. And while sketching out two formats in discussion may be an approach,= I'm not at all convinced by the idea of drafts defining both - especially = in an asymmetric manner as you suggest. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From boberry@cisco.com Tue Oct 23 04:11:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432D921F86E9 for ; Tue, 23 Oct 2012 04:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOwunGJmDb6I for ; Tue, 23 Oct 2012 04:11:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 383C221F86CA for ; Tue, 23 Oct 2012 04:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2674; q=dns/txt; s=iport; t=1350990676; x=1352200276; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VtusZ31HGGXBK2D51iFicL/JOfzUZK86Ye7j5zq9CKU=; b=h5j4bgS3JCFbtrZ5zJVIZe00BgN1ygfa43P/RcLN9p7cTt2hxT4BjN2B FQ03szm+Ya5zlcqgQzck9a3nyfniME9oRLZzpaGUvIoXKvccUQhvhVVqC dKmHpcLqWgldeqs/k1rkXFn5NdVefyBAjFgbrx6F1xC7koNvDkDEnExLp 0=; X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134418299" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 23 Oct 2012 11:11:16 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-106.cisco.com [10.81.230.106]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9NBBF6G001186; Tue, 23 Oct 2012 11:11:15 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Tue, 23 Oct 2012 07:11:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83AA0ADF-28AE-4B04-A073-2DBA9128407D@cisco.com> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1085) Cc: "" , "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] status of components DLEP and consensus on them X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:11:20 -0000 On Oct 23, 2012, at 5:42 AM, Dearlove, Christopher (UK) wrote: > (The last comment is Stan, I think before that it is Henning and = Thomas Henderson.) >=20 >>>> - RFC 5444 or not? >>=20 >>> My suggestion would be to postpone this question until the basic = protocol mechanisms are well defined. >=20 >> Hmmm. I consider the issue to be settled, and the answer is "not". At = least for this draft. If someone would like to come along behind DLEP = and create a "DLEP over 5444" draft... >=20 > I'm currently maintaining a strictly neutral position on what should = be the case here. But I'm afraid I've seen nothing on the list that = looks like a consensus agreement that this is settled. The fact that = someone not involved in the discussion then reviewed the discussion and = listed this among other items as not settled would support that. >=20 > The idea of "DLEP over 5444" as an alternative draft seems poor to me. = DLEP as you are specifying it includes message formats. In order for = this idea to be meaningful, you'd have to specify DLEP messages in = abstract terms, then have alternative formats one based on specialised = formats. one based on 5444. And while sketching out two formats in = discussion may be an approach, I'm not at all convinced by the idea of = drafts defining both - especially in an asymmetric manner as you = suggest. I agree that one DLEP is/should be adequate. And I also agree with = Stan not to use 5444. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Tue Oct 23 04:13:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DDE21F878A for ; Tue, 23 Oct 2012 04:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGFE-PNYSlqV for ; Tue, 23 Oct 2012 04:13:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0A31121F8787 for ; Tue, 23 Oct 2012 04:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2320; q=dns/txt; s=iport; t=1350990828; x=1352200428; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iMqE/SzcCZBnwvhjmD+pzm8hsO2fAyPuxvtoOBjYyak=; b=g0pTnwgHZFhGBcLpuXDFXpoc7x9MuNl4//21xXvHNJn5MCMyzzhOvcn5 i2r0YUYJjJthK2wV0VI0oEWDnHahC4+qQBnpd0sqCl5EqsxDJ9fapqbxM TO4zTYOgY0vS/piIOzUaOMJZ4P0srdBdLe9a+8sYQtPBn1mSS8Hw02kPk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFl7hlCtJV2c/2dsb2JhbABEwWOBCIIeAQEBAwEBAQEPAVsLBQsLGCcHJx8RBhMih1wGC5xdj1yQQotfhX5gA5VxhWSIaoFrgws X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134454346" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 23 Oct 2012 11:13:44 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-106.cisco.com [10.81.230.106]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9NBDhIT002930; Tue, 23 Oct 2012 11:13:43 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <508641F2.9050100@fkie.fraunhofer.de> Date: Tue, 23 Oct 2012 07:13:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:13:50 -0000 Henning, I've seen the draft, you should submit it to the WG. -Bo On Oct 23, 2012, at 3:06 AM, Henning Rogge wrote: > On 10/22/2012 09:10 PM, Ivancic, William D. (GRC-RHN0) wrote: >> It should be possible to use the DLEP message formats without all >> the signalling required for the DLEP client/server session to perform >> the functions addressed in this draft. The modem would simply >> provide link states out via multicast or unicast UDP datagrams >> (DLEP-Lite). Whether or not this is a good idea, or acceptable to the >> manet group, is yet to be determined. >=20 > I have an implementation that does this with a RFC5444 compliant = protocol (was written in April this year). >=20 >> In the mean time, This modemLPA document was originally submitted to >> the IRTF mobopts research group as an individual submission >> draft-ivancic-mobopts-modemlpa-01. That research group as recently >> closed down. I am looking for a new place to put updates until a >> decision is made on DLEP-Lite. Is the manet group the right place? I >> really don't know if this is the right group or if someplace else may >> be more appropriate. I see no other working groups or research >> groups really looking at layer-2 triggers. >=20 > The concept of my "stateless-rfc5444-dlep" was to create a 'core set' = of functionality that allow simplified use cases like you describe. >=20 > In the most simple one, the Radio just sends out two types of messages = via multicast or unicast in regular intervals. The Router just listens = to the messages and updates its internal databases according the them. >=20 > One message contains information about the network the radio is = attached to, the second message contains information about the known = neighbors of the radio. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Tue Oct 23 04:21:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F9B21F86DD for ; Tue, 23 Oct 2012 04:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IylAfA4X9MIm for ; Tue, 23 Oct 2012 04:21:54 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id C03E121F85EA for ; Tue, 23 Oct 2012 04:21:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,634,1344207600"; d="scan'208";a="238230929" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Oct 2012 12:21:52 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9NBLpxj025028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 12:21:52 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Tue, 23 Oct 2012 12:21:52 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry Thread-Topic: [manet] status of components DLEP and consensus on them Thread-Index: AQHNrIswe+sGTvqD/EmoU6f+wmIG35fGqRLggAALYgCAABDuUA== Date: Tue, 23 Oct 2012 11:21:51 +0000 Message-ID: References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> <83AA0ADF-28AE-4B04-A073-2DBA9128407D@cisco.com> In-Reply-To: <83AA0ADF-28AE-4B04-A073-2DBA9128407D@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] status of components DLEP and consensus on them X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:21:55 -0000 Agreeing with Stan that you shouldn't use 5444 is fine. And not all voices = are equal, document authors do, and I believe should, have more weight than= others. Nevertheless I don't think you've established that there is a cons= ensus against 5444. Tom Henderson's list would support that, and as far as = I can see, Tom provided a not so involved up to that point viewpoint. I thi= nk at the moment opinions are split between "not 5444" and "let's get to th= at later", but I wouldn't like to say whether there's a consensus for the f= ormer. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry Sent: 23 October 2012 12:12 To: Dearlove, Christopher (UK) Cc: ; ; Stan Ratliff (sratli= ff) Subject: Re: [manet] status of components DLEP and consensus on them ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Oct 23, 2012, at 5:42 AM, Dearlove, Christopher (UK) wrote: > (The last comment is Stan, I think before that it is Henning and Thomas H= enderson.) >=20 >>>> - RFC 5444 or not? >>=20 >>> My suggestion would be to postpone this question until the basic protoc= ol mechanisms are well defined. >=20 >> Hmmm. I consider the issue to be settled, and the answer is "not". At le= ast for this draft. If someone would like to come along behind DLEP and cre= ate a "DLEP over 5444" draft... >=20 > I'm currently maintaining a strictly neutral position on what should be t= he case here. But I'm afraid I've seen nothing on the list that looks like = a consensus agreement that this is settled. The fact that someone not invol= ved in the discussion then reviewed the discussion and listed this among ot= her items as not settled would support that. >=20 > The idea of "DLEP over 5444" as an alternative draft seems poor to me. DL= EP as you are specifying it includes message formats. In order for this ide= a to be meaningful, you'd have to specify DLEP messages in abstract terms, = then have alternative formats one based on specialised formats. one based o= n 5444. And while sketching out two formats in discussion may be an approac= h, I'm not at all convinced by the idea of drafts defining both - especiall= y in an asymmetric manner as you suggest. I agree that one DLEP is/should be adequate. And I also agree with Stan n= ot to use 5444. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Tue Oct 23 04:26:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF33921F86D4 for ; Tue, 23 Oct 2012 04:26:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uHOSGjxHIK2 for ; Tue, 23 Oct 2012 04:26:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B39F121F86CF for ; Tue, 23 Oct 2012 04:26:41 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1581307eek.31 for ; Tue, 23 Oct 2012 04:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=AakCYhnr0qw50n/86yRjtOKBT33g12IMgf7gpLKwxI0=; b=Vrl6YoqG7UOt32czgMk1LY2SrqD+no3ZDXJUKEUz07jVMBQhf4hB0y61EB2sZw2rBc w4ULFsnfL4ocW3SWhIBz+VfeL1qS3lUn2LJAJdwdDMek1fzox1uTxGsiQyBoCiVuru1q SWBFYuEaxxMCoylGzwxEVYtfSLx4h2hrnwvSxlFDfr4KpOtXcEChAldtSOFM1q/5+XPq DOmD9vhgb2rZSE0LZFFydejqNjmznc5gAWB5NEdIKeY/97QwoFHO9M3oSaoUJ2jPGoZl mQQig+HvnDVwjXCIJcRt5SwEJM5aQ+LYnnUIl0sY51d5xtKsQvQDRRuamJdBf7Qe2u2I A4Jg== Received: by 10.14.200.194 with SMTP id z42mr8091908een.13.1350991601249; Tue, 23 Oct 2012 04:26:41 -0700 (PDT) Received: from [172.16.4.73] ([188.205.88.52]) by mx.google.com with ESMTPS id d44sm20396499eeo.10.2012.10.23.04.26.39 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 04:26:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21D@xmb-aln-x03.cisco.com> Date: Tue, 23 Oct 2012 13:26:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1195C440-820A-413C-B76A-96F3373EE567@inf-net.nl> References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21D@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" , "Ivancic, William D. (GRC-RHN0)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkQgrjGQOGPFYwA9+zeKUv/SJ/APfHk/wbUYgbThuXMnBgW30kJC3qYbfJefHk04OLtcQ9D Cc: " List" Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:26:43 -0000 I support this DLEP-lite idea. I have to deal security requirements=20 with strong border protection, where the inner (red) network would=20 benefit form feedback from the outer (black) network. Using data=20 diode is more easy to deploy than a secured gateway. So a pure=20 uni-directional feed would help getting data through a diode. Teco Op 22 okt. 2012, om 22:02 heeft Stan Ratliff (sratliff) het volgende = geschreven: > Will,=20 >=20 > If you have some time, I'd like to meet with you and discuss = "DLEP-lite". >=20 > Regards, > Stan >=20 > On Oct 22, 2012, at 3:10 PM, Ivancic, William D. (GRC-RHN0) wrote: >=20 >> A few months ago (time flies), the authors of modemLPA have been = in discussion with the authors of >> "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] to >> determine if DLEP will fullfil the needs that ModemLPA is targeted >> at. DLEP is currently a client/server session oriented protocol = that >> provides link layer information to directly connected devices - >> generally routers. The Modem Link Property Advertisment protocol >> broadcasts link status notifications to directly-attached devices = and >> devices or applications that may be multiple hops away from the = modem >> (or other sending device). >>=20 >> It should be possible to use the DLEP message formats without all = the >> signalling required for the DLEP client/server session to perform = the >> functions addressed in this draft. The modem would simply provide >> link states out via multicast or unicast UDP datagrams = (DLEP-Lite). >> Whether or not this is a good idea, or acceptable to the manet = group, >> is yet to be determined. >>=20 >> In the mean time, This modemLPA document was originally submitted to = the IRTF mobopts research group as an individual submission = draft-ivancic-mobopts-modemlpa-01. That research group as recently = closed down. I am looking for a new place to put updates until a = decision is made on DLEP-Lite. Is the manet group the right place? I = really don't know if this is the right group or if someplace else may be = more appropriate. I see no other working groups or research groups = really looking at layer-2 triggers.=20 >>=20 >> Finally: >> A PERL script, modem-LPA-packetgen.pl >> , has been placed in sourceforge >> as open source software. The PERL script generates modemLPA = packets >> base on the modem link property advertisement draft, >> "draft-ivancic-mobopts-modemlpa-01". =20 >>=20 >> The script was used to demonstrate modemLPA by controlling the = rate >> on a file transfer protocol. The file transfer protocol used was >> Saratoga and is implemented in a PERL script. The Saratoga PERL >> script is available on SourceForge. Search for saratoga and the >> script will be in the directory saratoga-v1-perl. >>=20 >> This script and the Saratoga implementation currently use a = multicast >> address of 226.1.1.2. The all routers address of 224.0.0.2 is >> suppose to be used, but the particular Linux machines we where >> running on did not want to pass 224.0.0.2 and we did not have >> sufficient time to determine why. >>=20 >> Eventually, we hope to include code for GNU radios that implement >> modemLPA (Or perhap DLEP-lite). >>=20 >> Code is available for modemLPA from >> =20 >> http://sourceforge.net/projects/modemlpa/ >>=20 >>=20 >> Code is available for Saratoga from >> =20 >> http://saratoga.cvs.sourceforge.net/viewvc/saratoga/ >>=20 >> I am currently planning on attending the IETF meetings in Atlanta. >> - Will Ivancic >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Tue Oct 23 04:37:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479C721F86E0 for ; Tue, 23 Oct 2012 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtXMgsEy8V4M for ; Tue, 23 Oct 2012 04:37:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0E40321F86E9 for ; Tue, 23 Oct 2012 04:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8729; q=dns/txt; s=iport; t=1350992267; x=1352201867; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QkVS3RbtkO4VZ2Di/AqFtG60IQHSxFYWZPohp69LNJ0=; b=Jmc7nRd6nFXE/Sdwb89uyzZM0hG4h/yisQIqC5fa9WkkgB7LxznBjTn/ InNzpKMEQSV4LrEGbNB5Do8aipB6eDwrkks8Jut7WhIMCdXO1Kxw1qcJk 9gfva8jh87LKVJk74HOtiBeG1O4GmDAkxadINegMRqhdKjJnpWK/jWh6L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAImAhlCtJXG9/2dsb2JhbABEwWOBCIIeAQEBAwEBAQEPAVsLBQsLEgYuJyIOBhMih1wGC5xUj1yQQASLXxQHhWNgA4tDhnyDMoVkbod8gWuDC4E+ X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134425338" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 23 Oct 2012 11:37:46 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-106.cisco.com [10.81.230.106]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9NBbjIb026822; Tue, 23 Oct 2012 11:37:45 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: Date: Tue, 23 Oct 2012 07:38:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:37:48 -0000 On Oct 22, 2012, at 10:49 PM, Ulrich Herberg wrote: > Hi Bo, >=20 > On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry wrote: > Hi Alex >=20 > For those of us that have not have the opportunity to follow > the Loadng discussions, could you please describe the similarities > and the unique differences of Loadng relative to Dymo. I'm aware > of the discussions about lousy nets and manets, but less between > the two protocols. >=20 > I think this would help everyone on the WG understand the benefits. >=20 >=20 > I agree with that, and it is a fair question to ask. Let me try to = list a few differences, others may chime in with more.=20 >=20 > First the commonalities: > - Both are reactive protocols, based on AODV, with the intended = status of "Proposed Standard" (AODV is "Experimental"). The MANET = charter lists that the WG has to come up with a std. track reactive = protocol. Essentially, in a reactive protocol, routes are requested = "on-demand" (i.e. when there is data traffic and no route exists for the = destination of the data packet). Therefore, you will see similar message = types in both protocols (Route Requests, Route Replies, and Route = Errors), and essentially the same basic mechanism. > - Both are applicable to MANETs (see also below for your next = question), and both support RFC5444. LOADng is decoupling the mechanism = from the message format; RFC5444 is mapped to the mechanism, but other = message formats could easily be specified (e.g., with a more compressed = message format for extremely limited links in terms of bandwidth). >=20 > Now some differences: > - Most importantly: LOADng has achieved what DYMO failed to do: to = gather broad industrial support from several large companies, several = large-scale deployments with several thousands of nodes, LOADng has an = updated MIB document, and documented interoperability test of at least = four recent implementations. > - Part of the reason, I believe, is that the writing style is very = different. LOADng has a more algorithmic way of writing. That's = immediate to see when you compare section 5.3 of DYMO with section 12 of = LOADng. It is, IMO, much harder to implement DYMO. The goal for LOADng = was to make it so straight forward to implement that an undergrad = student could take the spec, spend a few days implementing it and have a = reasonable and interoperable implementation. I have implemented LOADng = in one day, based on the specification. > - There are multiple optional features in DYMO that have deliberately = not been included in LOADng (expanding ring multicasts, intermediate = RREPs, precursor lists etc). The reason was the following: in an = experimental protocol (AODV) it is fine to have many options, in order = to explore whether they are useful. We have that experience now with = AODV. For some of the options, such as iRREP, it has not been shown over = the last decade that they are of general use. In some cases, they may be = beneficial, but not in general. Also, they make it very hard to provide = end-to-end security. LOADng kept the mantra of a small, slim, and = efficient protocol. Having many options makes it hard to assure = interoperable devices out of the box, in particular if there is no = negotiation of capabilities. > Moreover, reactive protocols are often used in cases where memory is = an extremely scarce resource, and where proactive protocols cannot be = used. That makes a slim design preferable, IMO, for such protocols. > - LOADng may be used in other layers as L3, e.g. as mesh-under = protocol. > - LOADng supports optimized broadcasting mechanisms such as MPR = flooding > - There is no Route Reply ACK in DYMO; this is part of LOADng to = verify bidirectionality of links; as in wireless channels, links are = rarely symmetric.=20 > =20 >=20 > Looking at the Tools page, the draft was first submitted October 24, = 2011, > draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc > Distance-vector Routing Protocol - Next Generation (LOADng)." The > abstract included the statement "The protocol is derived > from AODV and extended for use in LLNs". >=20 > Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the > line "The protocol is derived from AODV (RFC3561) and extended for > use in LLNs." was removed. This version also supported RFC 5444. >=20 > The draft posted tonight, October 22, 2012, = draft-clausen-lln-loadng-06, > for the most part changes "Low power and Lossy Networks (LLN)" > references to "Mobile Ad hoc NETworks (MANETs)." >=20 >=20 > The draft started out from where the deployments exist, which some = call LLNs. However, as a basic reactive protocol, LOADng also covers the = more general MANET case that includes a wider ranger of resources (from = extremely constrained to not-so-constrained) and mobility. In = particular, by supporting RFC5444 it fits well in the MANET architecture = and the surrounding security extensions, flooding optimizations and TLVs = etc. for RFC5444. When you say, "draft started out from where the deployments exist", where these implementations DYMO, which draft? Since 5444 was just added to the Loadng draft, is there an = implementation using 5444? > I hope I could shed some light on that question. I invite you to read = both drafts, there is probably more to say here. >=20 > I won't go into details here, but most of the discussions we had were = not so much about technical issues, but about procedural. LOADng has = started when DYMO was stalled for more than 2 years. I think we have a = well mature document, supported by strong industry backing and running = code. The latter is crucial in the IETF. I'm curious why the Loadng effort did not/could not work through the WG = to re-invigorate the DYMO discussions.=20 January 2005 - draft-ietf-manet-dymo-00 - Mobile Ad hoc Networks Working Group - Expires: July 5, 2005 ... several draft updates ... December 5, 2008 - draft-ietf-manet-dymo-16 March 8, 2009 - draft-ietf-manet-dymo-17 - Expires: September 9, 2009 February 23, 2010 - draft-ietf-manet-dymo-18 - Expires: August 27, 2010 - This draft included RFC5444 formatting March 22, 2010 - draft-ietf-manet-dymo-19 - Expires: September 23, 2010 July 10, 2010 - draft-ietf-manet-dymo-20 July 26, 2010 - draft-ietf-manet-dymo-21 - Expires: January 27, 2011 *October 24, 2011 - draft-clausen-lln-loadng-00 - Title: The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) - Abstract: This document describes the LLN Ad hoc On-Demand (LOAD) = distance vector routing protocol, a reactive routing protocol intended for = use in Low power Lossy Networks (LLN). The protocol is derived from = AODV and extended for use in LLNs. *October 31, 2011 - draft-clausen-lln-loadng-01 March 12, 2012 - draft-ietf-manet-dymo-22 - Expires: September 13, 2012 - Rebranding the protocol was included: Dynamic MANET On-demand (AODVv2) Routing *March 12, 2012 - draft-clausen-lln-loadng-02 *March 29, 2012 - draft-clausen-lln-loadng-03 *April 22, 2012 - draft-clausen-lln-loadng-04 *July 14, 2012 - draft-clausen-lln-loadng-05 - C. Perkins, Futurewei Inc. was added as a co-author - This line was removed from the Abstract: "The protocol is derived from AODV (RFC3561) and extended for use in LLNs." - This draft included RFC5444 formatting October 23, 2012 - draft-ietf-manet-dymo-23=20 *October 22, 2012 - draft-clausen-lln-loadng-06 - Added J. Dean from Naval Research Laboratory >=20 > Best regards > Ulrich >=20 >=20 > =20 >=20 > Thanks > -Bo >=20 >=20 >=20 > On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote: >=20 > > Dear all, > > > > we have updated LOADng, to make it clear that it is in scope and = charter for MANET. Unfortunately, it is only a minor revision of the = technical content, since we have been in discussions with the DYMO = authors and the WG leadership for several months on how to proceed with = the reactive protocol in MANET. The chairs will likely reply very soon = to the list with an outcome of the discussion. > > > > Best regards, > > > > Axel Colin de Verdiere > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From john.dowdell@cassidian.com Tue Oct 23 06:23:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250AF21F8568 for ; Tue, 23 Oct 2012 06:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=1.955, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55WFFWpqzAAB for ; Tue, 23 Oct 2012 06:23:17 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id C0CAA21F849C for ; Tue, 23 Oct 2012 06:23:14 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 23 Oct 2012 15:23:11 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 23 Oct 2012 15:23:13 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 15:23:12 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 15:23:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Oct 2012 14:23:11 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE01F72D72@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Some comments on manet-dlep-03 (UNKNOWN metric value) Thread-Index: AQHNoBfsWIhPi/1WP0Wy53psEOaFT5en2kCAgAAoDICAAgCEgIAAsLaAgAAxoACAA+2FAIAAcJkAgAA8ZICAAbOXgIAAA3QAgAAiigCAAABrgIAABViAgAAAggCAAAI6AIAAAy6AgAAD2gCAAAHEgIAAAX4AgAAAWwCAAAQ6AIAAAWYAgAABboCAAADdAP//rMYQgABavgCAAAzAAIAAB8yAgAADmYCAAAkLgIAATpQAgAG35oCAAHXegIAARJyAgAABFACAAAF+gIAAAI2AgAAA7wCAAATuAIAAA74AgAAA8ICAAAHsAIAAAPSAgAAYIID//7TScIAAYSwAgAAMAwCAABpTgIAA5NiAgABwD4CAAAUlAIAAE+oAgAAjnQCAAAVpAIAAASmAgADq2wCAAELQAIAAFCoAgAAUKgCAAAbRAIAABH6AgAE84wCAAOzCgIAND75g References: From: "Dowdell, John" To: "Stan Ratliff (sratliff)" , "Henning Rogge" , X-OriginalArrivalTime: 23 Oct 2012 13:23:11.0270 (UTC) FILETIME=[8C7DBC60:01CDB121] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19298.004 X-TM-AS-Result: No--37.854000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Bo Berry \(boberry\)" Subject: Re: [manet] Some comments on manet-dlep-03 (UNKNOWN metric value) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:23:19 -0000 Stan et al Some thoughts on why we might want a metric value of UNKNOWN instead of just not sending one. Suppose we have a network device which supports the reporting of certain metrics. Those metrics for which values are not reported are simply never sent (or actually I would rather the device declared that those were unsupported but that is another discussion entirely). On occasion, perhaps when the device is re-synchronising its connection to the network in some manner, or is waiting for a central scheduler to perform some action (e.g. for beyond line of sight hub and spoke communications devices), one or more metric values become invalid. Rather than not reporting the metric, I propose that the device reports UNKNOWN for those metrics which do not produce sensible results. It might be argued that such an event will coincide with a LINK DOWN event, and I would be very happy that during a LINK DOWN that such an event was handled within the existing specification, but if a measurement went out of range during LINK UP, then that is where the UNKNOWN value would be of used. As to proposed text, dlep-03 section 9.12 (relative link quality) already has a value of 100 to be reported where RLQ cannot be calculated. I would remark that the case of 'cannot be calculated' is not stated to refer to a case where that state is temporary, maybe because of a fault, or permanent in the sense that the device does not calculate RLQ. If we are going to have a value of UNKNOWN, then I would suggest that this needs to be a common value across all metrics, and not change according to the metric. A value of zero (0) would seem a good choice for UNKNOWN. Some text would need to be inserted in every section that discusses a metric (9.7-9.12) indicating that where the metric is reported by the device under normal operation, but that the device is temporarily unable to do so, that a value of UNKNOWN be reported to signal this temporary state. Regards John =20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff (sratliff) Sent: 15 October 2012 01:09 To: Henning Rogge Cc: manet@ietf.org; Bo Berry (boberry) Subject: Re: [manet] Some comments on manet-dlep-03 I've asked twice now (this email makes attempt number 3) for someone to suggest some text to clarify what a router or modem would do with an UNKNOWN metric. So far, what I've seen is a potentially new *way* of specifying UNKNOWN - one that makes more sense than picking some arbitrary code point. But no actual text to suggest what either of the endpoints would *do* with the data. Maybe I'm old, feeble, and not very bright - but I'm looking for suggestions that start with "A router receiving a metric value of UNKNOWN MUST..." or "An implementation receiving an UNKNOWN indication SHOULD..." or something along those lines. Barring that, the only text I've got to insert is what I suggested before:=20 >=20 > "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ is supported, but not currently calculable. The authors have no idea under what circumstances this would occur. Routers receiving a value of RLQ_UNKNOWN are free to take any action deemed appropriate, including (but not limited to) ignoring the value, producing log messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was added at the request of the working group, as consensus formed around the key ideas that this MAY allow for innovation, even though none of the working group members were able to note a set of circumstances under which this innovation might take place. So, in an effort to stop the email storm, the authors added the additional code point." >=20 Stan On Oct 14, 2012, at 6:01 AM, Henning Rogge wrote: > I think the idea is not bad. >=20 > IF we decide to use a special codepoint for "unknown TLV value", using > "length =3D 0" would give us a generic way for doing it for all kind = of > additional metric TLVs... instead of doing this "what to use for > UNKNOWN" brainstorming again. >=20 > It also makes it easier to include the UNKNOWN codepoint into metrics > which have no bits/values left. >=20 > Henning Rogge >=20 > On Sat, Oct 13, 2012 at 5:06 PM, Bo Berry wrote: >> Teco >> Thanks, this helps. So let's see what others think. >> Have a great wkend. >>=20 >> -Bo >>=20 >>=20 >> On Oct 13, 2012, at 10:50 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 13 okt. 2012, om 16:26 heeft Bo Berry het volgende geschreven: >>>=20 >>>> Teco, >>>> I do not understand it and it's not been described in a manner >>>> that I can. But if we can not understand it, we will not be >>>> successful describing it such that it can be useful. >>>>=20 >>>> If you can provide meaningful, descriptive text, that would help. >>>> At this time, "prepare for data items that can fall back to unknown" >>>> does not help me. What do you propose as optional data items >>>> and how do you propose, by what mechanism, they fall back? Do >>>> they fall back in the radio or router, or both? >>>=20 >>> The optional Data Item TLVs for Neighbor Up are in the draft: >>> - IPv4 Address >>> - IPv6 Address >>> - Maximum Data Rate >>> - Current Data Rate >>> - Latency >>> - Expected Forwarding Time >>> - Resources >>> - Relative Link Factor >>> - Credit Window Status >>> Neighbor Up messages would be send by router, although the draft >>> mentions the router can send it also. >>> Relative Link Factor should be Relative Link Quality (posted before, >>> I think). In Neighbor Update, Expected Forwarding Time is missing. >>>=20 >>> My comment is on the protocol. Optional data item TLVs can be present, >>> or not. There was a proposal for TLV with an UNKNOWN codepoint, for RLQ. >>> I don't see much difference in UNKNOWN and not sending the TLV. Then, >>> this UNKNOWN applies to all optional Data Item TLVs. So if we just >>> add a mechanism that enables sending UNKNOWN for all optional Data >>> Item TLVs, we are done. Addresses have the drop already. The other >>> TLVs can have the length=3D0. That's all. I provided the text = already. >>>=20 >>> I can't be more clear. Sorry. >>>=20 >>> Teco >>>=20 >>>>=20 >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 13, 2012, at 9:14 AM, Teco Boot wrote: >>>>=20 >>>>> DLEP is (mainly) getting the neighbor information base from radio to >>>>> router, as accurate as possible. It is up to the router to use this for >>>>> route calculation. >>>>>=20 >>>>> This discussion is not about using RFC 5444. >>>>>=20 >>>>> It is about transfer of "hey there, I don't have this info anymore". >>>>> Bo and Stan say, this is not needed. Others say, there is a need for it. >>>>> I agree with the others, because I cannot see a reason a radio is only >>>>> allowed *once* during neighbor_up state to miss data items. We better >>>>> prepare for data items that can fall back to unknown. I say: let's allow >>>>> this for all optional data items. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>> Op 13 okt. 2012, om 14:02 heeft Abdussalam Baryun het volgende geschreven: >>>>>=20 >>>>>> I agree we should design for the present MANET technologies and >>>>>> future, for the protocol completion. Do you mean router-state as the >>>>>> DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don't >>>>>> understand why we need to consider router states. >>>>>>=20 >>>>>> DLEP considers the session between server and client states, other >>>>>> states are not inscope. For simplicity, DLEP should be abstract from >>>>>> MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an >>>>>> optional future interaction may be useful but complicated (will need >>>>>> RFC5444). >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>> On 10/13/12, Teco Boot wrote: >>>>>>>=20 >>>>>> My point is that the DLEP protocol should be "complete", in that the >>>>>> radio is able to get the router in a certain state, in another state >>>>>> and get back in the earlier state. RLQ is just an example. >>>>>>=20 >>>>>> If you think this makes no sense with the radios you have seen up to >>>>>> now, you could be right. Tomorrow, you could have a different opinion. >>>>>> I saw on this mailing list some of us see already the requirement the >>>>>> protocol shall be "complete". >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From l.wood@surrey.ac.uk Tue Oct 23 06:56:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCBF21F8602 for ; Tue, 23 Oct 2012 06:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.536 X-Spam-Level: X-Spam-Status: No, score=-4.536 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjzNB0WXx1lU for ; Tue, 23 Oct 2012 06:56:15 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id B3F7921F85EA for ; Tue, 23 Oct 2012 06:56:14 -0700 (PDT) Received: from [195.245.231.67:48060] by server-5.bemta-5.messagelabs.com id BD/ED-09732-DF1A6805; Tue, 23 Oct 2012 13:56:13 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-8.tower-82.messagelabs.com!1351000572!40990203!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25323 invoked from network); 23 Oct 2012 13:56:12 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-8.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 23 Oct 2012 13:56:12 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.240]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Tue, 23 Oct 2012 14:56:12 +0100 From: To: , , Date: Tue, 23 Oct 2012 14:54:49 +0100 Thread-Topic: [manet] DLEP and modem Link Property Advertisements Thread-Index: Ac2xEU/R3uGo7ctYSGCrLwDvHGNVbwAFKeVB Message-ID: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F41F21D@xmb-aln-x03.cisco.com>, <1195C440-820A-413C-B76A-96F3373EE567@inf-net.nl> In-Reply-To: <1195C440-820A-413C-B76A-96F3373EE567@inf-net.nl> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:56:16 -0000 You might also be interested in our related IEEE Aerospace paper on modem l= ink property advertisements, which provides a bit of context http://personal.ee.surrey.ac.uk/Personal/L.Wood/router-modem-integration/ Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Teco Boo= t [teco@inf-net.nl] Sent: 23 October 2012 12:26 To: Stan Ratliff (sratliff); Ivancic, William D. (GRC-RHN0) Cc: List Subject: Re: [manet] DLEP and modem Link Property Advertisements I support this DLEP-lite idea. I have to deal security requirements with strong border protection, where the inner (red) network would benefit form feedback from the outer (black) network. Using data diode is more easy to deploy than a secured gateway. So a pure uni-directional feed would help getting data through a diode. Teco Op 22 okt. 2012, om 22:02 heeft Stan Ratliff (sratliff) het volgende geschr= even: > Will, > > If you have some time, I'd like to meet with you and discuss "DLEP-lite". > > Regards, > Stan > > On Oct 22, 2012, at 3:10 PM, Ivancic, William D. (GRC-RHN0) wrote: > >> A few months ago (time flies), the authors of modemLPA have been in d= iscussion with the authors of >> "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] to >> determine if DLEP will fullfil the needs that ModemLPA is targeted >> at. DLEP is currently a client/server session oriented protocol that >> provides link layer information to directly connected devices - >> generally routers. The Modem Link Property Advertisment protocol >> broadcasts link status notifications to directly-attached devices and >> devices or applications that may be multiple hops away from the modem >> (or other sending device). >> >> It should be possible to use the DLEP message formats without all the >> signalling required for the DLEP client/server session to perform the >> functions addressed in this draft. The modem would simply provide >> link states out via multicast or unicast UDP datagrams (DLEP-Lite). >> Whether or not this is a good idea, or acceptable to the manet group, >> is yet to be determined. >> >> In the mean time, This modemLPA document was originally submitted to the= IRTF mobopts research group as an individual submission draft-ivancic-mobo= pts-modemlpa-01. That research group as recently closed down. I am lookin= g for a new place to put updates until a decision is made on DLEP-Lite. Is = the manet group the right place? I really don't know if this is the right = group or if someplace else may be more appropriate. I see no other working= groups or research groups really looking at layer-2 triggers. >> >> Finally: >> A PERL script, modem-LPA-packetgen.pl >> , has been placed in sourceforge >> as open source software. The PERL script generates modemLPA packets >> base on the modem link property advertisement draft, >> "draft-ivancic-mobopts-modemlpa-01". >> >> The script was used to demonstrate modemLPA by controlling the rate >> on a file transfer protocol. The file transfer protocol used was >> Saratoga and is implemented in a PERL script. The Saratoga PERL >> script is available on SourceForge. Search for saratoga and the >> script will be in the directory saratoga-v1-perl. >> >> This script and the Saratoga implementation currently use a multicast >> address of 226.1.1.2. The all routers address of 224.0.0.2 is >> suppose to be used, but the particular Linux machines we where >> running on did not want to pass 224.0.0.2 and we did not have >> sufficient time to determine why. >> >> Eventually, we hope to include code for GNU radios that implement >> modemLPA (Or perhap DLEP-lite). >> >> Code is available for modemLPA from >> >> http://sourceforge.net/projects/modemlpa/ >> >> >> Code is available for Saratoga from >> >> http://saratoga.cvs.sourceforge.net/viewvc/saratoga/ >> >> I am currently planning on attending the IETF meetings in Atlanta. >> - Will Ivancic >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Tue Oct 23 07:32:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AEF21F8659 for ; Tue, 23 Oct 2012 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua7STxf15hR3 for ; Tue, 23 Oct 2012 07:32:41 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A3DC821F8563 for ; Tue, 23 Oct 2012 07:32:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,635,1344207600"; d="scan'208";a="280513042" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Oct 2012 15:32:39 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9NEWdYa016221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 15:32:39 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Tue, 23 Oct 2012 15:32:38 +0100 From: "Dearlove, Christopher (UK)" To: "Ralph Droms (rdroms)" , manet Thread-Topic: [manet] AD review of draft-kelsey-intarea-mesh-link-establishment Thread-Index: AQHNsH4Mcc+BCVRJaEODfuq8NgAuAJfG7M9A Date: Tue, 23 Oct 2012 14:32:38 +0000 Message-ID: References: <4518F39EB578034D8C99A9B7776CDBA32660B5@xmb-aln-x04.cisco.com> In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA32660B5@xmb-aln-x04.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] AD review of draft-kelsey-intarea-mesh-link-establishment X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:32:42 -0000 Reading the Introduction to this draft, I don't accept the description of N= HDP (RFC 6130) that it gives. NHDP does not "recommend that messages are se= nt over secured links", nor does it use "already-configured links" (of cour= se it could, but that's not the universal use case). The document claims to go further than NHDP by making initialisation of lin= k-layer security a main function. But distribution and derivation of keys i= s explicitly excluded. That really rather makes this pointless - key distri= bution is the hard part, and the issues of key management in a less-managed= network (which is what an ad hoc - or mesh if the authors prefer the term = - network wants to be) are the real problem - and impacts on the rest of yo= ur solution. This gets something of the worst of both worlds of not doing s= ecurity while claiming to do security. Furthermore "secured as described in= 802.15.4" does not answer all the questions I would have. This is why NHDP= does not do security itself - which is not the same as saying use secured = links, an RFC 6622-based solution may be used for example (and given time a= nd support I'd like to define one for NHDP+OLSRv2, but that's another matte= r). Half a solution constrains but does not help. I would appreciate background here - is this an attempt to put what is a co= mpeting proprietary protocol onto the Standards Track without any of the pr= oper discussion in the relevant WGs (this one for a start) prior to IETF LC= ? Has it any wider support than one company? Any implementations? Incidentally, the main reason this draft can be simpler than NHDP is that i= t doesn't handle multiple interfaces, or multiple addressing, which are the= major sources of complexity in NHDP. Also the document is pretty much abse= nt on the issue of how data should be recorded (which it must be if to be u= sed - by what?) and on its assumed validity time, timeouts etc. In short, I think that the status of this document needs reviewing, why sho= uld it be on the Standards Track and why has it bypassed WGs, and that (pro= bably not coincidentally) it lacks the attention to detail that WG document= s don't progress without. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of R= alph Droms (rdroms) Sent: 22 October 2012 18:53 To: manet Subject: [manet] AD review of draft-kelsey-intarea-mesh-link-establishment ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I've been asked to sponsor draft-kelsey-intarea-mesh-link-establishment as = an AD-sponsored individual submission. As part of my AD review of the docu= ment, I'm soliciting input from a variety of relevant communities, includin= g the manet WG. I expect to complete my review next week and then send the document out for= IETF last call. Please respond with comments by next Monday, Oct 29, eith= er to the mailing list or directly to me. I'm aware that the last call wi= ll overlap the IETF meeting in Atlanta but it will be a four week last call= , which should be enough for reviewing this document. - Ralph _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Tue Oct 23 08:20:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98B711E80E0 for ; Tue, 23 Oct 2012 08:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4zUfKZRe2aR for ; Tue, 23 Oct 2012 08:19:59 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 159F711E80DC for ; Tue, 23 Oct 2012 08:19:59 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1965094dan.31 for ; Tue, 23 Oct 2012 08:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=ACEwmC1FDfR1ZoAVvOoDnB3/1pGow1UOUzt+kThBhcM=; b=vTGD1DsuoArF7T5Rbj2jN2zjwM88KEHQJ097Tp9qY3CIlszOvSL/NRmRsmWg+PhFW9 ZrbJQeR5jRMbkZVLE0TZkdHUnxLKDOwGEHjbyzSj07itW5FdBZX5JQAyp5COAUkcjtt5 cmODaolkTxtL22vaItd3haOVskNTmCYzPiGSk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=ACEwmC1FDfR1ZoAVvOoDnB3/1pGow1UOUzt+kThBhcM=; b=n/hLfuQJYSsJRy247lJ1YWXZ7sLlmSfDjpe3ITjH/n+BHbVqF65dBgV8y465k1lmyv 7P4A/bI1U0LYnRX27JXgi2rk5+bDpKLTQ9sAuAFdmboajqRXxDTtLFmlemGWHmBSKOKm PP+pSLsMlylfp0j6MKT4AqAC51LsdfbqreGOkjJVI1gg1u3X+DCmaF8vhntAtJq81nKj ZXthGXJmSToTpP9lVApJbV/jkTZ3Om4d0G0xagH5XwBqyWh3JHZFub8pEGWASb85xlyA 6FWNa43kh1E8U0sOLOLSN2K2CdMf1OMIYeAPrnbe7VHkWmXHOGMHrvpxJOHtYJmAv4MS TcKA== Received: by 10.68.219.5 with SMTP id pk5mr3614965pbc.124.1351005598817; Tue, 23 Oct 2012 08:19:58 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id k4sm7861169pax.7.2012.10.23.08.19.56 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 08:19:57 -0700 (PDT) References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <03B78081B371D44390ED6E7BADBB4A7722014627@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722014627@xmb-rcd-x02.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-3F1008DE-0D2B-44BB-92A0-C23164A50194 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Tue, 23 Oct 2012 08:19:56 -0700 To: "JP Vasseur (jvasseur)" X-Gm-Message-State: ALoCoQkrPuTbtPqcAB3GSVmvKzm4P/hz4ItMRcXwBYAB1/A2eNDOETojzRs6pPUdI05ZNBT0/4Hz Cc: "" , "Bo Berry \(boberry\)" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:20:00 -0000 --Apple-Mail-3F1008DE-0D2B-44BB-92A0-C23164A50194 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi JP, I was about to write a more detailed answer and then decided against it. Bo a= sked a technical question, to which I replied. Let's wait what the chairs sa= y, then I may answer to your points. Best Ulrich On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" wrote= : > Dear Ulrich, >=20 > Let me chine in since I do not think that we are in agreement with your co= nclusions here - see below >=20 > On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote: >=20 >> Hi Bo, >>=20 >> On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry wrote: >>> Hi Alex >>>=20 >>> For those of us that have not have the opportunity to follow >>> the Loadng discussions, could you please describe the similarities >>> and the unique differences of Loadng relative to Dymo. I'm aware >>> of the discussions about lousy nets and manets, but less between >>> the two protocols. >>>=20 >>> I think this would help everyone on the WG understand the benefits. >>=20 >>=20 >> I agree with that, and it is a fair question to ask. Let me try to list a= few differences, others may chime in with more.=20 >>=20 >> First the commonalities: >> - Both are reactive protocols, based on AODV, with the intended status o= f "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that= the WG has to come up with a std. track reactive protocol. Essentially, in a= reactive protocol, routes are requested "on-demand" (i.e. when there is dat= a traffic and no route exists for the destination of the data packet). There= fore, you will see similar message types in both protocols (Route Requests, R= oute Replies, and Route Errors), and essentially the same basic mechanism. >=20 > JP> It is worth that MANET has already a WG document, DYMO, which has been= discussed extensively in the WG. >=20 >> - Both are applicable to MANETs (see also below for your next question), a= nd both support RFC5444. LOADng is decoupling the mechanism from the message= format; RFC5444 is mapped to the mechanism, but other message formats could= easily be specified (e.g., with a more compressed message format for extrem= ely limited links in terms of bandwidth). >>=20 >> Now some differences: >> - Most importantly: LOADng has achieved what DYMO failed to do: to gather= broad industrial support from several large companies, several large-scale d= eployments with several thousands of nodes, LOADng has an updated MIB docume= nt, and documented interoperability test of at least four recent implementa= tions. >=20 > JP> If I may, this is more of a Marketing comment though. I do not think t= hat DYMO failed in any way. It turns out that the timing was different, that= 's all. >=20 >> - Part of the reason, I believe, is that the writing style is very differ= ent. LOADng has a more algorithmic way of writing. That's immediate to see w= hen you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, m= uch harder to implement DYMO. The goal for LOADng was to make it so straight= forward to implement that an undergrad student could take the spec, spend a= few days implementing it and have a reasonable and interoperable implementa= tion. I have implemented LOADng in one day, based on the specification. >=20 > JP> I personally saw several implementations of DYMO, and if we require mo= re algorithmic details about DYMO, let's provide comments to the DYMO > authors. >=20 >> - There are multiple optional features in DYMO that have deliberately not= been included in LOADng (expanding ring multicasts, intermediate RREPs, pre= cursor lists etc). The reason was the following: in an experimental protocol= (AODV) it is fine to have many options, in order to explore whether they ar= e useful. We have that experience now with AODV. For some of the options, su= ch as iRREP, it has not been shown over the last decade that they are of gen= eral use. In some cases, they may be beneficial, but not in general. Also, t= hey make it very hard to provide end-to-end security. LOADng kept the mantra= of a small, slim, and efficient protocol. Having many options makes it hard= to assure interoperable devices out of the box, in particular if there is n= o negotiation of capabilities. >> Moreover, reactive protocols are often used in cases where memory is an e= xtremely scarce resource, and where proactive protocols cannot be used. That= makes a slim design preferable, IMO, for such protocols. >=20 > JP> We can discuss further in Atlanta, but several of these options are IM= O quite useful. >=20 >> - LOADng may be used in other layers as L3, e.g. as mesh-under protocol. >=20 > JP> Another concern =E2=80=A6 If you plan using LOAD-ng as a mesh under pr= otocol, this requires much more discussion (not sure that such discussions > should take place at the IETF, but because this would be an IETF work, we w= ould need to discuss it further). Indeed, proposing to standardize a > mesh-under protocol is not just a matter of manipulating MAC addresses ins= tead of IP addresses: there are tons of implications of the architecture, > as described in details in http://tools.ietf.org/html/draft-routing-archit= ecture-iot-00 >=20 >> - LOADng supports optimized broadcasting mechanisms such as MPR flooding >> - There is no Route Reply ACK in DYMO; this is part of LOADng to verify b= idirectionality of links; as in wireless channels, links are rarely symmetri= c.=20 >=20 > JP> Let's discuss further about these optimizations, which if needed, coul= d be added to DYMO. >=20 >>>=20 >>> Looking at the Tools page, the draft was first submitted October 24, 201= 1, >>> draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc >>> Distance-vector Routing Protocol - Next Generation (LOADng)." The >>> abstract included the statement "The protocol is derived >>> from AODV and extended for use in LLNs". >>>=20 >>> Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the >>> line "The protocol is derived from AODV (RFC3561) and extended for >>> use in LLNs." was removed. This version also supported RFC 5444. >>>=20 >>> The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06,= >>> for the most part changes "Low power and Lossy Networks (LLN)" >>> references to "Mobile Ad hoc NETworks (MANETs)." >>=20 >>=20 >> The draft started out from where the deployments exist, which some call L= LNs. >=20 > JP> As pointed out earlier, then I have two major concerns: > 1) If the reactive routing protocol deals with LLNs, especially "hard cons= trained" LLNs as pointed out in this mailing list, > then I would strongly suggest to run the document by the two WGs, MANET an= d ROLL. Let's see what the chairs decides. > 2) ROLL co-chair hat-off, I do see a number of issues using reactive routi= ng in hard constrained LLNs such as AMI PLC, > years of experience in routing in such networks show us that there are maj= or scalability issues (I am not referring to the number > of nodes, but also user traffic since depending on the user traffic this m= ay lead to massive control plane traffic churn to mention > one of the many issues). >=20 >> However, as a basic reactive protocol, LOADng also covers the more genera= l MANET case that includes a wider ranger of resources (from extremely const= rained to not-so-constrained) and mobility. In particular, by supporting RFC= 5444 it fits well in the MANET architecture and the surrounding security ext= ensions, flooding optimizations and TLVs etc. for RFC5444. >>=20 >> I hope I could shed some light on that question. I invite you to read bot= h drafts, there is probably more to say here. >>=20 >> I won't go into details here, but most of the discussions we had were not= so much about technical issues, but about procedural. LOADng has started wh= en DYMO was stalled for more than 2 years. I think we have a well mature doc= ument, supported by strong industry backing and running code. >=20 > JP> I do not make this email took polemical but you also have strong indus= try disagreement in using such protocols for extremely > constrained LLNs to say the least. >=20 > Thanks. >=20 > JP. >=20 >> The latter is crucial in the IETF. >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> =20 >>>=20 >>> Thanks >>> -Bo >>>=20 >>>=20 >>>=20 >>> On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=C3=A8re wrote: >>>=20 >>> > Dear all, >>> > >>> > we have updated LOADng, to make it clear that it is in scope and chart= er for MANET. Unfortunately, it is only a minor revision of the technical co= ntent, since we have been in discussions with the DYMO authors and the WG le= adership for several months on how to proceed with the reactive protocol in M= ANET. The chairs will likely reply very soon to the list with an outcome of t= he discussion. >>> > >>> > Best regards, >>> > >>> > Axel Colin de Verdiere >>> > >>> > _______________________________________________ >>> > manet mailing list >>> > manet@ietf.org >>> > https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-3F1008DE-0D2B-44BB-92A0-C23164A50194 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi JP,

I was a= bout to write a more detailed answer and then decided against it. Bo asked a= technical question, to which I replied. Let's wait what the chairs say, the= n I may answer to your points.

Best
Ulric= h

On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Dear Ulrich,

Let me chine in since I do not think that we are in agreement with your= conclusions here - see below

On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote:

Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry <boberry@cisco.com= > wrote:
Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities
and the unique differences of Loadng relative to Dymo.  I'm aware
of the discussions about lousy nets and manets, but less between
the two protocols.

I think this would help everyone on the WG understand the benefits.


I agree with that, and it is a fair question to ask. Let me try to list= a few differences, others may chime in with more. 

First the commonalities:
 - Both are reactive protocols, based on AODV, with the intended s= tatus of "Proposed Standard" (AODV is "Experimental"). The MANET charter lis= ts that the WG has to come up with a std. track reactive protocol. Essential= ly, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and no route exi= sts for the destination of the data packet). Therefore, you will see similar= message types in both protocols (Route Requests, Route Replies, and Route E= rrors), and essentially the same basic mechanism.

JP> It is worth that MANET has already a WG document, DYMO, which ha= s been discussed extensively in the WG.

- Both are applicable to MANETs (see also below for your next question)= , and both support RFC5444. LOADng is decoupling the mechanism from the mess= age format; RFC5444 is mapped to the mechanism, but other message formats co= uld easily be specified (e.g., with a more compressed message format for extremely limited links in terms o= f bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to gath= er broad industrial support from several large companies, several large-scal= e deployments with several thousands of nodes, LOADng has an updated MIB doc= ument, and documented interoperability test of at least four recent implementations.

JP> If I may, this is more of a Marketing comment though. I do not t= hink that DYMO failed in any way. It turns out that the timing was different= , that's all.

- Part of the reason, I believe, is that the writing style is very diff= erent. LOADng has a more algorithmic way of writing. That's immediate to see= when you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO,= much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that an= undergrad student could take the spec, spend a few days implementing it and= have a reasonable and interoperable implementation. I have implemented LOAD= ng in one day, based on the specification.

JP> I personally saw several implementations of DYMO, and if we requ= ire more algorithmic details about DYMO, let's provide comments to the DYMO<= /div>
authors.

- There are multiple optional features in DYMO that have deliberately n= ot been included in LOADng (expanding ring multicasts, intermediate RREPs, p= recursor lists etc). The reason was the following: in an experimental protoc= ol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that exp= erience now with AODV. For some of the options, such as iRREP, it has not be= en shown over the last decade that they are of general use. In some cases, t= hey may be beneficial, but not in general. Also, they make it very hard to provide end-to-end security. LO= ADng kept the mantra of a small, slim, and efficient protocol. Having many o= ptions makes it hard to assure interoperable devices out of the box, in part= icular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is an= extremely scarce resource, and where proactive protocols cannot be used. Th= at makes a slim design preferable, IMO, for such protocols.

JP> We can discuss further in Atlanta, but several of these options a= re IMO quite useful.

- LOADng may be used in other layers as L3, e.g. as mesh-under protocol= .

JP> Another concern =E2=80=A6 If you plan using LOAD-ng as a mesh un= der protocol, this requires much more discussion (not sure that such discuss= ions
should take place at the IETF, but because this would be an IETF work, w= e would need to discuss it further). Indeed, proposing to standardize a
mesh-under protocol is not just a matter of manipulating MAC addresses i= nstead of IP addresses: there are tons of implications of the architecture,<= /div>
- LOADng supports optimized broadcasting mechanisms such as MPR floodin= g
- There is no Route Reply ACK in DYMO; this is part of LOADng to v= erify bidirectionality of links; as in wireless channels, links are rarely s= ymmetric. 
 

JP> Let's discuss further about these optimizations, which if needed= , could be added to DYMO.


Looking at the Tools page, the draft was first submitted October 24, 2011, draft-clausen-lln-loadng-00.  The title was, "The LLN On-demand Ad hoc<= br> Distance-vector Routing Protocol - Next Generation (LOADng)."  The
abstract included the statement "The protocol is derived
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for
use in LLNs." was removed.  This version also supported RFC 5444.

The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06,
= for the most part changes "Low power and Lossy Networks (LLN)"
references to "Mobile Ad hoc NETworks (MANETs)."


The draft started out from where the deployments exist, which some call= LLNs.

JP> As pointed out earlier, then I have two major concerns:
1) If the reactive routing protocol deals with LLNs, especially "hard c= onstrained" LLNs as pointed out in this mailing list,
then I would strongly suggest to run the document by the two WGs, MANET= and ROLL. Let's see what the chairs decides.
2) ROLL co-chair hat-off, I do see a number of issues using reactive ro= uting in hard constrained LLNs such as AMI PLC,
years of experience in routing in such networks show us that there are m= ajor scalability issues (I am not referring to the number
of nodes, but also user traffic since depending on the user traffic thi= s may lead to massive control plane traffic churn to mention
one of the many issues).

However, as a basic reactive protocol, LOADng also covers the more gene= ral MANET case that includes a wider ranger of resources (from extremely con= strained to not-so-constrained) and mobility. In particular, by supporting R= FC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimization= s and TLVs etc. for RFC5444.

I hope I could shed some light on that question. I invite you to read b= oth drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had were n= ot so much about technical issues, but about procedural. LOADng has started w= hen DYMO was stalled for more than 2 years. I think we have a well mature do= cument, supported by strong industry backing and running code.

JP> I do not make this email took polemical but you also have strong= industry disagreement in using such protocols for extremely
constrained LLNs to say the least.

Thanks.

JP.

The latter is crucial in the IETF.

Best regards
Ulrich


 

Thanks
-Bo



On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=C3=A8re wrote:

> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and charte= r for MANET. Unfortunately, it is only a minor revision of the technical con= tent, since we have been in discussions with the DYMO authors and the WG lea= dership for several months on how to proceed with the reactive protocol in MANET. The chairs will likely repl= y very soon to the list with an outcome of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

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

= --Apple-Mail-3F1008DE-0D2B-44BB-92A0-C23164A50194-- From ulrich@herberg.name Tue Oct 23 08:24:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D800C21F85D5 for ; Tue, 23 Oct 2012 08:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPXhxsQiev4X for ; Tue, 23 Oct 2012 08:24:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3FB21F85E2 for ; Tue, 23 Oct 2012 08:24:22 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so519359pbb.31 for ; Tue, 23 Oct 2012 08:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=LAhB4lY/ghfU+/cS0y/hQxbJU/xxK3o8swqn9Vzo65o=; b=TreIqbzIK5COwl54aUv7JJkWwk52AbdH86ydtwzB2j/XAP4ht4c5ChdxefPAsJLQfm 4RU52O3/7i7J9mjwaKqdRIEVYgoVxjbJEA29FXX7cccWPWcZIp9BWLGpGSOGPEDjO/+P uqVGqnTSXXMjpICEw7PdkD/IAG9oXUTEvGfn4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=LAhB4lY/ghfU+/cS0y/hQxbJU/xxK3o8swqn9Vzo65o=; b=L7lmtf3MnYWDyiliQEqQ40tzJlsY9XNgQ3G9JnWtnNUaTjPP4tjUydBcdH47MQEp0v bldvqcLO5ARawM4JziYhhI4gLHVrb5rEHUpRkPOwauHJYlev6k70xqzItGTots29Cytv yCH6TBDQDskXtmc1DoR+8qdSksoj0fUTdifhssXt3q4uK3nqwN7ENSSXkON3lGHlyNpE I6rBadFfWo30VU+TCMrSrlPOuAvqhFp7oCE32j1c7J9KOORMlje9liLAIUn2eOZZVmpf dtuy0/oW6E+q0awK6NV6oS70WK+RJ+buSyCnDqKGHsEe3kuKNX7VQV5LTHk1VlL8ZcgC pkjA== Received: by 10.68.138.198 with SMTP id qs6mr41246778pbb.151.1351005858835; Tue, 23 Oct 2012 08:24:18 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id un16sm7845567pbc.47.2012.10.23.08.24.17 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 08:24:18 -0700 (PDT) References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Tue, 23 Oct 2012 08:24:16 -0700 To: Bo Berry X-Gm-Message-State: ALoCoQnHlQ5+HLJMS+hwFPTJ0awS1vbgcdLVfQ4qV+PHmgLfMLoqq5PUvD6iv3jUTzVyeeTRGjNV Cc: "" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:24:36 -0000 Bo, On Oct 23, 2012, at 4:38, Bo Berry wrote: >=20 > On Oct 22, 2012, at 10:49 PM, Ulrich Herberg wrote: >=20 >> Hi Bo, >>=20 >> On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry wrote: >> Hi Alex >>=20 >> For those of us that have not have the opportunity to follow >> the Loadng discussions, could you please describe the similarities >> and the unique differences of Loadng relative to Dymo. I'm aware >> of the discussions about lousy nets and manets, but less between >> the two protocols. >>=20 >> I think this would help everyone on the WG understand the benefits. >>=20 >>=20 >> I agree with that, and it is a fair question to ask. Let me try to list a= few differences, others may chime in with more.=20 >>=20 >> First the commonalities: >> - Both are reactive protocols, based on AODV, with the intended status of= "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that t= he WG has to come up with a std. track reactive protocol. Essentially, in a r= eactive protocol, routes are requested "on-demand" (i.e. when there is data t= raffic and no route exists for the destination of the data packet). Therefor= e, you will see similar message types in both protocols (Route Requests, Rou= te Replies, and Route Errors), and essentially the same basic mechanism. >> - Both are applicable to MANETs (see also below for your next question), a= nd both support RFC5444. LOADng is decoupling the mechanism from the message= format; RFC5444 is mapped to the mechanism, but other message formats could= easily be specified (e.g., with a more compressed message format for extrem= ely limited links in terms of bandwidth). >>=20 >> Now some differences: >> - Most importantly: LOADng has achieved what DYMO failed to do: to gather= broad industrial support from several large companies, several large-scale d= eployments with several thousands of nodes, LOADng has an updated MIB docume= nt, and documented interoperability test of at least four recent implementat= ions. >> - Part of the reason, I believe, is that the writing style is very differ= ent. LOADng has a more algorithmic way of writing. That's immediate to see w= hen you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, m= uch harder to implement DYMO. The goal for LOADng was to make it so straight= forward to implement that an undergrad student could take the spec, spend a= few days implementing it and have a reasonable and interoperable implementa= tion. I have implemented LOADng in one day, based on the specification. >> - There are multiple optional features in DYMO that have deliberately not= been included in LOADng (expanding ring multicasts, intermediate RREPs, pre= cursor lists etc). The reason was the following: in an experimental protocol= (AODV) it is fine to have many options, in order to explore whether they ar= e useful. We have that experience now with AODV. For some of the options, su= ch as iRREP, it has not been shown over the last decade that they are of gen= eral use. In some cases, they may be beneficial, but not in general. Also, t= hey make it very hard to provide end-to-end security. LOADng kept the mantra= of a small, slim, and efficient protocol. Having many options makes it hard= to assure interoperable devices out of the box, in particular if there is n= o negotiation of capabilities. >> Moreover, reactive protocols are often used in cases where memory is an e= xtremely scarce resource, and where proactive protocols cannot be used. That= makes a slim design preferable, IMO, for such protocols. >> - LOADng may be used in other layers as L3, e.g. as mesh-under protocol. >> - LOADng supports optimized broadcasting mechanisms such as MPR flooding >> - There is no Route Reply ACK in DYMO; this is part of LOADng to verify b= idirectionality of links; as in wireless channels, links are rarely symmetri= c.=20 >>=20 >>=20 >> Looking at the Tools page, the draft was first submitted October 24, 2011= , >> draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc >> Distance-vector Routing Protocol - Next Generation (LOADng)." The >> abstract included the statement "The protocol is derived >> from AODV and extended for use in LLNs". >>=20 >> Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the >> line "The protocol is derived from AODV (RFC3561) and extended for >> use in LLNs." was removed. This version also supported RFC 5444. >>=20 >> The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, >> for the most part changes "Low power and Lossy Networks (LLN)" >> references to "Mobile Ad hoc NETworks (MANETs)." >>=20 >>=20 >> The draft started out from where the deployments exist, which some call L= LNs. However, as a basic reactive protocol, LOADng also covers the more gene= ral MANET case that includes a wider ranger of resources (from extremely con= strained to not-so-constrained) and mobility. In particular, by supporting R= FC5444 it fits well in the MANET architecture and the surrounding security e= xtensions, flooding optimizations and TLVs etc. for RFC5444. >=20 > When you say, "draft started out from where the deployments exist", > where these implementations DYMO, which draft? Sorry that I was unclear, I meant LOADng. >=20 > Since 5444 was just added to the Loadng draft, is there an implementation u= sing 5444? Other authors may be more knowledgeabe to reply to this. Note that RFC5444 i= s decoupled from the core protocol mechanism. >=20 >=20 >> I hope I could shed some light on that question. I invite you to read bot= h drafts, there is probably more to say here. >>=20 >> I won't go into details here, but most of the discussions we had were not= so much about technical issues, but about procedural. LOADng has started wh= en DYMO was stalled for more than 2 years. I think we have a well mature doc= ument, supported by strong industry backing and running code. The latter is c= rucial in the IETF. >=20 > I'm curious why the Loadng effort did not/could not work through the WG to= re-invigorate the DYMO discussions.=20 >=20 >=20 > January 2005 - draft-ietf-manet-dymo-00 > - Mobile Ad hoc Networks Working Group > - Expires: July 5, 2005 >=20 > ... several draft updates ... >=20 > December 5, 2008 - draft-ietf-manet-dymo-16 >=20 > March 8, 2009 - draft-ietf-manet-dymo-17 > - Expires: September 9, 2009 >=20 > February 23, 2010 - draft-ietf-manet-dymo-18 > - Expires: August 27, 2010 > - This draft included RFC5444 formatting >=20 > March 22, 2010 - draft-ietf-manet-dymo-19 > - Expires: September 23, 2010 >=20 > July 10, 2010 - draft-ietf-manet-dymo-20 >=20 > July 26, 2010 - draft-ietf-manet-dymo-21 > - Expires: January 27, 2011 >=20 > *October 24, 2011 - draft-clausen-lln-loadng-00 > - Title: The LLN On-demand Ad hoc Distance-vector > Routing Protocol - Next Generation (LOADng) > - Abstract: This document describes the LLN Ad hoc On-Demand (LOAD) dis= tance > vector routing protocol, a reactive routing protocol intended for use= > in Low power Lossy Networks (LLN). The protocol is derived from AODV= > and extended for use in LLNs. >=20 > *October 31, 2011 - draft-clausen-lln-loadng-01 >=20 > March 12, 2012 - draft-ietf-manet-dymo-22 > - Expires: September 13, 2012 > - Rebranding the protocol was included: > Dynamic MANET On-demand (AODVv2) Routing >=20 > *March 12, 2012 - draft-clausen-lln-loadng-02 >=20 > *March 29, 2012 - draft-clausen-lln-loadng-03 >=20 > *April 22, 2012 - draft-clausen-lln-loadng-04 >=20 > *July 14, 2012 - draft-clausen-lln-loadng-05 > - C. Perkins, Futurewei Inc. was added as a co-author > - This line was removed from the Abstract: "The protocol > is derived from AODV (RFC3561) and extended for use in LLNs." > - This draft included RFC5444 formatting >=20 > October 23, 2012 - draft-ietf-manet-dymo-23=20 >=20 > *October 22, 2012 - draft-clausen-lln-loadng-06 > - Added J. Dean from Naval Research Laboratory I was replying to your technical questions, but prefer not to go into histor= y until the chairs reply. Best regards Ulrich >=20 >=20 >=20 >>=20 >> Best regards >> Ulrich >>=20 >>=20 >>=20 >>=20 >> Thanks >> -Bo >>=20 >>=20 >>=20 >> On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=C3=A8re wrote: >>=20 >>> Dear all, >>>=20 >>> we have updated LOADng, to make it clear that it is in scope and charter= for MANET. Unfortunately, it is only a minor revision of the technical cont= ent, since we have been in discussions with the DYMO authors and the WG lead= ership for several months on how to proceed with the reactive protocol in MA= NET. The chairs will likely reply very soon to the list with an outcome of t= he discussion. >>>=20 >>> Best regards, >>>=20 >>> Axel Colin de Verdiere >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From hrogge@googlemail.com Tue Oct 23 08:38:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E92621F86B4 for ; Tue, 23 Oct 2012 08:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sMoY4FGFZam for ; Tue, 23 Oct 2012 08:38:07 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 195E221F86B3 for ; Tue, 23 Oct 2012 08:38:07 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1972411dan.31 for ; Tue, 23 Oct 2012 08:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Xbnrat4oL9nIIyBSklZX1Jbv4/x2TMuFd1DhM960NQI=; b=oUAdaaDscFfQYhPiYBpSPqlqSiPS0dvaofPFiBOaBvEJhwLu02z/cIbnAcX5w/Nehu cxquH2tWBQHaAbwZKd9ilb42f6h4QpPDjxVmyH6YfO8VnB+LBrjql1/TIel89FIPnWjb 0nych3/ydNt+9DgQH7H9wRPB6U7rliYWjGxS/sSbHFbEfnIBSCNcAAEMw3Ac9EU/geXK qlW8SOOEguYVCxaOzgFgQVr1WgnMOJrwp2xtb8O6ewBCn+TxkgsGdbLjK+LYXu7nkKS7 QFyy7idLUGfVZNotHJQl3dsSgKQP3Ww9COV9ddHW9Oyw2i3BWC8LsjqdEudnwB+AlQwj un/g== Received: by 10.68.233.196 with SMTP id ty4mr41653740pbc.23.1351006686672; Tue, 23 Oct 2012 08:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Tue, 23 Oct 2012 08:37:46 -0700 (PDT) In-Reply-To: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> From: Henning Rogge Date: Tue, 23 Oct 2012 17:37:46 +0200 Message-ID: To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:38:08 -0000 Okay, I will publish the draft-00 document in the next days. I think it could even be more simplified... Henning Rogge On Tue, Oct 23, 2012 at 1:13 PM, Bo Berry wrote: > Henning, > I've seen the draft, you should submit it to the WG. > > -Bo > > On Oct 23, 2012, at 3:06 AM, Henning Rogge wrote: > >> On 10/22/2012 09:10 PM, Ivancic, William D. (GRC-RHN0) wrote: >>> It should be possible to use the DLEP message formats without all >>> the signalling required for the DLEP client/server session to perform >>> the functions addressed in this draft. The modem would simply >>> provide link states out via multicast or unicast UDP datagrams >>> (DLEP-Lite). Whether or not this is a good idea, or acceptable to the >>> manet group, is yet to be determined. >> >> I have an implementation that does this with a RFC5444 compliant protoco= l (was written in April this year). >> >>> In the mean time, This modemLPA document was originally submitted to >>> the IRTF mobopts research group as an individual submission >>> draft-ivancic-mobopts-modemlpa-01. That research group as recently >>> closed down. I am looking for a new place to put updates until a >>> decision is made on DLEP-Lite. Is the manet group the right place? I >>> really don't know if this is the right group or if someplace else may >>> be more appropriate. I see no other working groups or research >>> groups really looking at layer-2 triggers. >> >> The concept of my "stateless-rfc5444-dlep" was to create a 'core set' of= functionality that allow simplified use cases like you describe. >> >> In the most simple one, the Radio just sends out two types of messages v= ia multicast or unicast in regular intervals. The Router just listens to th= e messages and updates its internal databases according the them. >> >> One message contains information about the network the radio is attached= to, the second message contains information about the known neighbors of t= he radio. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From jau@coe.drexel.edu Tue Oct 23 09:27:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD05111E8109 for ; Tue, 23 Oct 2012 09:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek8NuTAwe-mH for ; Tue, 23 Oct 2012 09:27:02 -0700 (PDT) Received: from edge02.coe.drexel.edu (edge02.coe.drexel.edu [129.25.59.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9074611E80ED for ; Tue, 23 Oct 2012 09:27:02 -0700 (PDT) Received: from ex.coe.drexel.edu ([169.254.1.82]) by Edge02.coe.drexel.edu ([129.25.59.24]) with mapi; Tue, 23 Oct 2012 12:27:01 -0400 From: Jaudelice de Oliveira To: Ulrich Herberg Date: Tue, 23 Oct 2012 12:27:05 -0400 Thread-Topic: [manet] LOADng-06 Thread-Index: Ac2xOzrgE879dsOcRaGwuYuaEiweoA== Message-ID: <46EE1684-91A3-467E-9530-C9A02819AB6E@coe.drexel.edu> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 16:27:03 -0000 Hi Ulrich, On Oct 22, 2012, at 10:49 PM, Ulrich Herberg wrote: >=20 > Now some differences: > - Most importantly: LOADng has achieved what DYMO failed to do: to gather= broad industrial support from several large companies, several large-scale= deployments with several thousands of nodes, I have joined the list recently, so I probably missed some of the earlier d= iscussion on LOAD-ng MANET deployment experiences. Can you point to documen= ts reflecting MANET results?=20 > LOADng has an updated MIB document, and documented interoperability test = of at least four recent implementations. Are you referring to the 2 to 5 LLN node topologies pass/fail testing draft= (draft-lavenu-lln-loadng-interoperability-report-03)?=20 > - Part of the reason, I believe, is that the writing style is very differ= ent. LOADng has a more algorithmic way of writing. That's immediate to see = when you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO,= much harder to implement DYMO. The goal for LOADng was to make it so strai= ght forward to implement that an undergrad student could take the spec, spe= nd a few days implementing it and have a reasonable and interoperable imple= mentation. I have implemented LOADng in one day, based on the specification= . Indeed, my PhD student also followed the specification and coding it was st= raight forward. However we did have concerns about its performance in LLNs = (which the deployment efforts you spoke of seem to be), specially with rega= rds to control overhead and end-to-end delay. Being a reactive protocol, i= ts dependency on user traffic may overwelm the network, which we did see in= our simulation study. I have seen the email from Thierry that commented on= results for 2000 nodes AMI PLC network, but did not get a reply to my inqu= iry with respect to the traffic used. > The draft started out from where the deployments exist, which some call L= LNs. However, as a basic reactive protocol, LOADng also covers the more gen= eral MANET case that includes a wider ranger of resources (from extremely c= onstrained to not-so-constrained) and mobility. In particular, by supportin= g RFC5444 it fits well in the MANET architecture and the surrounding securi= ty extensions, flooding optimizations and TLVs etc. for RFC5444. Again, I may have missed this, but do you have results from deployments wit= h mobile nodes? As you stated, the deployment were the LOADng draft started= from were all LLNs, and I am still curious about the details of those stud= ies. Do you have a pointer to a documented study? > I won't go into details here, but most of the discussions we had were not= so much about technical issues, but about procedural. LOADng has started w= hen DYMO was stalled for more than 2 years. I think we have a well mature d= ocument, supported by strong industry backing and running code. The latter = is crucial in the IETF. > Best regards > Ulrich >=20 Best regards, Jau. Jaudelice de Oliveira Associate Professor ECE Dept, Drexel University From ulrich@herberg.name Tue Oct 23 10:01:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8559C1F0419 for ; Tue, 23 Oct 2012 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTYOKAVM3M6q for ; Tue, 23 Oct 2012 10:01:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C392A11E80CC for ; Tue, 23 Oct 2012 10:01:21 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4924975vbb.31 for ; Tue, 23 Oct 2012 10:01:21 -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=SReK5F1O49Yc1yuyxrijkUse+VA22ravKcjkbXXCoXo=; b=OLgbAlkVgEAQh8cLaFyj2b579PqMro/w0Ve7jCoOn9Zj19RXIFMbwayyTUiZLvmjnq 6hF/4I2A6+zDNHuMPHTxAtebLNBd6TMNNX2kOFAq1WhHdSLIsJYIX54A4xwXQagCUpMs Ehz0mFy6qVhTZBusBfLrH0DNxfHoL5B65BT64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SReK5F1O49Yc1yuyxrijkUse+VA22ravKcjkbXXCoXo=; b=TUVNZr9xLPCdUulXO1JKE2Y5Wckii0cO438rDRJyhKl40ZaCwW8tWDq70uYN6OfLEP lOYmuPYB86hR/S4dBFapPK05MdOUUlEtbvm8ZsHBinI3GYFwLGVdzetIx0iwXvosj0x7 Yf9f6X3EU4Yv4FtyYGcZlaEveDn156nmjuUtOwvU7bMn1AKnctLMIFjpmXuhRO5y0dY3 aSYjJork3yoEx5vg89bL2M38JW8Ba6EoOmtm29TNCf3FQgYxxomYqdf3yuCHrufplQ+7 7b84TttAS0Dyuw5M7ptfbBVcmx15Acliqz9d15yyAPtw6TDi+Z+YmozJEtpTWAhaU04c SQdQ== MIME-Version: 1.0 Received: by 10.221.2.76 with SMTP id nt12mr3266305vcb.12.1351011681458; Tue, 23 Oct 2012 10:01:21 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Tue, 23 Oct 2012 10:01:21 -0700 (PDT) In-Reply-To: <46EE1684-91A3-467E-9530-C9A02819AB6E@coe.drexel.edu> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <46EE1684-91A3-467E-9530-C9A02819AB6E@coe.drexel.edu> Date: Tue, 23 Oct 2012 10:01:21 -0700 Message-ID: From: Ulrich Herberg To: Jaudelice de Oliveira Content-Type: multipart/alternative; boundary=bcaec54a377a5c5a5d04ccbceb8f X-Gm-Message-State: ALoCoQmR6ohet0X8/7/LEOzPavuAru7r2YhB+xJqZQ8fTnQcs2ruKyA8+9S5lHCXP50P1nmFQ4A2 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:01:23 -0000 --bcaec54a377a5c5a5d04ccbceb8f Content-Type: text/plain; charset=ISO-8859-1 Hi Jaudelice, On Tue, Oct 23, 2012 at 9:27 AM, Jaudelice de Oliveira wrote: > Hi Ulrich, > > On Oct 22, 2012, at 10:49 PM, Ulrich Herberg wrote: > > > > > Now some differences: > > - Most importantly: LOADng has achieved what DYMO failed to do: to > gather broad industrial support from several large companies, several > large-scale deployments with several thousands of nodes, > > I have joined the list recently, so I probably missed some of the earlier > discussion on LOAD-ng MANET deployment experiences. Welcome to the list! > Can you point to documents reflecting MANET results? > Just to be clear here: MANET is working on an improved version of AODV. I expect a very similar performance of LOADng compared to AODV, and there are dozens, maybe hundreds of papers about the performance of AODV. This is very similar between OLSR and OLSRv2; I would be very surprised to see a significant performance difference between the two protocols, as they have the same mechanism (however, OLSRv2 has several simplifications such as fewer message types and is more flexible because of RFC5444). The reason why MANET has this discussion is to come up with a standards track version of AODV. So compared to AODV, LOADng has some improvements which are listed in the introduction: Compared to [RFC3561 ], LOADng is extended as follows: o Optimized flooding is supported, reducing the overhead incurred by RREQ generation and flooding. If no optimized flooding operation is specified for a given deployment, classical flooding is used by default. o Different address lengths are supported - from full 16 octet IPv6 addresses over 8 octet EUI64 addresss [EUI64 ], 6 octet MAC addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet addresses such as [RFC4944 ]. The only requirement is, that within a given routing domain, all addresses are of the same address length. o Control messages are carried by way of the Generalized MANET Packet/Message Format [RFC5444 ]. o Using [RFC5444 ], control messages can include TLV (Type-Length- Value) elements, permitting protocol extensions to be developed. LOADng supports routing using arbitrary additive metrics, which can be specified as extensions to this protocol. > > > LOADng has an updated MIB document, and documented interoperability test > of at least four recent implementations. > > Are you referring to the 2 to 5 LLN node topologies pass/fail testing > draft (draft-lavenu-lln-loadng-interoperability-report-03)? > Yes. Again, don't confuse that with a performance evaluation. It is purely an interop document. > > > - Part of the reason, I believe, is that the writing style is very > different. LOADng has a more algorithmic way of writing. That's immediate > to see when you compare section 5.3 of DYMO with section 12 of LOADng. It > is, IMO, much harder to implement DYMO. The goal for LOADng was to make it > so straight forward to implement that an undergrad student could take the > spec, spend a few days implementing it and have a reasonable and > interoperable implementation. I have implemented LOADng in one day, based > on the specification. > > Indeed, my PhD student also followed the specification and coding it was > straight forward. I am glad to hear that. However we did have concerns about its performance in LLNs (which the > deployment efforts you spoke of seem to be), specially with regards to > control overhead and end-to-end delay. One point to the control overhead: it is given by RFC5444. Unless there is any fragmentation, I don't see a problem with that. Fragmentation is unlikely, even in some of the 802.15.4 layers, as there will be a maximum of two addresses and about two TLVs in each message (you can easily to the math here how many octets that would be in RFC5444). Using MPR flooding or other optimized flooding methods have shown to severely reduce the overhead as well (and there are many studies showing the difference between classic flooding and MPR flooding). In particular in cases where there are few communication end-points communicating with each other at the same time and only rarely there is data traffic, reactive protocols may have a much better performance (no control traffic unless there is data traffic, and only 1 route stored at each router). And this is known to MANET WG for a long time, and reason for the current charter. There are other use cases, where reactive protocols are not suitable, and proactive protocols are better, which is why we have OLSR (and hopefully OLSRv2). On the delay, what are your requirements? Sure, if you need the traffic to be delivered within 1ms, a reactive protocol may not be the right protocol for you. Take a proactive protocol then. This is why, contrary to other WGs, we don't have the approach of "one-size-fits-all". Because it simply depends on the scenario and your requirements. > Being a reactive protocol, its dependency on user traffic may overwelm the > network, which we did see in our simulation study. Again, that very much depends on the traffic scenario and the topology, and if you use optimized flooding. I have never doubted that there are scenarios where reactive protocols suck, but there are scenarios where they are better than proactive ones. > I have seen the email from Thierry that commented on results for 2000 > nodes AMI PLC network, but did not get a reply to my inquiry with respect > to the traffic used. > > > The draft started out from where the deployments exist, which some call > LLNs. However, as a basic reactive protocol, LOADng also covers the more > general MANET case that includes a wider ranger of resources (from > extremely constrained to not-so-constrained) and mobility. In particular, > by supporting RFC5444 it fits well in the MANET architecture and the > surrounding security extensions, flooding optimizations and TLVs etc. for > RFC5444. > > Again, I may have missed this, but do you have results from deployments > with mobile nodes? Pretty much all work that has been done on AODV gives you the performance. This is how a WG works; there was an experimental protocol, there have been experiments over the last 10 years or so. Now we improve the protocol by making the frame format more flexible, by allowing for optimized flooding etc. and make a standard tracks protocol (at least that's currently in the charter and pending a decision of the chairs). > As you stated, the deployment were the LOADng draft started from were all > LLNs, and I am still curious about the details of those studies. Do you > have a pointer to a documented study? > As I am not one of those having a deployment that can be disclosed, I cannot reply here. > > > Best regards, > > Jau. > > > Best regards Ulrich --bcaec54a377a5c5a5d04ccbceb8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jaudelice,

On Tue, Oct 23, 2012 at 9:2= 7 AM, Jaudelice de Oliveira <jau@coe.drexel.edu> wrote:
=
Hi Ulrich,

On Oct 22, 2012, at 10:49 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

>
> Now some differences:
> - Most importantly: LOADng has achieved what DYMO failed to do: to gat= her broad industrial support from several large companies, several large-sc= ale deployments with several thousands of nodes,

I have joined the list recently, so I probably missed some of the ear= lier discussion on LOAD-ng MANET deployment experiences.
=
Welcome to the list!

=A0
Can you point to documents reflecting MANET results?
<= br>
Just to be clear here: MANET is working on an improved versio= n of AODV. I expect a very similar performance of LOADng compared to AODV, = and there are dozens, maybe hundreds of papers about the performance of AOD= V. This is very similar between OLSR and OLSRv2; I would be very surprised = to see a significant performance difference between the two protocols, as t= hey have the same mechanism (however, OLSRv2 has several simplifications su= ch as fewer message types and is more flexible because of RFC5444). The rea= son why MANET has this discussion is to come up with a standards track vers= ion of AODV.


So compared to AODV, LOADng has some imp= rovements which are listed in the introduction:

Compared to [RFC3561], LOADn= g is extended as follows: o Optimized flooding is supported, reducing the overhead incurred by RREQ generation and flooding. If no optimized flooding operation is specified for a given deployment, classical flooding is used by default. o Different address lengths are supported - from full 16 octet IPv6 addresses over 8 octet EUI64 addresss [EUI64= ], 6 octet MAC addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet addresses such as [RFC4944]. The only requirement is, that within a given routing domain, all addresses are of the same address length.

   o  Control messages are carried b=
y way of the Generalized MANET
      Packet/Message Format [RFC5444].

   o  Using [RFC5=
444], control messages can include TLV (Type-Length-
      Value) elements, permitting protocol extensions to be developed.

   LOADng supports routing using arbitrary additive metrics, which can
   be specified as extensions to this protocol.

<= div>=A0

> LOADng has an updated MIB document, and documented interoperability te= st of at least four recent implementations.

Are you referring to the 2 to 5 LLN node topologies pass/fail testing= draft (draft-lavenu-lln-loadng-interoperability-report-03)?


Yes. Again, don't confuse that wit= h a performance evaluation. It is purely an interop document.

=A0

> - Part of the reason, I believe, is that the writing style is very dif= ferent. LOADng has a more algorithmic way of writing. That's immediate = to see when you compare section 5.3 of DYMO with section 12 of LOADng. It i= s, IMO, much harder to implement DYMO. The goal for LOADng was to make it s= o straight forward to implement that an undergrad student could take the sp= ec, spend a few days implementing it and have a reasonable and interoperabl= e implementation. I have implemented LOADng in one day, based on the specif= ication.

Indeed, my PhD student also followed the specification and coding it = was straight forward.


I am = glad to hear that.
=A0

However we did have concerns about its performance in LLNs (which the deplo= yment efforts you spoke of seem to be), specially with regards to control o= verhead and end-to-end delay. =A0

One point= to the control overhead: it is given by RFC5444. Unless there is any fragm= entation, I don't see a problem with that. Fragmentation is unlikely, e= ven in some of the 802.15.4 layers, as there will be a maximum of two addre= sses and about two TLVs in each message (you can easily to the math here ho= w many octets that would be in RFC5444). Using MPR flooding or other optimi= zed flooding methods have shown to severely reduce the overhead as well (an= d there are many studies showing the difference between classic flooding an= d MPR flooding). In particular in cases where there are few communication e= nd-points communicating with each other at the same time and only rarely th= ere is data traffic, reactive protocols may have a much better performance = (no control traffic unless there is data traffic, and only 1 route stored a= t each router). And this is known to MANET WG for a long time, and reason f= or the current charter. There are other use cases, where reactive protocols= are not suitable, and proactive protocols are better, which is why we have= OLSR (and hopefully OLSRv2).=A0

On the delay, what are your requirements? Sure, if you = need the traffic to be delivered within 1ms, a reactive protocol may not be= the right protocol for you. Take a proactive protocol then. This is why, c= ontrary to other WGs, we don't have the approach of "one-size-fits= -all". Because it simply depends on the scenario and your requirements= .

=A0
Being a reactiv= e protocol, its dependency on user traffic may overwelm the network, which = we did see in our simulation study.


Again, that very much depends on the tra= ffic scenario and the topology, and if you use optimized flooding. I have n= ever doubted that there are scenarios where reactive protocols suck, but th= ere are scenarios where they are better than proactive ones.


=A0
= I have seen the email from Thierry that commented on results for 2000 nodes= AMI PLC network, but did not get a reply to my inquiry with respect to the= traffic used.

> The draft started out from where the deployments exist, which some cal= l LLNs. However, as a basic reactive protocol, LOADng also covers the more = general MANET case that includes a wider ranger of resources (from extremel= y constrained to not-so-constrained) and mobility. In particular, by suppor= ting RFC5444 it fits well in the MANET architecture and the surrounding sec= urity extensions, flooding optimizations and TLVs etc. for RFC5444.

Again, I may have missed this, but do you have results from deploymen= ts with mobile nodes?


Prett= y much all work that has been done on AODV gives you the performance. This = is how a WG works; there was an experimental protocol, there have been expe= riments over the last 10 years or so. Now we improve the protocol by making= the frame format more flexible, by allowing for optimized flooding etc. an= d make a standard tracks protocol (at least that's currently in the cha= rter and pending a decision of the chairs).

=A0
As you stated, = the deployment were the LOADng draft started from were all LLNs, and I am s= till curious about the details of those studies. Do you have a pointer to a= documented study?

As I am not one of those having a deployme= nt that can be disclosed, I cannot reply here.

=A0=


Best regards,

Jau.


Best regards
Ulrich=A0
--bcaec54a377a5c5a5d04ccbceb8f-- From charliep@computer.org Tue Oct 23 10:05:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CEB11E80E7 for ; Tue, 23 Oct 2012 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c49EX5U1tgkL for ; Tue, 23 Oct 2012 10:05:18 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8C11E80D5 for ; Tue, 23 Oct 2012 10:05:18 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TQhum-0006gT-IH; Tue, 23 Oct 2012 13:05:16 -0400 Message-ID: <5086CE48.3040208@computer.org> Date: Tue, 23 Oct 2012 10:05:12 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ulrich Herberg References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86dfce2e5c92478b7ce6de257e8e94e751350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:05:19 -0000 Hello folks, I have some more to add to Ulrich's comments. On 10/22/2012 7:49 PM, Ulrich Herberg wrote: > > Moreover, reactive protocols are often used in cases where memory is > an extremely scarce resource, and where proactive protocols cannot be > used. That makes a slim design preferable, IMO, for such protocols. > - LOADng may be used in other layers as L3, e.g. as mesh-under protocol. > - LOADng supports optimized broadcasting mechanisms such as MPR flooding > - There is no Route Reply ACK in DYMO; this is part of LOADng to > verify bidirectionality of links; as in wireless channels, links are > rarely symmetric. This functionality is easily accomplished without RREP_ACK. The original design of DYMO was intended to have two characteristics: - enable minimalistic implementations by making some features optional - combine the design points of AODV and DSR, which are the two Experimental reactive protocols published by [manet] WG. The name DYMO was chosen in order to signal the development of a Proposed Standard, and to avoid showing favoritism to AODV or DSR. In hindsight, the choice of name seems to have been a mistake, and on the advice of several people I reverted the name back to AODV(v2). I have made an issue on the issue tracker about the naming. Of course AODVv2 supports optimized broadcasting, and was always designed and intended to do so. Also AODVv2 could equally (and, in fact, LOADng proves this) be used in other layers. And, as mentioned, AODVv2 already supports the functionality of RREP_ACK, and the specification of pre-existing methods for doing that was viewed as a simplification. Of course, RREP-ACK could be added back to the protocol specification almost trivially, especially since that message type was already specified in AODV, and later respecified in quite similar fashion within LOADng. It is my view that the IETF [manet] reactive protocol specification was always intended to support minimalistic deployments such as LOADng, and it is my intention to make sure of it. Almost tautologically, having optional features such as precursor lists does not constrain minimalistic deployments. I have reorganized the AODVv2 specification so that the optional features mentioned by Ulrich are clearly separated from the base protocol. -- Regards, Charlie P. From jau@coe.drexel.edu Tue Oct 23 11:02:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF14F11E80EC for ; Tue, 23 Oct 2012 11:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCWp2RF5vCF4 for ; Tue, 23 Oct 2012 11:01:59 -0700 (PDT) Received: from edge02.coe.drexel.edu (edge02.coe.drexel.edu [129.25.59.24]) by ietfa.amsl.com (Postfix) with ESMTP id 506DC21F86AF for ; Tue, 23 Oct 2012 11:01:59 -0700 (PDT) Received: from ex.coe.drexel.edu ([169.254.1.82]) by Edge02.coe.drexel.edu ([129.25.59.24]) with mapi; Tue, 23 Oct 2012 14:01:58 -0400 From: Jaudelice de Oliveira To: Ulrich Herberg Date: Tue, 23 Oct 2012 14:02:01 -0400 Thread-Topic: [manet] LOADng-06 Thread-Index: Ac2xSH5tzkzA74gPRGut1Hfi0fk2ZQ== Message-ID: References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <46EE1684-91A3-467E-9530-C9A02819AB6E@coe.drexel.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FC12CF8A1E6D490E96B8CFFF48686584coedrexeledu_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:02:01 -0000 --_000_FC12CF8A1E6D490E96B8CFFF48686584coedrexeledu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 23, 2012, at 1:01 PM, Ulrich Herberg > wrote: Hi Jaudelice, I have joined the list recently, so I probably missed some of the earlier d= iscussion on LOAD-ng MANET deployment experiences. Welcome to the list! So compared to AODV, LOADng has some improvements which are listed in the i= ntroduction: Compared to [RFC3561], LOADng is extend= ed as follows: o Optimized flooding is supported, reducing the overhead incurred by RREQ generation and flooding. If no optimized flooding operation is specified for a given deployment, classical flooding is used by default. o Different address lengths are supported - from full 16 octet IPv6 addresses over 8 octet EUI64 addresss [EUI64], 6 octet MAC addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet addresses such as [RFC4944]. The= only requirement is, that within a given routing domain, all addresses are of the same address length. o Control messages are carried by way of the Generalized MANET Packet/Message Format [RFC5444]. o Using [RFC5444], control messages= can include TLV (Type-Length- Value) elements, permitting protocol extensions to be developed. LOADng supports routing using arbitrary additive metrics, which can be specified as extensions to this protocol. > LOADng has an updated MIB document, and documented interoperability test = of at least four recent implementations. Are you referring to the 2 to 5 LLN node topologies pass/fail testing draft= (draft-lavenu-lln-loadng-interoperability-report-03)? Yes. Again, don't confuse that with a performance evaluation. It is purely = an interop document. > - Part of the reason, I believe, is that the writing style is very differ= ent. LOADng has a more algorithmic way of writing. That's immediate to see = when you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO,= much harder to implement DYMO. The goal for LOADng was to make it so strai= ght forward to implement that an undergrad student could take the spec, spe= nd a few days implementing it and have a reasonable and interoperable imple= mentation. I have implemented LOADng in one day, based on the specification= . Indeed, my PhD student also followed the specification and coding it was st= raight forward. I am glad to hear that. However we did have concerns about its performance in LLNs (which the deplo= yment efforts you spoke of seem to be), specially with regards to control o= verhead and end-to-end delay. One point to the control overhead: it is given by RFC5444. Unless there is = any fragmentation, I don't see a problem with that. Fragmentation is unlike= ly, even in some of the 802.15.4 layers, as there will be a maximum of two = addresses and about two TLVs in each message (you can easily to the math he= re how many octets that would be in RFC5444). Using MPR flooding or other o= ptimized flooding methods have shown to severely reduce the overhead as wel= l (and there are many studies showing the difference between classic floodi= ng and MPR flooding). In particular in cases where there are few communicat= ion end-points communicating with each other at the same time and only rare= ly there is data traffic, reactive protocols may have a much better perform= ance (no control traffic unless there is data traffic, and only 1 route sto= red at each router). And this is known to MANET WG for a long time, and rea= son for the current charter. There are other use cases, where reactive prot= ocols are not suitable, and proactive protocols are better, which is why we= have OLSR (and hopefully OLSRv2). Perhaps I was too subtle=85 My point was that you were alluding to LOADng's= success with respect to DYMO by pointing to existing deployments, which I= believe are all LLN deployments. By that measure, there are many successfu= l AODV (and DYMO deployments), as you pointed out, so I fail to see the dep= loyment advantage you claimed LOADng to have with respect to DYMO. Sure, there are scenarios were reactive protocols will thrive and others wh= ere proactive protocols are the natural choice. My point was that the LOADn= g deployment scenarios I have heard of (may have missed discussions on this= list) are constrained LLNs, and the traffic used (realistic or not) will d= rive the performance results. BR, Jau. On the delay, what are your requirements? Sure, if you need the traffic to = be delivered within 1ms, a reactive protocol may not be the right protocol = for you. Take a proactive protocol then. This is why, contrary to other WGs= , we don't have the approach of "one-size-fits-all". Because it simply depe= nds on the scenario and your requirements. Being a reactive protocol, its dependency on user traffic may overwelm the = network, which we did see in our simulation study. Again, that very much depends on the traffic scenario and the topology, and= if you use optimized flooding. I have never doubted that there are scenari= os where reactive protocols suck, but there are scenarios where they are be= tter than proactive ones. I have seen the email from Thierry that commented on results for 2000 nodes= AMI PLC network, but did not get a reply to my inquiry with respect to the= traffic used. > The draft started out from where the deployments exist, which some call L= LNs. However, as a basic reactive protocol, LOADng also covers the more gen= eral MANET case that includes a wider ranger of resources (from extremely c= onstrained to not-so-constrained) and mobility. In particular, by supportin= g RFC5444 it fits well in the MANET architecture and the surrounding securi= ty extensions, flooding optimizations and TLVs etc. for RFC5444. Again, I may have missed this, but do you have results from deployments wit= h mobile nodes? Pretty much all work that has been done on AODV gives you the performance. = This is how a WG works; there was an experimental protocol, there have been= experiments over the last 10 years or so. Now we improve the protocol by m= aking the frame format more flexible, by allowing for optimized flooding et= c. and make a standard tracks protocol (at least that's currently in the ch= arter and pending a decision of the chairs). As you stated, the deployment were the LOADng draft started from were all L= LNs, and I am still curious about the details of those studies. Do you have= a pointer to a documented study? As I am not one of those having a deployment that can be disclosed, I canno= t reply here. Best regards, Jau. Best regards Ulrich --_000_FC12CF8A1E6D490E96B8CFFF48686584coedrexeledu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Ulrich,


On Oct 23, 2012, at 1:01 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

Hi Jaudelice,
<= br>

I have joined the list recently, so I probably missed some of the ear= lier discussion on LOAD-ng MANET deployment experiences.
=
Welcome to the list!

=




So compared to AODV, LOADng has some imp= rovements which are listed in the introduction:

Compared to [RFC3561], LO= ADng is extended as follows: o Optimized flooding is supported, reducing the overhead incurred by RREQ generation and flooding. If no optimized flooding operation is specified for a given deployment, classical flooding is used by default. o Different address lengths are supported - from full 16 octet IPv6 addresses over 8 octet EUI64 addresss [EUI64= ], 6 octet MAC addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet addresses such as [RFC4944]. The only requirement is, that within a given routing domain, all addresses are of the same address length.

   o  Control messages are carried b=
y way of the Generalized MANET
      Packet/Message Format [RFC5444].

   o  Using [RFC5=
444], control messages can include TLV (Type-Length-
      Value) elements, permitting protocol extensions to be developed.

   LOADng supports routing using arbitrary additive metrics, which can
   be specified as extensions to this protocol.

<= div> 

> LOADng has an updated MIB document, and documented interoperability te= st of at least four recent implementations.

Are you referring to the 2 to 5 LLN node topologies pass/fail testing= draft (draft-lavenu-lln-loadng-interoperability-report-03)?


Yes. Again, don't confuse that with a = performance evaluation. It is purely an interop document.

 

> - Part of the reason, I believe, is that the writing style is very dif= ferent. LOADng has a more algorithmic way of writing. That's immediate to s= ee when you compare section 5.3 of DYMO with section 12 of LOADng. It is, I= MO, much harder to implement DYMO. The goal for LOADng was to make it so st= raight forward to implement that an undergrad student could take the spec, = spend a few days implementing it and have a reasonable and interoperable im= plementation. I have implemented LOADng in one day, based on the specificat= ion.

Indeed, my PhD student also followed the specification and coding it = was straight forward.


I am = glad to hear that.
 

However we did have concerns about its performance in LLNs (which the deplo= yment efforts you spoke of seem to be), specially with regards to control o= verhead and end-to-end delay.  

One po= int to the control overhead: it is given by RFC5444. Unless there is any fr= agmentation, I don't see a problem with that. Fragmentation is unlikely, ev= en in some of the 802.15.4 layers, as there will be a maximum of two addres= ses and about two TLVs in each message (you can easily to the math here how= many octets that would be in RFC5444). Using MPR flooding or other optimiz= ed flooding methods have shown to severely reduce the overhead as well (and= there are many studies showing the difference between classic flooding and= MPR flooding). In particular in cases where there are few communication en= d-points communicating with each other at the same time and only rarely the= re is data traffic, reactive protocols may have a much better performance (= no control traffic unless there is data traffic, and only 1 route stored at= each router). And this is known to MANET WG for a long time, and reason fo= r the current charter. There are other use cases, where reactive protocols = are not suitable, and proactive protocols are better, which is why we have = OLSR (and hopefully OLSRv2). 


Perhaps I was too subtle= =85 My point was that you were alluding to LOADng's success  with resp= ect to DYMO by pointing to existing deployments, which I believe are all LL= N deployments. By that measure, there are many successful AODV (and DYMO de= ployments), as you pointed out, so I fail to see the deployment advantage y= ou claimed LOADng to have with respect to DYMO.

Su= re, there are scenarios were reactive protocols will thrive and others wher= e proactive protocols are the natural choice. My point was that the LOADng = deployment scenarios I have heard of (may have missed discussions on this l= ist) are constrained LLNs, and the traffic used (realistic or not) will dri= ve the performance results.

BR,
Jau.


On= the delay, what are your requirements? Sure, if you need the traffic to be= delivered within 1ms, a reactive protocol may not be the right protocol fo= r you. Take a proactive protocol then. This is why, contrary to other WGs, = we don't have the approach of "one-size-fits-all". Because it simply depend= s on the scenario and your requirements.

 
Being a reac= tive protocol, its dependency on user traffic may overwelm the network, whi= ch we did see in our simulation study.


Again, that very much depends on the tra= ffic scenario and the topology, and if you use optimized flooding. I have n= ever doubted that there are scenarios where reactive protocols suck, but th= ere are scenarios where they are better than proactive ones.


 
I have seen the email from Thierry that commented on results for 2000 no= des AMI PLC network, but did not get a reply to my inquiry with respect to = the traffic used.

> The draft started out from where the deployments exist, which some cal= l LLNs. However, as a basic reactive protocol, LOADng also covers the more = general MANET case that includes a wider ranger of resources (from extremel= y constrained to not-so-constrained) and mobility. In particular, by suppor= ting RFC5444 it fits well in the MANET architecture and the surrounding sec= urity extensions, flooding optimizations and TLVs etc. for RFC5444.

Again, I may have missed this, but do you have results from deploymen= ts with mobile nodes?


Prett= y much all work that has been done on AODV gives you the performance. This = is how a WG works; there was an experimental protocol, there have been expe= riments over the last 10 years or so. Now we improve the protocol by making= the frame format more flexible, by allowing for optimized flooding etc. an= d make a standard tracks protocol (at least that's currently in the charter= and pending a decision of the chairs).

 
As you state= d, the deployment were the LOADng draft started from were all LLNs, and I a= m still curious about the details of those studies. Do you have a pointer t= o a documented study?

As I am not one of those having a deployme= nt that can be disclosed, I cannot reply here.

&nb= sp;


Best regards,

Jau.


Best regards
Ulrich 

= --_000_FC12CF8A1E6D490E96B8CFFF48686584coedrexeledu_-- From jvasseur@cisco.com Tue Oct 23 11:06:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DD21F0C89 for ; Tue, 23 Oct 2012 11:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.36 X-Spam-Level: X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgJm-SLNy0U1 for ; Tue, 23 Oct 2012 11:06:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ECF561F0C8E for ; Tue, 23 Oct 2012 11:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23683; q=dns/txt; s=iport; t=1351015612; x=1352225212; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cus2NC0vkp+PUypYQ8/PurLNwSXeTcwTdGW+Tf8MqMs=; b=Y6Lg9VhNKfF+DwkgiQzY6YAkb7SLNGNdCQs44R0aLmADvtOY8CRXFGWL i6d/Iu+oXbjm7ZMx6ycfwlJUYlhjMMX1OWsDobDaDCkB2xQ4tocM6HXdl jCDlCNVx63quXk6QrbMxf1kylvA5C7cWsHtydu8C5HC9eOge81xaoI8Ck I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAHTchlCtJXG+/2dsb2JhbABEuQUBiGqBCIIeAQEBAwEBAQEPAVsBCgULAgEIEhAdBycLFAMOAgQOBQgah1wGC5wDj1yQLotfFAeFY2ADkj+ESY03gWuCb4FaCRce X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208,217";a="131568045" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2012 18:06:51 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NI6pgn002660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 18:06:51 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 13:06:50 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] LOADng-06 Thread-Index: AQHNsP6PoCdWGOst6kOKVbo4pjGngA== Date: Tue, 23 Oct 2012 18:06:50 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220174EE@xmb-rcd-x02.cisco.com> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <03B78081B371D44390ED6E7BADBB4A7722014627@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--47.879200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220174EExmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" , "Bo Berry \(boberry\)" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:06:54 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77220174EExmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Oct 23, 2012, at 5:19 PM, Ulrich Herberg wrote: Hi JP, I was about to write a more detailed answer and then decided against it. Bo= asked a technical question, to which I replied. Let's wait what the chairs= say, then I may answer to your points. Sure, feel free not to answer. Your call. I fully respect it. If you want to have a technical discussion on why (as individual contributo= r) I think that LOAD-ng is a major issue for highly constrained LLNs, I would be more than happy to continue that discussion on the mailing list. That being said, my point was that DYMO/AODVv2 was a very good base to comp= lete the reactive routing work in MANET. Best. JP. Best Ulrich On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" > wrote: Dear Ulrich, Let me chine in since I do not think that we are in agreement with your con= clusions here - see below On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote: Hi Bo, On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry > wrote: Hi Alex For those of us that have not have the opportunity to follow the Loadng discussions, could you please describe the similarities and the unique differences of Loadng relative to Dymo. I'm aware of the discussions about lousy nets and manets, but less between the two protocols. I think this would help everyone on the WG understand the benefits. I agree with that, and it is a fair question to ask. Let me try to list a f= ew differences, others may chime in with more. First the commonalities: - Both are reactive protocols, based on AODV, with the intended status of = "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that = the WG has to come up with a std. track reactive protocol. Essentially, in = a reactive protocol, routes are requested "on-demand" (i.e. when there is d= ata traffic and no route exists for the destination of the data packet). Th= erefore, you will see similar message types in both protocols (Route Reques= ts, Route Replies, and Route Errors), and essentially the same basic mechan= ism. JP> It is worth that MANET has already a WG document, DYMO, which has been = discussed extensively in the WG. - Both are applicable to MANETs (see also below for your next question), an= d both support RFC5444. LOADng is decoupling the mechanism from the message= format; RFC5444 is mapped to the mechanism, but other message formats coul= d easily be specified (e.g., with a more compressed message format for extr= emely limited links in terms of bandwidth). Now some differences: - Most importantly: LOADng has achieved what DYMO failed to do: to gather b= road industrial support from several large companies, several large-scale d= eployments with several thousands of nodes, LOADng has an updated MIB docum= ent, and documented interoperability test of at least four recent implement= ations. JP> If I may, this is more of a Marketing comment though. I do not think th= at DYMO failed in any way. It turns out that the timing was different, that= 's all. - Part of the reason, I believe, is that the writing style is very differen= t. LOADng has a more algorithmic way of writing. That's immediate to see wh= en you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, m= uch harder to implement DYMO. The goal for LOADng was to make it so straigh= t forward to implement that an undergrad student could take the spec, spend= a few days implementing it and have a reasonable and interoperable impleme= ntation. I have implemented LOADng in one day, based on the specification. JP> I personally saw several implementations of DYMO, and if we require mor= e algorithmic details about DYMO, let's provide comments to the DYMO authors. - There are multiple optional features in DYMO that have deliberately not b= een included in LOADng (expanding ring multicasts, intermediate RREPs, prec= ursor lists etc). The reason was the following: in an experimental protocol= (AODV) it is fine to have many options, in order to explore whether they a= re useful. We have that experience now with AODV. For some of the options, = such as iRREP, it has not been shown over the last decade that they are of = general use. In some cases, they may be beneficial, but not in general. Als= o, they make it very hard to provide end-to-end security. LOADng kept the m= antra of a small, slim, and efficient protocol. Having many options makes i= t hard to assure interoperable devices out of the box, in particular if the= re is no negotiation of capabilities. Moreover, reactive protocols are often used in cases where memory is an ext= remely scarce resource, and where proactive protocols cannot be used. That = makes a slim design preferable, IMO, for such protocols. JP> We can discuss further in Atlanta, but several of these options are IMO= quite useful. - LOADng may be used in other layers as L3, e.g. as mesh-under protocol. JP> Another concern =85 If you plan using LOAD-ng as a mesh under protocol,= this requires much more discussion (not sure that such discussions should take place at the IETF, but because this would be an IETF work, we w= ould need to discuss it further). Indeed, proposing to standardize a mesh-under protocol is not just a matter of manipulating MAC addresses inst= ead of IP addresses: there are tons of implications of the architecture, as described in details in http://tools.ietf.org/html/draft-routing-archite= cture-iot-00 - LOADng supports optimized broadcasting mechanisms such as MPR flooding - There is no Route Reply ACK in DYMO; this is part of LOADng to verify bid= irectionality of links; as in wireless channels, links are rarely symmetric= . JP> Let's discuss further about these optimizations, which if needed, could= be added to DYMO. Looking at the Tools page, the draft was first submitted October 24, 2011, draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)." The abstract included the statement "The protocol is derived from AODV and extended for use in LLNs". Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the line "The protocol is derived from AODV (RFC3561) and extended for use in LLNs." was removed. This version also supported RFC 5444. The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)." The draft started out from where the deployments exist, which some call LLN= s. JP> As pointed out earlier, then I have two major concerns: 1) If the reactive routing protocol deals with LLNs, especially "hard const= rained" LLNs as pointed out in this mailing list, then I would strongly suggest to run the document by the two WGs, MANET and= ROLL. Let's see what the chairs decides. 2) ROLL co-chair hat-off, I do see a number of issues using reactive routin= g in hard constrained LLNs such as AMI PLC, years of experience in routing in such networks show us that there are majo= r scalability issues (I am not referring to the number of nodes, but also user traffic since depending on the user traffic this ma= y lead to massive control plane traffic churn to mention one of the many issues). However, as a basic reactive protocol, LOADng also covers the more general = MANET case that includes a wider ranger of resources (from extremely constr= ained to not-so-constrained) and mobility. In particular, by supporting RFC= 5444 it fits well in the MANET architecture and the surrounding security ex= tensions, flooding optimizations and TLVs etc. for RFC5444. I hope I could shed some light on that question. I invite you to read both = drafts, there is probably more to say here. I won't go into details here, but most of the discussions we had were not s= o much about technical issues, but about procedural. LOADng has started whe= n DYMO was stalled for more than 2 years. I think we have a well mature doc= ument, supported by strong industry backing and running code. JP> I do not make this email took polemical but you also have strong indust= ry disagreement in using such protocols for extremely constrained LLNs to say the least. Thanks. JP. The latter is crucial in the IETF. Best regards Ulrich Thanks -Bo On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote: > Dear all, > > we have updated LOADng, to make it clear that it is in scope and charter = for MANET. Unfortunately, it is only a minor revision of the technical cont= ent, since we have been in discussions with the DYMO authors and the WG lea= dership for several months on how to proceed with the reactive protocol in = MANET. The chairs will likely reply very soon to the list with an outcome o= f the discussion. > > Best regards, > > Axel Colin de Verdiere > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77220174EExmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Oct 23, 2012, at 5:19 PM, Ulrich Herberg wrote:

Hi JP,

I was about to write a more detailed answer and then decided against i= t. Bo asked a technical question, to which I replied. Let's wait what the c= hairs say, then I may answer to your points.


Sure, feel free not to answer. Your call. I fully respect it.

If you want to have a technical discussion on why (as individual contr= ibutor) I think that LOAD-ng is a major issue for highly constrained LLNs,<= /div>
I would be more than happy to continue that discussion on the mailing = list.

That being said, my point was that DYMO/AODVv2 was a very good base to= complete the reactive routing work in MANET.

Best.

JP.

Best
Ulrich

On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Dear Ulrich,

Let me chine in since I do not think that we are in agreement with you= r conclusions here - see below

On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote:

Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry <boberry@cisco.co= m> wrote:
Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities
and the unique differences of Loadng relative to Dymo.  I'm aware
of the discussions about lousy nets and manets, but less between
the two protocols.

I think this would help everyone on the WG understand the benefits.


I agree with that, and it is a fair question to ask. Let me try to lis= t a few differences, others may chime in with more. 

First the commonalities:
 - Both are reactive protocols, based on AODV, with the intended = status of "Proposed Standard" (AODV is "Experimental").= The MANET charter lists that the WG has to come up with a std. track react= ive protocol. Essentially, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and n= o route exists for the destination of the data packet). Therefore, you will= see similar message types in both protocols (Route Requests, Route Replies= , and Route Errors), and essentially the same basic mechanism.

JP> It is worth that MANET has already a WG document, DYMO, which h= as been discussed extensively in the WG.

- Both are applicable to MANETs (see also below for your next question= ), and both support RFC5444. LOADng is decoupling the mechanism from the me= ssage format; RFC5444 is mapped to the mechanism, but other message formats= could easily be specified (e.g., with a more compressed message format for extremely limited links in terms= of bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to gat= her broad industrial support from several large companies, several large-sc= ale deployments with several thousands of nodes, LOADng has an updated MIB = document, and documented interoperability test of at least four recent implementations.

JP> If I may, this is more of a Marketing comment though. I do not = think that DYMO failed in any way. It turns out that the timing was differe= nt, that's all.

- Part of the reason, I believe, is that the writing style is very dif= ferent. LOADng has a more algorithmic way of writing. That's immediate to s= ee when you compare section 5.3 of DYMO with section 12 of LOADng. It is, I= MO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that a= n undergrad student could take the spec, spend a few days implementing it a= nd have a reasonable and interoperable implementation. I have implemented L= OADng in one day, based on the specification.

JP> I personally saw several implementations of DYMO, and if we req= uire more algorithmic details about DYMO, let's provide comments to the DYM= O
authors.

- There are multiple optional features in DYMO that have deliberately = not been included in LOADng (expanding ring multicasts, intermediate RREPs,= precursor lists etc). The reason was the following: in an experimental pro= tocol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that ex= perience now with AODV. For some of the options, such as iRREP, it has not = been shown over the last decade that they are of general use. In some cases= , they may be beneficial, but not in general. Also, they make it very hard to provide end-to-end security. L= OADng kept the mantra of a small, slim, and efficient protocol. Having many= options makes it hard to assure interoperable devices out of the box, in p= articular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is a= n extremely scarce resource, and where proactive protocols cannot be used. = That makes a slim design preferable, IMO, for such protocols.

JP> We can discuss further in Atlanta, but several of these options= are IMO quite useful.

- LOADng may be used in other layers as L3, e.g. as mesh-under protoco= l.

JP> Another concern =85 If you plan using LOAD-ng as a mesh under p= rotocol, this requires much more discussion (not sure that such discussions=
should take place at the IETF, but because this would be an IETF work,= we would need to discuss it further). Indeed, proposing to standardize a
mesh-under protocol is not just a matter of manipulating MAC addresses= instead of IP addresses: there are tons of implications of the architectur= e,

- LOADng supports optimized broadcasting mechanisms such as MPR floodi= ng
- There is no Route Reply ACK in DYMO; this is part of LOADng to = verify bidirectionality of links; as in wireless channels, links are rarely= symmetric. 
 

JP> Let's discuss further about these optimizations, which if neede= d, could be added to DYMO.


Looking at the Tools page, the draft was first submitted October 24, 2011,<= br> draft-clausen-lln-loadng-00.  The title was, "The LLN On-demand A= d hoc
Distance-vector Routing Protocol - Next Generation (LOADng)."  Th= e
abstract included the statement "The protocol is derived
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for
use in LLNs." was removed.  This version also supported RFC 5444.=

The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)."


The draft started out from where the deployments exist, which some cal= l LLNs.

JP> As pointed out earlier, then I have two major concerns:
1) If the reactive routing protocol deals with LLNs, especially "= hard constrained" LLNs as pointed out in this mailing list,
then I would strongly suggest to run the document by the two WGs, MANE= T and ROLL. Let's see what the chairs decides.
2) ROLL co-chair hat-off, I do see a number of issues using reactive r= outing in hard constrained LLNs such as AMI PLC,
years of experience in routing in such networks show us that there are= major scalability issues (I am not referring to the number
of nodes, but also user traffic since depending on the user traffic th= is may lead to massive control plane traffic churn to mention
one of the many issues).

However, as a basic reactive protocol, LOADng also covers the more gen= eral MANET case that includes a wider ranger of resources (from extremely c= onstrained to not-so-constrained) and mobility. In particular, by supportin= g RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimizatio= ns and TLVs etc. for RFC5444.

I hope I could shed some light on that question. I invite you to read = both drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had were = not so much about technical issues, but about procedural. LOADng has starte= d when DYMO was stalled for more than 2 years. I think we have a well matur= e document, supported by strong industry backing and running code.

JP> I do not make this email took polemical but you also have stron= g industry disagreement in using such protocols for extremely
constrained LLNs to say the least.

Thanks.

JP.

The latter is crucial in the IETF.

Best regards
Ulrich


 

Thanks
-Bo



On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote:

> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and chart= er for MANET. Unfortunately, it is only a minor revision of the technical c= ontent, since we have been in discussions with the DYMO authors and the WG = leadership for several months on how to proceed with the reactive protocol in MANET. The chairs will likely rep= ly very soon to the list with an outcome of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A77220174EExmbrcdx02ciscoc_-- From teco@inf-net.nl Tue Oct 23 11:31:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AF71F0C91 for ; Tue, 23 Oct 2012 11:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+Z0rlJ9vwJe for ; Tue, 23 Oct 2012 11:31:14 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F68321F86E4 for ; Tue, 23 Oct 2012 11:31:14 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1787367eek.31 for ; Tue, 23 Oct 2012 11:31:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=So5VZrxNaMv9Ls0B/Zf95J0p++of81kzIfXGAhew3T8=; b=bLDqPQs8wcqACg8PdoQjm50U9lvUcB/FStyz7qPDZX+THj9fC8NkjWozOimADlfZeV s2K62dyiIG9YXQO2OB/kidCiEAMxEZPoUurAJaETTOa4aAbkX3XDqXNW49rAYxXEEmE3 jjc4ysP1zEmmVXH4QhSkWKWXAnljgbZL1EVa9KKpgEeD3RnoWkTb8yp3ism9kyYl8uz6 tTV12P2rGbsU0OAfEbem/MN0+n6UR2AyiX+rMGFgdoNayMbSLwKv0XnG29Zkjsg2R4yF +yujfu41d40sT8A4cQd6UXteORWK7J5zJzrf0MLwJMoO6MnYTHJRsMesrIpKFm656La7 KEMQ== Received: by 10.14.193.136 with SMTP id k8mr18084860een.30.1351017073343; Tue, 23 Oct 2012 11:31:13 -0700 (PDT) Received: from [10.175.173.28] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id d44sm22115160eeo.10.2012.10.23.11.31.11 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 11:31:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FDCC6312-89CB-4504-BB29-0919A34854A1" From: Teco Boot In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220174EE@xmb-rcd-x02.cisco.com> Date: Tue, 23 Oct 2012 20:31:10 +0200 Message-Id: <69C0ADDF-DD11-45CC-B12E-D351246958AE@inf-net.nl> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <03B78081B371D44390ED6E7BADBB4A7722014627@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220174EE@xmb-rcd-x02.cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlkyE6KbPc0AlMCxN9LQE/vFrA/m5FV2FztuJZ8UULNMS3Jb4d2YvS31uE2xtY26n1dI2mn Cc: "" , "Bo Berry \(boberry\)" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:31:21 -0000 --Apple-Mail=_FDCC6312-89CB-4504-BB29-0919A34854A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Op 23 okt. 2012, om 20:06 heeft JP Vasseur (jvasseur) het volgende = geschreven: > Hi Ulrich, >=20 > On Oct 23, 2012, at 5:19 PM, Ulrich Herberg wrote: >=20 >> Hi JP, >>=20 >> I was about to write a more detailed answer and then decided against = it. Bo asked a technical question, to which I replied. Let's wait what = the chairs say, then I may answer to your points. >>=20 >=20 > Sure, feel free not to answer. Your call. I fully respect it. >=20 > If you want to have a technical discussion on why (as individual = contributor) I think that LOAD-ng is a major issue for highly = constrained LLNs, > I would be more than happy to continue that discussion on the mailing = list. >=20 > That being said, my point was that DYMO/AODVv2 was a very good base to = complete the reactive routing work in MANET. Don't conclude to fast. AFAIK there is no WG decision to step back from = DYMO/AODVv2. It just was parked for a while. Can I assume that your point *is* that DYMO/AODVv2 *is* a very good base = to complete?=20 Teco >=20 > Best. >=20 > JP. >=20 >> Best >> Ulrich >>=20 >> On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" = wrote: >>=20 >>> Dear Ulrich, >>>=20 >>> Let me chine in since I do not think that we are in agreement with = your conclusions here - see below >>>=20 >>> On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote: >>>=20 >>>> Hi Bo, >>>>=20 >>>> On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry = wrote: >>>> Hi Alex >>>>=20 >>>> For those of us that have not have the opportunity to follow >>>> the Loadng discussions, could you please describe the similarities >>>> and the unique differences of Loadng relative to Dymo. I'm aware >>>> of the discussions about lousy nets and manets, but less between >>>> the two protocols. >>>>=20 >>>> I think this would help everyone on the WG understand the benefits. >>>>=20 >>>>=20 >>>> I agree with that, and it is a fair question to ask. Let me try to = list a few differences, others may chime in with more.=20 >>>>=20 >>>> First the commonalities: >>>> - Both are reactive protocols, based on AODV, with the intended = status of "Proposed Standard" (AODV is "Experimental"). The MANET = charter lists that the WG has to come up with a std. track reactive = protocol. Essentially, in a reactive protocol, routes are requested = "on-demand" (i.e. when there is data traffic and no route exists for the = destination of the data packet). Therefore, you will see similar message = types in both protocols (Route Requests, Route Replies, and Route = Errors), and essentially the same basic mechanism. >>>=20 >>> JP> It is worth that MANET has already a WG document, DYMO, which = has been discussed extensively in the WG. >>>=20 >>>> - Both are applicable to MANETs (see also below for your next = question), and both support RFC5444. LOADng is decoupling the mechanism = from the message format; RFC5444 is mapped to the mechanism, but other = message formats could easily be specified (e.g., with a more compressed = message format for extremely limited links in terms of bandwidth). >>>>=20 >>>> Now some differences: >>>> - Most importantly: LOADng has achieved what DYMO failed to do: to = gather broad industrial support from several large companies, several = large-scale deployments with several thousands of nodes, LOADng has an = updated MIB document, and documented interoperability test of at least = four recent implementations. >>>=20 >>> JP> If I may, this is more of a Marketing comment though. I do not = think that DYMO failed in any way. It turns out that the timing was = different, that's all. >>>=20 >>>> - Part of the reason, I believe, is that the writing style is very = different. LOADng has a more algorithmic way of writing. That's = immediate to see when you compare section 5.3 of DYMO with section 12 of = LOADng. It is, IMO, much harder to implement DYMO. The goal for LOADng = was to make it so straight forward to implement that an undergrad = student could take the spec, spend a few days implementing it and have a = reasonable and interoperable implementation. I have implemented LOADng = in one day, based on the specification. >>>=20 >>> JP> I personally saw several implementations of DYMO, and if we = require more algorithmic details about DYMO, let's provide comments to = the DYMO >>> authors. >>>=20 >>>> - There are multiple optional features in DYMO that have = deliberately not been included in LOADng (expanding ring multicasts, = intermediate RREPs, precursor lists etc). The reason was the following: = in an experimental protocol (AODV) it is fine to have many options, in = order to explore whether they are useful. We have that experience now = with AODV. For some of the options, such as iRREP, it has not been shown = over the last decade that they are of general use. In some cases, they = may be beneficial, but not in general. Also, they make it very hard to = provide end-to-end security. LOADng kept the mantra of a small, slim, = and efficient protocol. Having many options makes it hard to assure = interoperable devices out of the box, in particular if there is no = negotiation of capabilities. >>>> Moreover, reactive protocols are often used in cases where memory = is an extremely scarce resource, and where proactive protocols cannot be = used. That makes a slim design preferable, IMO, for such protocols. >>>=20 >>> JP> We can discuss further in Atlanta, but several of these options = are IMO quite useful. >>>=20 >>>> - LOADng may be used in other layers as L3, e.g. as mesh-under = protocol. >>>=20 >>> JP> Another concern =85 If you plan using LOAD-ng as a mesh under = protocol, this requires much more discussion (not sure that such = discussions >>> should take place at the IETF, but because this would be an IETF = work, we would need to discuss it further). Indeed, proposing to = standardize a >>> mesh-under protocol is not just a matter of manipulating MAC = addresses instead of IP addresses: there are tons of implications of the = architecture, >>> as described in details in = http://tools.ietf.org/html/draft-routing-architecture-iot-00 >>>=20 >>>> - LOADng supports optimized broadcasting mechanisms such as MPR = flooding >>>> - There is no Route Reply ACK in DYMO; this is part of LOADng to = verify bidirectionality of links; as in wireless channels, links are = rarely symmetric.=20 >>>> =20 >>>=20 >>> JP> Let's discuss further about these optimizations, which if = needed, could be added to DYMO. >>>=20 >>>>=20 >>>> Looking at the Tools page, the draft was first submitted October = 24, 2011, >>>> draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad = hoc >>>> Distance-vector Routing Protocol - Next Generation (LOADng)." The >>>> abstract included the statement "The protocol is derived >>>> from AODV and extended for use in LLNs". >>>>=20 >>>> Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the >>>> line "The protocol is derived from AODV (RFC3561) and extended for >>>> use in LLNs." was removed. This version also supported RFC 5444. >>>>=20 >>>> The draft posted tonight, October 22, 2012, = draft-clausen-lln-loadng-06, >>>> for the most part changes "Low power and Lossy Networks (LLN)" >>>> references to "Mobile Ad hoc NETworks (MANETs)." >>>>=20 >>>>=20 >>>> The draft started out from where the deployments exist, which some = call LLNs. >>>=20 >>> JP> As pointed out earlier, then I have two major concerns: >>> 1) If the reactive routing protocol deals with LLNs, especially = "hard constrained" LLNs as pointed out in this mailing list, >>> then I would strongly suggest to run the document by the two WGs, = MANET and ROLL. Let's see what the chairs decides. >>> 2) ROLL co-chair hat-off, I do see a number of issues using reactive = routing in hard constrained LLNs such as AMI PLC, >>> years of experience in routing in such networks show us that there = are major scalability issues (I am not referring to the number >>> of nodes, but also user traffic since depending on the user traffic = this may lead to massive control plane traffic churn to mention >>> one of the many issues). >>>=20 >>>> However, as a basic reactive protocol, LOADng also covers the more = general MANET case that includes a wider ranger of resources (from = extremely constrained to not-so-constrained) and mobility. In = particular, by supporting RFC5444 it fits well in the MANET architecture = and the surrounding security extensions, flooding optimizations and TLVs = etc. for RFC5444. >>>>=20 >>>> I hope I could shed some light on that question. I invite you to = read both drafts, there is probably more to say here. >>>>=20 >>>> I won't go into details here, but most of the discussions we had = were not so much about technical issues, but about procedural. LOADng = has started when DYMO was stalled for more than 2 years. I think we have = a well mature document, supported by strong industry backing and running = code. >>>=20 >>> JP> I do not make this email took polemical but you also have strong = industry disagreement in using such protocols for extremely >>> constrained LLNs to say the least. >>>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>>> The latter is crucial in the IETF. >>>>=20 >>>> Best regards >>>> Ulrich >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> Thanks >>>> -Bo >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote: >>>>=20 >>>> > Dear all, >>>> > >>>> > we have updated LOADng, to make it clear that it is in scope and = charter for MANET. Unfortunately, it is only a minor revision of the = technical content, since we have been in discussions with the DYMO = authors and the WG leadership for several months on how to proceed with = the reactive protocol in MANET. The chairs will likely reply very soon = to the list with an outcome of the discussion. >>>> > >>>> > Best regards, >>>> > >>>> > Axel Colin de Verdiere >>>> > >>>> > _______________________________________________ >>>> > manet mailing list >>>> > manet@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_FDCC6312-89CB-4504-BB29-0919A34854A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Ulrich,

On Oct 23, 2012, at 5:19 PM, Ulrich Herberg wrote:

Hi JP,

I was about to write a more detailed answer and then decided = against it. Bo asked a technical question, to which I replied. Let's = wait what the chairs say, then I may answer to your points.


Sure, feel free not to answer. Your call. I fully respect it.

If you want to have a technical discussion on why (as individual = contributor) I think that LOAD-ng is a major issue for highly = constrained LLNs,
I would be more than happy to continue that discussion on the = mailing list.

That being said, my point was that DYMO/AODVv2 was a very good base = to complete the reactive routing work in = MANET.

Don't = conclude to fast. AFAIK there is no WG decision to step back from = DYMO/AODVv2. It just was parked for a while.
Can I assume that = your point *is* that DYMO/AODVv2 *is* a very good base to = complete? 

Teco


Best.

JP.

Best
Ulrich

On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Dear Ulrich,

Let me chine in since I do not think that we are in agreement with = your conclusions here - see below

On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote:

Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry = <boberry@cisco.com> wrote:
Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities
and the unique differences of Loadng relative to Dymo.  I'm = aware
of the discussions about lousy nets and manets, but less between
the two protocols.

I think this would help everyone on the WG understand the benefits.


I agree with that, and it is a fair question to ask. Let me try to = list a few differences, others may chime in with more. 

First the commonalities:
 - Both are reactive protocols, based on AODV, with the = intended status of "Proposed Standard" (AODV is "Experimental"). The = MANET charter lists that the WG has to come up with a std. track = reactive protocol. Essentially, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and no route = exists for the destination of the data packet). Therefore, you will see = similar message types in both protocols (Route Requests, Route Replies, = and Route Errors), and essentially the same basic mechanism.

JP> It is worth that MANET has already a WG document, DYMO, = which has been discussed extensively in the WG.

- Both are applicable to MANETs (see also below for your next = question), and both support RFC5444. LOADng is decoupling the mechanism = from the message format; RFC5444 is mapped to the mechanism, but other = message formats could easily be specified (e.g., with a more compressed message format for extremely limited links in = terms of bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to = gather broad industrial support from several large companies, several = large-scale deployments with several thousands of nodes, LOADng has an = updated MIB document, and documented interoperability test of at least four recent implementations.

JP> If I may, this is more of a Marketing comment though. I do = not think that DYMO failed in any way. It turns out that the timing was = different, that's all.

- Part of the reason, I believe, is that the writing style is very = different. LOADng has a more algorithmic way of writing. That's = immediate to see when you compare section 5.3 of DYMO with section 12 of = LOADng. It is, IMO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement = that an undergrad student could take the spec, spend a few days = implementing it and have a reasonable and interoperable implementation. = I have implemented LOADng in one day, based on the specification.

JP> I personally saw several implementations of DYMO, and if we = require more algorithmic details about DYMO, let's provide comments to = the DYMO
authors.

- There are multiple optional features in DYMO that have = deliberately not been included in LOADng (expanding ring multicasts, = intermediate RREPs, precursor lists etc). The reason was the following: = in an experimental protocol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that = experience now with AODV. For some of the options, such as iRREP, it has = not been shown over the last decade that they are of general use. In = some cases, they may be beneficial, but not in general. Also, they make it very hard to provide end-to-end = security. LOADng kept the mantra of a small, slim, and efficient = protocol. Having many options makes it hard to assure interoperable = devices out of the box, in particular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory = is an extremely scarce resource, and where proactive protocols cannot be = used. That makes a slim design preferable, IMO, for such = protocols.

JP> We can discuss further in Atlanta, but several of these = options are IMO quite useful.

- LOADng may be used in other layers as L3, e.g. as mesh-under = protocol.

JP> Another concern =85 If you plan using LOAD-ng as a mesh = under protocol, this requires much more discussion (not sure that such = discussions
should take place at the IETF, but because this would be an IETF = work, we would need to discuss it further). Indeed, proposing to = standardize a
mesh-under protocol is not just a matter of manipulating MAC = addresses instead of IP addresses: there are tons of implications of the = architecture,

- LOADng supports optimized broadcasting mechanisms such as MPR = flooding
- There is no Route Reply ACK in DYMO; this is part of LOADng = to verify bidirectionality of links; as in wireless channels, links are = rarely symmetric. 
 

JP> Let's discuss further about these optimizations, which if = needed, could be added to DYMO.


Looking at the Tools page, the draft was first submitted October 24, = 2011,
draft-clausen-lln-loadng-00.  The title was, "The LLN On-demand Ad = hoc
Distance-vector Routing Protocol - Next Generation (LOADng)." =  The
abstract included the statement "The protocol is derived
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for
use in LLNs." was removed.  This version also supported RFC = 5444.

The draft posted tonight, October 22, 2012, = draft-clausen-lln-loadng-06,
for the most part changes "Low power and Lossy Networks (LLN)"
references to "Mobile Ad hoc NETworks (MANETs)."


The draft started out from where the deployments exist, which some = call LLNs.

JP> As pointed out earlier, then I have two major = concerns:
1) If the reactive routing protocol deals with LLNs, especially = "hard constrained" LLNs as pointed out in this mailing list,
then I would strongly suggest to run the document by the two WGs, = MANET and ROLL. Let's see what the chairs decides.
2) ROLL co-chair hat-off, I do see a number of issues using = reactive routing in hard constrained LLNs such as AMI PLC,
years of experience in routing in such networks show us that there = are major scalability issues (I am not referring to the number
of nodes, but also user traffic since depending on the user traffic = this may lead to massive control plane traffic churn to mention
one of the many issues).

However, as a basic reactive protocol, LOADng also covers the more = general MANET case that includes a wider ranger of resources (from = extremely constrained to not-so-constrained) and mobility. In = particular, by supporting RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding = optimizations and TLVs etc. for RFC5444.

I hope I could shed some light on that question. I invite you to = read both drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had = were not so much about technical issues, but about procedural. LOADng = has started when DYMO was stalled for more than 2 years. I think we have = a well mature document, supported by strong industry backing and running code.

JP> I do not make this email took polemical but you also have = strong industry disagreement in using such protocols for extremely
constrained LLNs to say the least.

Thanks.

JP.

The latter is crucial in the IETF.

Best regards
Ulrich


 

Thanks
-Bo



On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote:

> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and = charter for MANET. Unfortunately, it is only a minor revision of the = technical content, since we have been in discussions with the DYMO = authors and the WG leadership for several months on how to proceed with the reactive protocol in MANET. The chairs will likely = reply very soon to the list with an outcome of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

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


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

= --Apple-Mail=_FDCC6312-89CB-4504-BB29-0919A34854A1-- From jvasseur@cisco.com Tue Oct 23 12:13:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4C111E80A4 for ; Tue, 23 Oct 2012 12:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF8lpmorVe-F for ; Tue, 23 Oct 2012 12:13:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 20EAD21F8654 for ; Tue, 23 Oct 2012 12:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26406; q=dns/txt; s=iport; t=1351019604; x=1352229204; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TMIqmrGNxcpCS1F9w5w+7q9SlsVAUtpWo0mAt5edeh4=; b=VbYs1FbnamF7ukaCEeRJQ3urQ9C03/vMParG89gGkkz/QgIzJOCwKoeE e+AqUtdEJ03DSoNHaTXlKweSX0zDq92ScKUcDCcLvZOxJ2cS9nFKwEaSQ siLsXGsnCIKInUQlA4JhQzH1rOoFBySjbu6ilm6ZTfVg6Jg7HFQi8R11+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAKbrhlCtJV2a/2dsb2JhbABEuQcBiHWBCIIeAQEBAwEBAQEPAVsBCgULAgEIEhAdBycLFAMOAgQOBQgah1wGC5wFj1yQNItgFAeFY2ADkkCESY03gWuCb4FaCRce X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208,217";a="134593240" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2012 19:13:23 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NJDNYT014394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 19:13:23 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 14:13:23 -0500 From: "JP Vasseur (jvasseur)" To: Teco Boot Thread-Topic: [manet] LOADng-06 Thread-Index: AQHNsP6PoCdWGOst6kOKVbo4pjGngA== Date: Tue, 23 Oct 2012 19:13:22 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722017C76@xmb-rcd-x02.cisco.com> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <03B78081B371D44390ED6E7BADBB4A7722014627@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220174EE@xmb-rcd-x02.cisco.com> <69C0ADDF-DD11-45CC-B12E-D351246958AE@inf-net.nl> In-Reply-To: <69C0ADDF-DD11-45CC-B12E-D351246958AE@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--51.470700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722017C76xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" , "Bo Berry \(boberry\)" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 19:13:26 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722017C76xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 23, 2012, at 11:31 AM, Teco Boot wrote: Op 23 okt. 2012, om 20:06 heeft JP Vasseur (jvasseur) het volgende geschrev= en: Hi Ulrich, On Oct 23, 2012, at 5:19 PM, Ulrich Herberg wrote: Hi JP, I was about to write a more detailed answer and then decided against it. Bo= asked a technical question, to which I replied. Let's wait what the chairs= say, then I may answer to your points. Sure, feel free not to answer. Your call. I fully respect it. If you want to have a technical discussion on why (as individual contributo= r) I think that LOAD-ng is a major issue for highly constrained LLNs, I would be more than happy to continue that discussion on the mailing list. That being said, my point was that DYMO/AODVv2 was a very good base to comp= lete the reactive routing work in MANET. Don't conclude to fast. AFAIK there is no WG decision to step back from DYM= O/AODVv2. It just was parked for a while. Can I assume that your point *is* that DYMO/AODVv2 *is* a very good base to= complete? My bad, sorry for the typo "was" should read "is" ! Indeed, Teco, this what= I meant to say. Cheers. JP. Teco Best. JP. Best Ulrich On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" > wrote: Dear Ulrich, Let me chine in since I do not think that we are in agreement with your con= clusions here - see below On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote: Hi Bo, On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry > wrote: Hi Alex For those of us that have not have the opportunity to follow the Loadng discussions, could you please describe the similarities and the unique differences of Loadng relative to Dymo. I'm aware of the discussions about lousy nets and manets, but less between the two protocols. I think this would help everyone on the WG understand the benefits. I agree with that, and it is a fair question to ask. Let me try to list a f= ew differences, others may chime in with more. First the commonalities: - Both are reactive protocols, based on AODV, with the intended status of = "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that = the WG has to come up with a std. track reactive protocol. Essentially, in = a reactive protocol, routes are requested "on-demand" (i.e. when there is d= ata traffic and no route exists for the destination of the data packet). Th= erefore, you will see similar message types in both protocols (Route Reques= ts, Route Replies, and Route Errors), and essentially the same basic mechan= ism. JP> It is worth that MANET has already a WG document, DYMO, which has been = discussed extensively in the WG. - Both are applicable to MANETs (see also below for your next question), an= d both support RFC5444. LOADng is decoupling the mechanism from the message= format; RFC5444 is mapped to the mechanism, but other message formats coul= d easily be specified (e.g., with a more compressed message format for extr= emely limited links in terms of bandwidth). Now some differences: - Most importantly: LOADng has achieved what DYMO failed to do: to gather b= road industrial support from several large companies, several large-scale d= eployments with several thousands of nodes, LOADng has an updated MIB docum= ent, and documented interoperability test of at least four recent implement= ations. JP> If I may, this is more of a Marketing comment though. I do not think th= at DYMO failed in any way. It turns out that the timing was different, that= 's all. - Part of the reason, I believe, is that the writing style is very differen= t. LOADng has a more algorithmic way of writing. That's immediate to see wh= en you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, m= uch harder to implement DYMO. The goal for LOADng was to make it so straigh= t forward to implement that an undergrad student could take the spec, spend= a few days implementing it and have a reasonable and interoperable impleme= ntation. I have implemented LOADng in one day, based on the specification. JP> I personally saw several implementations of DYMO, and if we require mor= e algorithmic details about DYMO, let's provide comments to the DYMO authors. - There are multiple optional features in DYMO that have deliberately not b= een included in LOADng (expanding ring multicasts, intermediate RREPs, prec= ursor lists etc). The reason was the following: in an experimental protocol= (AODV) it is fine to have many options, in order to explore whether they a= re useful. We have that experience now with AODV. For some of the options, = such as iRREP, it has not been shown over the last decade that they are of = general use. In some cases, they may be beneficial, but not in general. Als= o, they make it very hard to provide end-to-end security. LOADng kept the m= antra of a small, slim, and efficient protocol. Having many options makes i= t hard to assure interoperable devices out of the box, in particular if the= re is no negotiation of capabilities. Moreover, reactive protocols are often used in cases where memory is an ext= remely scarce resource, and where proactive protocols cannot be used. That = makes a slim design preferable, IMO, for such protocols. JP> We can discuss further in Atlanta, but several of these options are IMO= quite useful. - LOADng may be used in other layers as L3, e.g. as mesh-under protocol. JP> Another concern =85 If you plan using LOAD-ng as a mesh under protocol,= this requires much more discussion (not sure that such discussions should take place at the IETF, but because this would be an IETF work, we w= ould need to discuss it further). Indeed, proposing to standardize a mesh-under protocol is not just a matter of manipulating MAC addresses inst= ead of IP addresses: there are tons of implications of the architecture, as described in details in http://tools.ietf.org/html/draft-routing-archite= cture-iot-00 - LOADng supports optimized broadcasting mechanisms such as MPR flooding - There is no Route Reply ACK in DYMO; this is part of LOADng to verify bid= irectionality of links; as in wireless channels, links are rarely symmetric= . JP> Let's discuss further about these optimizations, which if needed, could= be added to DYMO. Looking at the Tools page, the draft was first submitted October 24, 2011, draft-clausen-lln-loadng-00. The title was, "The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)." The abstract included the statement "The protocol is derived from AODV and extended for use in LLNs". Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the line "The protocol is derived from AODV (RFC3561) and extended for use in LLNs." was removed. This version also supported RFC 5444. The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)." The draft started out from where the deployments exist, which some call LLN= s. JP> As pointed out earlier, then I have two major concerns: 1) If the reactive routing protocol deals with LLNs, especially "hard const= rained" LLNs as pointed out in this mailing list, then I would strongly suggest to run the document by the two WGs, MANET and= ROLL. Let's see what the chairs decides. 2) ROLL co-chair hat-off, I do see a number of issues using reactive routin= g in hard constrained LLNs such as AMI PLC, years of experience in routing in such networks show us that there are majo= r scalability issues (I am not referring to the number of nodes, but also user traffic since depending on the user traffic this ma= y lead to massive control plane traffic churn to mention one of the many issues). However, as a basic reactive protocol, LOADng also covers the more general = MANET case that includes a wider ranger of resources (from extremely constr= ained to not-so-constrained) and mobility. In particular, by supporting RFC= 5444 it fits well in the MANET architecture and the surrounding security ex= tensions, flooding optimizations and TLVs etc. for RFC5444. I hope I could shed some light on that question. I invite you to read both = drafts, there is probably more to say here. I won't go into details here, but most of the discussions we had were not s= o much about technical issues, but about procedural. LOADng has started whe= n DYMO was stalled for more than 2 years. I think we have a well mature doc= ument, supported by strong industry backing and running code. JP> I do not make this email took polemical but you also have strong indust= ry disagreement in using such protocols for extremely constrained LLNs to say the least. Thanks. JP. The latter is crucial in the IETF. Best regards Ulrich Thanks -Bo On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote: > Dear all, > > we have updated LOADng, to make it clear that it is in scope and charter = for MANET. Unfortunately, it is only a minor revision of the technical cont= ent, since we have been in discussions with the DYMO authors and the WG lea= dership for several months on how to proceed with the reactive protocol in = MANET. The chairs will likely reply very soon to the list with an outcome o= f the discussion. > > Best regards, > > Axel Colin de Verdiere > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722017C76xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9C6062FECC42BF4EBD20883A16392527@cisco.com> Content-Transfer-Encoding: quoted-printable
On Oct 23, 2012, at 11:31 AM, Teco Boot wrote:


Op 23 okt. 2012, om 20:06 heeft JP Vasseur (jvasseur) het volgende ges= chreven:

Hi Ulrich,

On Oct 23, 2012, at 5:19 PM, Ulrich Herberg wrote:

Hi JP,

I was about to write a more detailed answer and then decided against i= t. Bo asked a technical question, to which I replied. Let's wait what the c= hairs say, then I may answer to your points.


Sure, feel free not to answer. Your call. I fully respect it.

If you want to have a technical discussion on why (as individual contr= ibutor) I think that LOAD-ng is a major issue for highly constrained LLNs,<= /div>
I would be more than happy to continue that discussion on the mailing = list.

That being said, my point was that DYMO/AODVv2 was a very good base to= complete the reactive routing work in MANET.

Don't conclude to fast. AFAIK there is no WG decision to step back fro= m DYMO/AODVv2. It just was parked for a while.
Can I assume that your point *is* that DYMO/AODVv2 *is* a very good ba= se to complete? 

My bad, sorry for the typo "was" should read "is" = ! Indeed, Teco, this what I meant to say.

Cheers.

JP.


Teco


Best.

JP.

Best
Ulrich

On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Dear Ulrich,

Let me chine in since I do not think that we are in agreement with you= r conclusions here - see below

On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote:

Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry <boberry@cisco.co= m> wrote:
Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities
and the unique differences of Loadng relative to Dymo.  I'm aware
of the discussions about lousy nets and manets, but less between
the two protocols.

I think this would help everyone on the WG understand the benefits.


I agree with that, and it is a fair question to ask. Let me try to lis= t a few differences, others may chime in with more. 

First the commonalities:
 - Both are reactive protocols, based on AODV, with the intended = status of "Proposed Standard" (AODV is "Experimental").= The MANET charter lists that the WG has to come up with a std. track react= ive protocol. Essentially, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and n= o route exists for the destination of the data packet). Therefore, you will= see similar message types in both protocols (Route Requests, Route Replies= , and Route Errors), and essentially the same basic mechanism.

JP> It is worth that MANET has already a WG document, DYMO, which h= as been discussed extensively in the WG.

- Both are applicable to MANETs (see also below for your next question= ), and both support RFC5444. LOADng is decoupling the mechanism from the me= ssage format; RFC5444 is mapped to the mechanism, but other message formats= could easily be specified (e.g., with a more compressed message format for extremely limited links in terms= of bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to gat= her broad industrial support from several large companies, several large-sc= ale deployments with several thousands of nodes, LOADng has an updated MIB = document, and documented interoperability test of at least four recent implementations.

JP> If I may, this is more of a Marketing comment though. I do not = think that DYMO failed in any way. It turns out that the timing was differe= nt, that's all.

- Part of the reason, I believe, is that the writing style is very dif= ferent. LOADng has a more algorithmic way of writing. That's immediate to s= ee when you compare section 5.3 of DYMO with section 12 of LOADng. It is, I= MO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that a= n undergrad student could take the spec, spend a few days implementing it a= nd have a reasonable and interoperable implementation. I have implemented L= OADng in one day, based on the specification.

JP> I personally saw several implementations of DYMO, and if we req= uire more algorithmic details about DYMO, let's provide comments to the DYM= O
authors.

- There are multiple optional features in DYMO that have deliberately = not been included in LOADng (expanding ring multicasts, intermediate RREPs,= precursor lists etc). The reason was the following: in an experimental pro= tocol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that ex= perience now with AODV. For some of the options, such as iRREP, it has not = been shown over the last decade that they are of general use. In some cases= , they may be beneficial, but not in general. Also, they make it very hard to provide end-to-end security. L= OADng kept the mantra of a small, slim, and efficient protocol. Having many= options makes it hard to assure interoperable devices out of the box, in p= articular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is a= n extremely scarce resource, and where proactive protocols cannot be used. = That makes a slim design preferable, IMO, for such protocols.

JP> We can discuss further in Atlanta, but several of these options= are IMO quite useful.

- LOADng may be used in other layers as L3, e.g. as mesh-under protoco= l.

JP> Another concern =85 If you plan using LOAD-ng as a mesh under p= rotocol, this requires much more discussion (not sure that such discussions=
should take place at the IETF, but because this would be an IETF work,= we would need to discuss it further). Indeed, proposing to standardize a
mesh-under protocol is not just a matter of manipulating MAC addresses= instead of IP addresses: there are tons of implications of the architectur= e,

- LOADng supports optimized broadcasting mechanisms such as MPR floodi= ng
- There is no Route Reply ACK in DYMO; this is part of LOADng to = verify bidirectionality of links; as in wireless channels, links are rarely= symmetric. 
 

JP> Let's discuss further about these optimizations, which if neede= d, could be added to DYMO.


Looking at the Tools page, the draft was first submitted October 24, 2011,<= br> draft-clausen-lln-loadng-00.  The title was, "The LLN On-demand A= d hoc
Distance-vector Routing Protocol - Next Generation (LOADng)."  Th= e
abstract included the statement "The protocol is derived
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for
use in LLNs." was removed.  This version also supported RFC 5444.=

The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06, for the most part changes "Low power and Lossy Networks (LLN)" references to "Mobile Ad hoc NETworks (MANETs)."


The draft started out from where the deployments exist, which some cal= l LLNs.

JP> As pointed out earlier, then I have two major concerns:
1) If the reactive routing protocol deals with LLNs, especially "= hard constrained" LLNs as pointed out in this mailing list,
then I would strongly suggest to run the document by the two WGs, MANE= T and ROLL. Let's see what the chairs decides.
2) ROLL co-chair hat-off, I do see a number of issues using reactive r= outing in hard constrained LLNs such as AMI PLC,
years of experience in routing in such networks show us that there are= major scalability issues (I am not referring to the number
of nodes, but also user traffic since depending on the user traffic th= is may lead to massive control plane traffic churn to mention
one of the many issues).

However, as a basic reactive protocol, LOADng also covers the more gen= eral MANET case that includes a wider ranger of resources (from extremely c= onstrained to not-so-constrained) and mobility. In particular, by supportin= g RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimizatio= ns and TLVs etc. for RFC5444.

I hope I could shed some light on that question. I invite you to read = both drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had were = not so much about technical issues, but about procedural. LOADng has starte= d when DYMO was stalled for more than 2 years. I think we have a well matur= e document, supported by strong industry backing and running code.

JP> I do not make this email took polemical but you also have stron= g industry disagreement in using such protocols for extremely
constrained LLNs to say the least.

Thanks.

JP.

The latter is crucial in the IETF.

Best regards
Ulrich


 

Thanks
-Bo



On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdi=E8re wrote:

> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and chart= er for MANET. Unfortunately, it is only a minor revision of the technical c= ontent, since we have been in discussions with the DYMO authors and the WG = leadership for several months on how to proceed with the reactive protocol in MANET. The chairs will likely rep= ly very soon to the list with an outcome of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

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

--_000_03B78081B371D44390ED6E7BADBB4A7722017C76xmbrcdx02ciscoc_-- From jvasseur@cisco.com Tue Oct 23 12:18:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43DC11E80E3 for ; Tue, 23 Oct 2012 12:18:31 -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.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX-YcYXBrYhl for ; Tue, 23 Oct 2012 12:18:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0E29611E80D9 for ; Tue, 23 Oct 2012 12:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18523; q=dns/txt; s=iport; t=1351019910; x=1352229510; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+WntOFHHoY+CdKui926ub+GroCFDwEASPqwlAak+PXE=; b=OR49BfGozQAer+wC9B8TsvcvXJbn/hqclS71YR4V8raE5WIo0dnT4yUJ fnSs3r4z3Rd8JLoW8vSwmCWWEyXliN06FUL6rV5gPjid2ocXyUdavgAO8 8COST/9hoyCoVchw24dTKsLLi9DmTwpna16iyujT7ia1HyAxywS8f4Aoi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFANHshlCtJXG8/2dsb2JhbABEuQcBiHWBCIIeAQEBAwEBAQEPAVQHCwULAgEIEhAdBycLFAMOAgQOBQgah1wGC5t0j1yQNItghX5gA4gmjmONN4Frgm+BYxce X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208,217";a="131593220" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2012 19:18:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9NJITr6028579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 19:18:29 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 14:18:29 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] LOADng-06 Thread-Index: AQHNsVMuoCdWGOst6kOKVbo4pjGngA== Date: Tue, 23 Oct 2012 19:18:28 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722017CF4@xmb-rcd-x02.cisco.com> References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <46EE1684-91A3-467E-9530-C9A02819AB6E@coe.drexel.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--55.880300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722017CF4xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 19:18:31 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722017CF4xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, [snip] On Oct 23, 2012, at 10:01 AM, Ulrich Herberg wrote: Just to be clear here: MANET is working on an improved version of AODV. I e= xpect a very similar performance of LOADng compared to AODV, and there are = dozens, maybe hundreds of papers about the performance of AODV. This is ver= y similar between OLSR and OLSRv2; I would be very surprised to see a signi= ficant performance difference between the two protocols, as they have the s= ame mechanism (however, OLSRv2 has several simplifications such as fewer me= ssage types and is more flexible because of RFC5444). The reason why MANET = has this discussion is to come up with a standards track version of AODV. JP> Note that there is no disagreement on the fact that AODV is a useful pr= otocol ! The issue is when it applies to highly constrained LLNs. For those having deploying dozens of thousands of nodes in such envir= onments, gathering a ton of data on these networks, it is legitimate to express real concern about the applicability of such proto= cols to LLNs. Hope to have a deep technical discussion at the IETF. So compared to AODV, LOADng has some improvements which are listed in the i= ntroduction: Compared to [RFC3561], LOADng is extend= ed as follows: o Optimized flooding is supported, reducing the overhead incurred by RREQ generation and flooding. If no optimized flooding operation is specified for a given deployment, classical flooding is used by default. o Different address lengths are supported - from full 16 octet IPv6 addresses over 8 octet EUI64 addresss [EUI64], 6 octet MAC addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet addresses such as [RFC4944]. The= only requirement is, that within a given routing domain, all addresses are of the same address length. o Control messages are carried by way of the Generalized MANET Packet/Message Format [RFC5444]. o Using [RFC5444], control messages= can include TLV (Type-Length- Value) elements, permitting protocol extensions to be developed. LOADng supports routing using arbitrary additive metrics, which can be specified as extensions to this protocol. > LOADng has an updated MIB document, and documented interoperability test = of at least four recent implementations. Are you referring to the 2 to 5 LLN node topologies pass/fail testing draft= (draft-lavenu-lln-loadng-interoperability-report-03)? Yes. Again, don't confuse that with a performance evaluation. It is purely = an interop document. > - Part of the reason, I believe, is that the writing style is very differ= ent. LOADng has a more algorithmic way of writing. That's immediate to see = when you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO,= much harder to implement DYMO. The goal for LOADng was to make it so strai= ght forward to implement that an undergrad student could take the spec, spe= nd a few days implementing it and have a reasonable and interoperable imple= mentation. I have implemented LOADng in one day, based on the specification= . Indeed, my PhD student also followed the specification and coding it was st= raight forward. I am glad to hear that. However we did have concerns about its performance in LLNs (which the deplo= yment efforts you spoke of seem to be), specially with regards to control o= verhead and end-to-end delay. One point to the control overhead: it is given by RFC5444. Unless there is = any fragmentation, I don't see a problem with that. Fragmentation is unlike= ly, even in some of the 802.15.4 layers, as there will be a maximum of two = addresses and about two TLVs in each message (you can easily to the math he= re how many octets that would be in RFC5444). Using MPR flooding or other o= ptimized flooding methods have shown to severely reduce the overhead as wel= l (and there are many studies showing the difference between classic floodi= ng and MPR flooding). In particular in cases where there are few communicat= ion end-points communicating with each other at the same time and only rare= ly there is data traffic, reactive protocols may have a much better perform= ance (no control traffic unless there is data traffic, and only 1 route sto= red at each router). And this is known to MANET WG for a long time, and rea= son for the current charter. There are other use cases, where reactive prot= ocols are not suitable, and proactive protocols are better, which is why we= have OLSR (and hopefully OLSRv2). On the delay, what are your requirements? Sure, if you need the traffic to = be delivered within 1ms, a reactive protocol may not be the right protocol = for you. Take a proactive protocol then. This is why, contrary to other WGs= , we don't have the approach of "one-size-fits-all". Because it simply depe= nds on the scenario and your requirements. Being a reactive protocol, its dependency on user traffic may overwelm the = network, which we did see in our simulation study. Again, that very much depends on the traffic scenario and the topology, and= if you use optimized flooding. I have never doubted that there are scenari= os where reactive protocols suck, but there are scenarios where they are be= tter than proactive ones. I have seen the email from Thierry that commented on results for 2000 nodes= AMI PLC network, but did not get a reply to my inquiry with respect to the= traffic used. > The draft started out from where the deployments exist, which some call L= LNs. However, as a basic reactive protocol, LOADng also covers the more gen= eral MANET case that includes a wider ranger of resources (from extremely c= onstrained to not-so-constrained) and mobility. In particular, by supportin= g RFC5444 it fits well in the MANET architecture and the surrounding securi= ty extensions, flooding optimizations and TLVs etc. for RFC5444. Again, I may have missed this, but do you have results from deployments wit= h mobile nodes? Pretty much all work that has been done on AODV gives you the performance. = This is how a WG works; there was an experimental protocol, there have been= experiments over the last 10 years or so. Now we improve the protocol by m= aking the frame format more flexible, by allowing for optimized flooding et= c. and make a standard tracks protocol (at least that's currently in the ch= arter and pending a decision of the chairs). As you stated, the deployment were the LOADng draft started from were all L= LNs, and I am still curious about the details of those studies. Do you have= a pointer to a documented study? As I am not one of those having a deployment that can be disclosed, I canno= t reply here. Best regards, Jau. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722017CF4xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2705C8B482086F45807319FE5B5E0C6F@cisco.com> Content-Transfer-Encoding: quoted-printable Hi,

[snip]

On Oct 23, 2012, at 10:01 AM, Ulrich Herberg wrote:



Just to be clear here: MANET is working on an improved version of AODV= . I expect a very similar performance of LOADng compared to AODV, and there= are dozens, maybe hundreds of papers about the performance of AODV. This i= s very similar between OLSR and OLSRv2; I would be very surprised to see a significant performance differe= nce between the two protocols, as they have the same mechanism (however, OL= SRv2 has several simplifications such as fewer message types and is more fl= exible because of RFC5444). The reason why MANET has this discussion is to come up with a standards track = version of AODV.


JP> Note that there is no disagreement on the fact that AODV is a u= seful protocol ! The issue is when it applies to highly constrained
LLNs. For those having deploying dozens of thousands of nodes in such = environments, gathering a ton of data on these networks, it
is legitimate to express real concern about the applicability of such = protocols to LLNs. Hope to have a deep technical discussion at 
the IETF.


So compared to AODV, LOADng has some improvements which are listed in = the introduction:

Compared to [RFC3561], =
LOADng is extended as follows:

   o  Optimized flooding is supported, reducing the overhead incurred by
      RREQ generation and flooding.  If no optimized flooding operation
      is specified for a given deployment, classical flooding is used by
      default.

   o  Different address lengths are supported - from full 16 octet IPv6
      addresses over 8 octet EUI64 addresss [EUI64=
], 6 octet MAC
      addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet
      addresses such as [RFC4944].  The only requirement is, that within
      a given routing domain, all addresses are of the same address
      length.

   o  Control messages are carried by way of the Generalized MANET
      Packet/Message Format [RFC5444].

   o  Using [RFC5=
444], control messages can include TLV (Type-Length-
      Value) elements, permitting protocol extensions to be developed.

   LOADng supports routing using arbitrary additive metrics, which can
   be specified as extensions to this protocol.

 

> LOADng has an updated MIB document, and documented interoperability te= st of at least four recent implementations.

Are you referring to the 2 to 5 LLN node topologies pass/fail testing draft= (draft-lavenu-lln-loadng-interoperability-report-03)?


Yes. Again, don't confuse that with a performance evaluation. It is pu= rely an interop document.

 

> - Part of the reason, I believe, is that the writing style is very dif= ferent. LOADng has a more algorithmic way of writing. That's immediate to s= ee when you compare section 5.3 of DYMO with section 12 of LOADng. It is, I= MO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that a= n undergrad student could take the spec, spend a few days implementing it a= nd have a reasonable and interoperable implementation. I have implemented L= OADng in one day, based on the specification.

Indeed, my PhD student also followed the specification and coding it was st= raight forward.


I am glad to hear that.
 

However we did have concerns about its performance in LLNs (which the deplo= yment efforts you spoke of seem to be), specially with regards to control o= verhead and end-to-end delay.  

One point to the control overhead: it is given by RFC5444. Unless ther= e is any fragmentation, I don't see a problem with that. Fragmentation is u= nlikely, even in some of the 802.15.4 layers, as there will be a maximum of= two addresses and about two TLVs in each message (you can easily to the math here how many octets that woul= d be in RFC5444). Using MPR flooding or other optimized flooding methods ha= ve shown to severely reduce the overhead as well (and there are many studie= s showing the difference between classic flooding and MPR flooding). In particular in cases where there are= few communication end-points communicating with each other at the same tim= e and only rarely there is data traffic, reactive protocols may have a much= better performance (no control traffic unless there is data traffic, and only 1 route stored at each rout= er). And this is known to MANET WG for a long time, and reason for the curr= ent charter. There are other use cases, where reactive protocols are not su= itable, and proactive protocols are better, which is why we have OLSR (and hopefully OLSRv2). 

On the delay, what are your requirements? Sure, if you need the traffi= c to be delivered within 1ms, a reactive protocol may not be the right prot= ocol for you. Take a proactive protocol then. This is why, contrary to othe= r WGs, we don't have the approach of "one-size-fits-all". Because it simply depends on the scenari= o and your requirements.

 
Being a reactive protocol, its dependency on user traffic may overwelm the = network, which we did see in our simulation study.


Again, that very much depends on the traffic scenario and the topology= , and if you use optimized flooding. I have never doubted that there are sc= enarios where reactive protocols suck, but there are scenarios where they a= re better than proactive ones.


 
I have seen the email from Thierry that commented on results for 2000 nodes= AMI PLC network, but did not get a reply to my inquiry with respect to the= traffic used.

> The draft started out from where the deployments exist, which some cal= l LLNs. However, as a basic reactive protocol, LOADng also covers the more = general MANET case that includes a wider ranger of resources (from extremel= y constrained to not-so-constrained) and mobility. In particular, by supporting RFC5444 it fits well in the MAN= ET architecture and the surrounding security extensions, flooding optimizat= ions and TLVs etc. for RFC5444.

Again, I may have missed this, but do you have results from deployments wit= h mobile nodes?


Pretty much all work that has been done on AODV gives you the performa= nce. This is how a WG works; there was an experimental protocol, there have= been experiments over the last 10 years or so. Now we improve the protocol= by making the frame format more flexible, by allowing for optimized flooding etc. and make a standard trac= ks protocol (at least that's currently in the charter and pending a decisio= n of the chairs).

 
As you stated, the deployment were the LOADng draft started from were all L= LNs, and I am still curious about the details of those studies. Do you have= a pointer to a documented study?

As I am not one of those having a deployment that can be disclosed, I = cannot reply here.

 


Best regards,

Jau.


Best regards
Ulrich 
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7722017CF4xmbrcdx02ciscoc_-- From thomas.r.henderson@boeing.com Tue Oct 23 16:43:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9B11E8112 for ; Tue, 23 Oct 2012 16:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+OihZO-bTDQ for ; Tue, 23 Oct 2012 16:43:49 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC511E80E2 for ; Tue, 23 Oct 2012 16:43:48 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9NNhjP1032401 for ; Tue, 23 Oct 2012 18:43:45 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9NNhiFb032388 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Oct 2012 18:43:45 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 23 Oct 2012 16:43:44 -0700 From: "Henderson, Thomas R" To: "'Dearlove, Christopher (UK)'" , Bo Berry Date: Tue, 23 Oct 2012 16:43:43 -0700 Thread-Topic: RFC 5444 and DLEP (was RE: [manet] status of components DLEP and consensus on them) Thread-Index: AQHNrIswe+sGTvqD/EmoU6f+wmIG35fGqRLggAALYgCAABDuUIAATrkA Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C1BC@XCH-NW-16V.nw.nos.boeing.com> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> <83AA0ADF-28AE-4B04-A073-2DBA9128407D@cisco.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 X-TM-AS-MML: No Cc: "" , "Stan Ratliff \(sratliff\)" Subject: [manet] RFC 5444 and DLEP (was RE: status of components DLEP and consensus on them) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:43:49 -0000 > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: Tuesday, October 23, 2012 4:22 AM > To: Bo Berry > Cc: ; Henderson, Thomas R; Stan Ratliff (sratliff) > Subject: RE: [manet] status of components DLEP and consensus on them >=20 > Agreeing with Stan that you shouldn't use 5444 is fine. And not all > voices are equal, document authors do, and I believe should, have more > weight than others. Nevertheless I don't think you've established that > there is a consensus against 5444. Tom Henderson's list would support > that, and as far as I can see, Tom provided a not so involved up to > that point viewpoint. I think at the moment opinions are split between > "not 5444" and "let's get to that later", but I wouldn't like to say > whether there's a consensus for the former. >=20 My perception is that there was not WG consensus on this, but that the auth= ors were not convinced to adopt 5444 or a revision of it. However, the dis= cussion/proposal of using 5444 seems to recur on the list since the questio= n of whether or not it is still an open issue is unclear. =20 What I had in mind, from a process standpoint for DLEP, is that a tracker i= ssue would be created, filled in, and closed on this topic, with summary of= what was discussed and decided. If this issue is indeed still open, then = it would be helpful to identify the currently available choices and how the= issue is planned to be resolved. =20 The primary discussion threads on this topic seem to have started at these = points in the MANET list earlier this year, with several useful summaries a= long the way of the alternatives and tradeoffs: 1) http://www.ietf.org/mail-archive/web/manet/current/msg12436.html 2) http://www.ietf.org/mail-archive/web/manet/current/msg12620.html 3) http://www.ietf.org/mail-archive/web/manet/current/msg13104.html 4) http://www.ietf.org/mail-archive/web/manet/current/msg13445.html I think that the next step would be for the authors and WG chairs to decide= whether to start using the tracker (I believe Teco also suggested it earli= er this month, and Charlie is using it on the reactive draft) and, if so, h= ow to summarize this issue's status in the tracker. Then we could try to i= dentify and tackle some others. I'd be willing to help but not if it will = be pushing uphill. - Tom p.s. (to the WG list participants) thank you for improving the DLEP subjec= t lines/threads recently since I commented on it, it has been helpful From jpmacker@gmail.com Tue Oct 23 18:20:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC37511E8163 for ; Tue, 23 Oct 2012 18:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFJr40DrjZlY for ; Tue, 23 Oct 2012 18:20:28 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 023A911E8149 for ; Tue, 23 Oct 2012 18:20:27 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5395685vcb.31 for ; Tue, 23 Oct 2012 18:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qlg5Akaodk78ZlEMTRhe3mAQnXh6uH6RHPTACRTWN/Y=; b=bJSCcSimBnXhD3I+f3ianUhy6uN9QH5YrylafY26kwl82RDAsSr4actXQBmBRIGLyw g3yN95/jhpefOIlKZ+zLTZ5POQUznm2rjJlVDXlEPg2FqwsGf7Ijddf3WKcUB6M3+yoJ QWlHbCn8111g4d7TbO7YP34Wfk0wBIz6EozN5CwTP1aRhMQzWhrqZF5AysZng3U4Wsom s/OdUw4k+eG1S7cTDWxqDqI7B/l/ejSGAMWmQzy6T3kwnG4lsIXKQnqtZMkHYNwaMDOh Y7H+AIu4xKXzOeR1pGUqkZ48v+zvqOCWDvj8vxuggN4UwGPvMKvwA6NzLhO8rHf/jd6B Dr3A== MIME-Version: 1.0 Received: by 10.52.68.19 with SMTP id r19mr19495548vdt.29.1351041625206; Tue, 23 Oct 2012 18:20:25 -0700 (PDT) Received: by 10.59.5.6 with HTTP; Tue, 23 Oct 2012 18:20:25 -0700 (PDT) In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C1BC@XCH-NW-16V.nw.nos.boeing.com> References: <758141CC3D829043A8C3164DD3D593EA2E4C38C183@XCH-NW-16V.nw.nos.boeing.com> <507E9FCB.40908@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F411637@xmb-aln-x03.cisco.com> <83AA0ADF-28AE-4B04-A073-2DBA9128407D@cisco.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C1BC@XCH-NW-16V.nw.nos.boeing.com> Date: Tue, 23 Oct 2012 21:20:25 -0400 Message-ID: From: Joseph Macker To: "Henderson, Thomas R" Content-Type: multipart/alternative; boundary=20cf3079bfca25aff904ccc3e418 Cc: "Dearlove, Christopher \(UK\)" , "" , Bo Berry , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] RFC 5444 and DLEP (was RE: status of components DLEP and consensus on them) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 01:20:30 -0000 --20cf3079bfca25aff904ccc3e418 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 23, 2012 at 7:43 PM, Henderson, Thomas R < thomas.r.henderson@boeing.com> wrote: > > > > -----Original Message----- > > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > > Sent: Tuesday, October 23, 2012 4:22 AM > > To: Bo Berry > > Cc: ; Henderson, Thomas R; Stan Ratliff (sratliff) > > Subject: RE: [manet] status of components DLEP and consensus on them > > > > Agreeing with Stan that you shouldn't use 5444 is fine. And not all > > voices are equal, document authors do, and I believe should, have more > > weight than others. Nevertheless I don't think you've established that > > there is a consensus against 5444. Tom Henderson's list would support > > that, and as far as I can see, Tom provided a not so involved up to > > that point viewpoint. I think at the moment opinions are split between > > "not 5444" and "let's get to that later", but I wouldn't like to say > > whether there's a consensus for the former. > > > > My perception is that there was not WG consensus on this, but that the > authors were not convinced to adopt 5444 or a revision of it. However, the > discussion/proposal of using 5444 seems to recur on the list since the > question of whether or not it is still an open issue is unclear. > > What I had in mind, from a process standpoint for DLEP, is that a tracker > issue would be created, filled in, and closed on this topic, with summary > of what was discussed and decided. If this issue is indeed still open, > then it would be helpful to identify the currently available choices and > how the issue is planned to be resolved. > > The primary discussion threads on this topic seem to have started at these > points in the MANET list earlier this year, with several useful summaries > along the way of the alternatives and tradeoffs: > > 1) http://www.ietf.org/mail-archive/web/manet/current/msg12436.html > 2) http://www.ietf.org/mail-archive/web/manet/current/msg12620.html > 3) http://www.ietf.org/mail-archive/web/manet/current/msg13104.html > 4) http://www.ietf.org/mail-archive/web/manet/current/msg13445.html > > I think that the next step would be for the authors and WG chairs to > decide whether to start using the tracker (I believe Teco also suggested it > earlier this month, and Charlie is using it on the reactive draft) and, if > so, how to summarize this issue's status in the tracker. Then we could try > to identify and tackle some others. I'd be willing to help but not if it > will be pushing uphill. > I think it is important to track these issues better and present resolutions/decisions if any. I believe using the tracker is a good idea. > > - Tom > > p.s. (to the WG list participants) thank you for improving the DLEP > subject lines/threads recently since I commented on it, it has been helpful > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf3079bfca25aff904ccc3e418 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 23, 2012 at 7:43 PM, Henders= on, Thomas R <thomas.r.henderson@boeing.com> wro= te:


> -----Original Message-----
> From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]
> Sent: Tuesday, October 23, 2012 4:22 AM
> To: Bo Berry
> Cc: <manet@ietf.org>; Hend= erson, Thomas R; Stan Ratliff (sratliff)
> Subject: RE: [manet] status of components DLEP and consensus on them >
> Agreeing with Stan that you shouldn't use 5444 is fine. And not al= l
> voices are equal, document authors do, and I believe should, have more=
> weight than others. Nevertheless I don't think you've establis= hed that
> there is a consensus against 5444. Tom Henderson's list would supp= ort
> that, and as far as I can see, Tom provided a not so involved up to > that point viewpoint. I think at the moment opinions are split between=
> "not 5444" and "let's get to that later", but = I wouldn't like to say
> whether there's a consensus for the former.
>

My perception is that there was not WG consensus on this, but that the auth= ors were not convinced to adopt 5444 or a revision of it. =A0However, the d= iscussion/proposal of using 5444 seems to recur on the list since the quest= ion of whether or not it is still an open issue is unclear.

What I had in mind, from a process standpoint for DLEP, is that a tracker i= ssue would be created, filled in, and closed on this topic, with summary of= what was discussed and decided. =A0If this issue is indeed still open, the= n it would be helpful to identify the currently available choices and how t= he issue is planned to be resolved.

The primary discussion threads on this topic seem to have started at these = points in the MANET list earlier this year, with several useful summaries a= long the way of the alternatives and tradeoffs:

1) http://www.ietf.org/mail-archive/web/manet/current/m= sg12436.html
2) http://www.ietf.org/mail-archive/web/manet/current/m= sg12620.html
3) http://www.ietf.org/mail-archive/web/manet/current/m= sg13104.html
4) http://www.ietf.org/mail-archive/web/manet/current/m= sg13445.html

I think that the next step would be for the authors and WG chairs to decide= whether to start using the tracker (I believe Teco also suggested it earli= er this month, and Charlie is using it on the reactive draft) and, if so, h= ow to summarize this issue's status in the tracker. =A0Then we could tr= y to identify and tackle some others. =A0I'd be willing to help but not= if it will be pushing uphill.


I think it is important to track these issues bet= ter and present resolutions/decisions if any. I believe using the tracker i= s a good idea.=A0
=A0

- Tom

p.s. =A0(to the WG list participants) thank you for improving the DLEP subj= ect lines/threads recently since I commented on it, it has been helpful
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf3079bfca25aff904ccc3e418-- From henning.rogge@fkie.fraunhofer.de Wed Oct 24 23:58:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9182311E80A3 for ; Wed, 24 Oct 2012 23:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMBdMIhcVqEe for ; Wed, 24 Oct 2012 23:58:44 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 8579511E808D for ; Wed, 24 Oct 2012 23:58:41 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TRHOo-0008Kg-Od; Thu, 25 Oct 2012 08:58:38 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TRHOo-0005ia-Lz; Thu, 25 Oct 2012 08:58:38 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Oct 2012 08:58:38 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 25 Oct 2012 08:58:38 +0200 Message-ID: <5088E2B5.60102@fkie.fraunhofer.de> Date: Thu, 25 Oct 2012 08:56:53 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040202010005020903020400" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 25 Oct 2012 06:58:38.0480 (UTC) FILETIME=[28DCE100:01CDB27E] X-Virus-Scanned: yes (ClamAV 0.97.6/15501/Wed Oct 24 21:49:29 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Cc: Bo Berry Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 06:58:46 -0000 --------------ms040202010005020903020400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I have uploaded my draft document to our eu-project webpage. I cannot=20 upload it to the IETF tracker at the moment because of the coming IETF. 'Stateless RFC5444-based Dynamic Link Exchange Protocol' started as a=20 document to show how a RFC5444 compliant DLEP specification could look=20 like, without using any kind of session mechanism between radio and=20 router. The current revision has been written a few weeks before the=20 IETF in Vancouver, so it does not contain changes related to DLEP-03. The protocol in the draft has three components: * Metric transport from the radio to the router * bi-directional transport of MAC/IP pair between radio and router=20 for arp-caching * controlling the radio by the router (at the moment a switch to turn = the radio on/off) The three components can be used independently of each other, components = not supported by one side do not disrupt the rest of the protocol. https://wiki.confine-project.eu/_media/pub:stateless_rfc5444-based_dynami= c_link_exchange_protocol.pdf Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040202010005020903020400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMjUwNjU4MzZaMCMGCSqGSIb3DQEJBDEWBBSJsRCYDw8qJN21BZ+N3OeZH9lSfDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEACfU+rQ6gay8DfE/okm1+rrX1VV/zDfoJS/ZMlYg3TXOl 4qoCAB4xWaP6mTEh6sLmWlq6nZk+e5gC+eLf8nJNsmWf+aXK7syAoREiPYopQ11TVQgR5lFz Ci3k2/FajFh6+gm8DnGsm/MqSFZ7lv9HARoNX2UHyiEIwqVIbj6G0q6nTKbaBZwJ8IpGA0pp EEFZZypCeTKWgqSRa8PHsmayHRoXpftTKamb+LYWpDLwVAnq9yrBXwOuFvwpKfYNkCyzK2Lz Z9Fj8unbb+7JAuDzcJxPPO1Ha926NT9bJ8VojJI/HNw5uRUsXN5lt7xDdPxNWuwuEUY+qwOv +gR6LPQGBAAAAAAAAA== --------------ms040202010005020903020400-- From abdussalambaryun@gmail.com Thu Oct 25 01:57:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7E521F890B for ; Thu, 25 Oct 2012 01:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWtSC3be7Hes for ; Thu, 25 Oct 2012 01:57:40 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E00DD21F89AC for ; Thu, 25 Oct 2012 01:57:39 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1680206vcb.31 for ; Thu, 25 Oct 2012 01:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OcYHg7kH3xmjU9+NCBD/nLwXkhMGiMx0BvGvJwE8x2s=; b=TtuJy1BJqDUtYCFM7As2wzFFsfg1znKO9lOYc/cheyixo/vS02y31n0qxarpSkQMYD WQfqjm/f4Fwbjku6mZ5+xQ/52aRskGvFCG0I9jywLbjVh69IViiN8R/YmadzxDAoYcui rrbBXxIEFwsA4m/2UxHwD8ImmxgEnJotXLMIqy0nYPG3bKsOcRmEFL+d2q/sgdfUzNMZ uiF72l9/RmvHlUyvW/8rFsOOcE0fuPDbUBEmUbDtQYF9mrIaGxLVz5Moeb/VdTzhl5rU qtZK9xNJtxZANu0WSR9txe89HlPgy9M5zwq+28fy8lklEK6Et+JEAy4UMbsIxgb0zt7j 4sdw== MIME-Version: 1.0 Received: by 10.220.154.68 with SMTP id n4mr12798294vcw.22.1351155459354; Thu, 25 Oct 2012 01:57:39 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 25 Oct 2012 01:57:39 -0700 (PDT) In-Reply-To: <5088E2B5.60102@fkie.fraunhofer.de> References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> <5088E2B5.60102@fkie.fraunhofer.de> Date: Thu, 25 Oct 2012 09:57:39 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=f46d043be0be30f13f04ccde65cf Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:57:42 -0000 --f46d043be0be30f13f04ccde65cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, I support the draft, will review, AB On Thu, Oct 25, 2012 at 7:56 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Hi, > > I have uploaded my draft document to our eu-project webpage. I cannot > upload it to the IETF tracker at the moment because of the coming IETF. > > > 'Stateless RFC5444-based Dynamic Link Exchange Protocol' started as a > document to show how a RFC5444 compliant DLEP specification could look > like, without using any kind of session mechanism between radio and route= r. > The current revision has been written a few weeks before the IETF in > Vancouver, so it does not contain changes related to DLEP-03. > > The protocol in the draft has three components: > > * Metric transport from the radio to the router > * bi-directional transport of MAC/IP pair between radio and router for > arp-caching > * controlling the radio by the router (at the moment a switch to turn > the radio on/off) > > The three components can be used independently of each other, components > not supported by one side do not disrupt the rest of the protocol. > > https://wiki.confine-project.**eu/_media/pub:stateless_** > rfc5444-based_dynamic_link_**exchange_protocol.pdf > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d043be0be30f13f04ccde65cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, I support the draft, will review,
=A0
AB
On Thu, Oct 25, 2012 at 7:56 AM, Hen= ning Rogge <henning.rogge@fkie.fraunhofer.de>= wrote:
Hi,

I have uploaded my draft document to our eu-project webpage. I cannot uploa= d it to the IETF tracker at the moment because of the coming IETF.


'Stateless RFC5444-based Dynamic Link Exchange Protocol' started as= a document to show how a RFC5444 compliant DLEP specification could look l= ike, without using any kind of session mechanism between radio and router. = The current revision has been written a few weeks before the IETF in Vancou= ver, so it does not contain changes related to DLEP-03.

The protocol in the draft has three components:

=A0 * Metric transport from the radio to the router
=A0 * bi-directional transport of MAC/IP pair between radio and router for = arp-caching
=A0 * controlling the radio by the router (at the moment a switch to turn t= he radio on/off)

The three components can be used independently of each other, components no= t supported by one side do not disrupt the rest of the protocol.

https://wiki.confi= ne-project.eu/_media/pub:stateless_rfc5444-based_dynamic_link= _exchange_protocol.pdf


Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--f46d043be0be30f13f04ccde65cf-- From ulrich@herberg.name Thu Oct 25 10:03:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A658121F89B9 for ; Thu, 25 Oct 2012 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrTtZ-iPRa5e for ; Thu, 25 Oct 2012 10:03:52 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E627021F89B6 for ; Thu, 25 Oct 2012 10:03:51 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2306830vbb.31 for ; Thu, 25 Oct 2012 10:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=bJY1AwA/ms+C1lf4UCUTkQhXDxgwDHDbO3COk/6ME5w=; b=OqEYsV8+Ekh5vGLP/Rly3ZT2fgG7FGReE+1PQSmIvOi9egoR2sTV2sxjadKEk51TKg 5YfJ20Ltze0kOxbYz7IVaOCC46EVz5L39AhvsXx0CfJL6Q3XppumQ+CUYAAtRbJ/BJzI n53ZSKGFbI09ZUpOFpU71dyeTLwk0E2rK+I2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=bJY1AwA/ms+C1lf4UCUTkQhXDxgwDHDbO3COk/6ME5w=; b=CNgbe95GLDxR75qShwi3P5yKPCv4rzyIJouEz11yB1lgM+VgixzI4bwD0HvEXV2xUR 234mIM3CmXpdXn85S/Z3vGgWMqRaWXTMBTxcO3agZ3t8N0f2/YFb1WsaRIcyhRxnUeze 82/h3AysXDuGS+qIiG+VVflC8bX/t9P7WBvQdB18jiZvMTqColyzBgUZE4EvVDN7nSaA k5zh+vz9S2P6Bd3Yt19noo5cJLsfMCi+V6pRlHufwR5Fr+zkkf2rAZeGG8BfcpdkpVCH WDt63wcLyrgBXqSavxrU2KXDbg1EtuoLAoN/e3RmGRLpo8Ks9hFZN7syLnu4TjjQ5NQK Zkfw== MIME-Version: 1.0 Received: by 10.220.225.132 with SMTP id is4mr15151892vcb.47.1351184631309; Thu, 25 Oct 2012 10:03:51 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 25 Oct 2012 10:03:51 -0700 (PDT) Date: Thu, 25 Oct 2012 10:03:51 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=14dae9ccd52cf9a6f904cce52f1b X-Gm-Message-State: ALoCoQkHJyULXRIMRYk0T+7SLeK6dmTqYCAU5OtAdkOh3Pw2QJQPvriVPcYd8w5+boakF421queK Subject: [manet] Agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 17:03:52 -0000 --14dae9ccd52cf9a6f904cce52f1b Content-Type: text/plain; charset=ISO-8859-1 Hello, I have uploaded an agenda draft to the meeting materials. This is a provisional draft agenda that has not yet been approved by the chairs. The chairs would be within their rights to make multiple changes to the agenda. I have only posted this as a starting point because I know both chairs are away from Internet at the moment. As usual, please send your comments to the list, and I am sure the chairs will pick them up and make any changes necessary. Best regards Ulrich --14dae9ccd52cf9a6f904cce52f1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I have uploaded an agenda draft to the meeting ma= terials.

This is a provisional draft agenda that h= as not yet been approved by the chairs. The chairs would be within their ri= ghts to make multiple changes to the agenda. I have only posted this as a s= tarting point because I know both chairs are away from Internet at the mome= nt. As usual, please send your comments to the list, and I am sure the chai= rs will pick them up and make any changes necessary.

Best regards
Ulrich
--14dae9ccd52cf9a6f904cce52f1b-- From ulrich@herberg.name Thu Oct 25 10:04:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE7621F89BB for ; Thu, 25 Oct 2012 10:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy+Ki9E52vQj for ; Thu, 25 Oct 2012 10:04:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 288B221F89B0 for ; Thu, 25 Oct 2012 10:04:57 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2308165vbb.31 for ; Thu, 25 Oct 2012 10:04:56 -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 :content-type; bh=j1pd1Cz76Dk9/p+O5737ThuUmXvDd+HBKPVCPjQg6yU=; b=v5gkmbQB7GgJF3+1yhiOaZ8UyrMirAdLUbtvwn6Y3PjXSMIRvr5z8ub2zo31JqTy5R CYm7Cc1aaW+CzjPRi1UUH3LXxcDT3fCozGA6HCIrXObHOfEwBis6uGtdrhXfmjz7es2W QMgP6qefEm59gN+UFFxn3/SkeP6MVlhATjxxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=j1pd1Cz76Dk9/p+O5737ThuUmXvDd+HBKPVCPjQg6yU=; b=JU5nBuNr6lS5wl515lqXHsXwrGjz8TRkxgtexfnS2WMY0n0imk/gr/KxiYoiv8N9co 3idKlwsCa2bRpiYn/5gKwnCzI7RjaiboJnjIE0U51CZureYVydhfDvcKp9BVi+L5HSIv NQao0X8sZrLCgzajnGXMUDqRV9rHWKfe11FwqgVyWiNOsWapE9eH3z9SLGUQtrzB3IAX 1ZGWM+65ab/Np+PD2lZMaL1KPD6jRijcCS2QLM2Y2hljcSJme+/mG+k2bnWVCw681erq fUyhz7ibU7ev/1LQ3YjwbYSuNNLV0o81Flzi0N3PeCeJ/vqL4BCSgnFXIcBkW8gRJ/Od t0uQ== MIME-Version: 1.0 Received: by 10.220.150.82 with SMTP id x18mr15388167vcv.73.1351184693696; Thu, 25 Oct 2012 10:04:53 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 25 Oct 2012 10:04:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Oct 2012 10:04:53 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d043c7c1eb1988b04cce5330e X-Gm-Message-State: ALoCoQkDP6HwFYqCE1DDfyR/L2M1nzvwP6OCkBUNCd1+EMxJe/BrgSayi8fGE5dASeTRoKSw1Fs4 Subject: Re: [manet] Agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 17:04:58 -0000 --f46d043c7c1eb1988b04cce5330e Content-Type: text/plain; charset=ISO-8859-1 P.S. Here is the direct link: http://www.ietf.org/proceedings/85/agenda/agenda-85-manet On Thu, Oct 25, 2012 at 10:03 AM, Ulrich Herberg wrote: > Hello, > > I have uploaded an agenda draft to the meeting materials. > > This is a provisional draft agenda that has not yet been approved by the > chairs. The chairs would be within their rights to make multiple changes to > the agenda. I have only posted this as a starting point because I know both > chairs are away from Internet at the moment. As usual, please send your > comments to the list, and I am sure the chairs will pick them up and make > any changes necessary. > > Best regards > Ulrich > --f46d043c7c1eb1988b04cce5330e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable P.S. Here is the direct link:
http://www.ietf.org/proceedings/85/agenda/agen= da-85-manet

On Thu, Oct 25, 2012 at 1= 0:03 AM, Ulrich Herberg <ulrich@herberg.name> wrote:
Hello,

I have uploaded an= agenda draft to the meeting materials.

This is a = provisional draft agenda that has not yet been approved by the chairs. The = chairs would be within their rights to make multiple changes to the agenda.= I have only posted this as a starting point because I know both chairs are= away from Internet at the moment. As usual, please send your comments to t= he list, and I am sure the chairs will pick them up and make any changes ne= cessary.

Best regards
Ulrich

--f46d043c7c1eb1988b04cce5330e-- From jasteven@rockwellcollins.com Thu Oct 25 12:33:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A20D21F889E for ; Thu, 25 Oct 2012 12:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkk-fNy2H+Zn for ; Thu, 25 Oct 2012 12:33:01 -0700 (PDT) Received: from secvs01.rockwellcollins.com (secvs01.rockwellcollins.com [205.175.225.240]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8C721F887E for ; Thu, 25 Oct 2012 12:33:01 -0700 (PDT) Received: from nosuchhost.198.131.in-addr.arpa (HELO collinscrsmtp02.rockwellcollins.com) ([131.198.63.133]) by mail-virt.rockwellcollins.com with ESMTP; 25 Oct 2012 14:33:00 -0500 In-Reply-To: To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF1303 November 21, 2007 From: jasteven@rockwellcollins.com Message-ID: Date: Thu, 25 Oct 2012 14:32:58 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 8.5.2FP2 HF162|May 16, 2011) at 10/25/2012 02:33:01 PM, Serialize complete at 10/25/2012 02:33:01 PM Content-Type: multipart/alternative; boundary="=_alternative 006AD00186257AA2_=" Subject: [manet] Oct 2012 IEEE Communications Magazine article discussing DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 19:33:02 -0000 This is a multipart message in MIME format. --=_alternative 006AD00186257AA2_= Content-Type: text/plain; charset="US-ASCII" I finally finished catching up on over a month of manet emails and don't remember seeing any mention of the Oct 2012 IEEE Communications Magazine article on "Radio-to-router interface technology and its applicability on the tactical edge" by Bow-Nan Cheng, James Wheeler, and Leonid Veytser of MIT Lincoln Laboratory. The article discusses the need for radio to router interface (R2RI) protocols for smart cross-layer multihop routing. The article examines and compares - RFC 5578 [PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics], - R2CP (Radio-to-Router Protocol), and - DLEP. The article can be found at http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6316778 I thought the article did a good job of discussing the issues of developing such R2RI protocols and the advantages and disadvantages of RFC 5578, R3CP, and DLEP. Some of the R2RI issues I thought particularly applicable to the manet area I work in are paragraphs entitled "Flow Control", "Variable Rate and Power Radio Systems", "R2RI Handling of Multicast Flows", "Link Metric Dampening and Hysteresis", and "Link Load Affect on Link Metrics". I also agreed with the statement that I think is general (although only stated in the paragraph on RFC 5578 disadvantages) that "Lack of a proper feed-forward mechanism [e.g., router-to-radio requests]: Military radio systems often need some information about incoming traffic to allocate time slots and perform resource management." The article discusses in the paragraph entitled "Radios' Bridge-Mode Capability" that "a basic assumption of R2RI is that future systems will allow bypassing of built-in multihop routing techniques, allowing the radio to merely act as a layer 2 RF link." I agree that this makes sense for many (most?) cases, and in particular high-speed directional backbone radios. However, I think that R2RI protocols should also support radios to perform built-in multihop routing where it makes sense, such as low capacity, edge, manets networks where the nodes often only have a single network interface (i.e., the manet radio network) and radio multihop routing optimizations can significantly improve performance. Jim Stevens --=_alternative 006AD00186257AA2_= Content-Type: text/html; charset="US-ASCII"
I finally finished catching up on over a month of manet emails and don't remember seeing any mention of the Oct 2012 IEEE Communications Magazine article on "Radio-to-router interface technology and its applicability on the tactical edge" by Bow-Nan Cheng, James Wheeler, and Leonid Veytser of MIT Lincoln Laboratory.

The article discusses the need for radio to router interface (R2RI) protocols for smart cross-layer multihop routing.  The article examines and compares
- RFC 5578 [PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics],
- R2CP (Radio-to-Router Protocol), and
- DLEP.

The article can be found at
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6316778

I thought the article did a good job of discussing the issues of developing such R2RI protocols and the advantages and disadvantages of RFC 5578, R3CP, and DLEP.

Some of the R2RI issues I thought particularly applicable to the manet area I work in are paragraphs entitled "Flow Control", "Variable Rate and Power Radio Systems", "R2RI Handling of Multicast Flows", "Link Metric Dampening and Hysteresis", and "Link Load Affect on Link Metrics".  I also agreed with the statement that I think is general (although only stated in the paragraph on RFC 5578 disadvantages) that "Lack of a proper feed-forward mechanism [e.g., router-to-radio requests]: Military radio systems often need some information about incoming traffic to allocate time slots and perform resource management."

The article discusses in the paragraph entitled "Radios' Bridge-Mode Capability" that "a basic assumption of R2RI is that future systems will allow bypassing of built-in multihop routing techniques, allowing the radio to merely act as a layer 2 RF link."  I agree that this makes sense for many (most?) cases, and in particular high-speed directional backbone radios.  However, I think that R2RI protocols should also support radios to perform built-in multihop routing where it makes sense, such as low capacity, edge, manets networks where the nodes often only have a single network interface (i.e., the manet radio network) and radio multihop routing optimizations can significantly improve performance.  

Jim Stevens
--=_alternative 006AD00186257AA2_=-- From boberry@cisco.com Fri Oct 26 03:33:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB3721F84DF for ; Fri, 26 Oct 2012 03:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldZAlPPgOcbX for ; Fri, 26 Oct 2012 03:33:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABA121F84C7 for ; Fri, 26 Oct 2012 03:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2917; q=dns/txt; s=iport; t=1351247582; x=1352457182; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VSd0n5SlsvJOicV0Vjj1LZ5ZZ613Xw+JLZ9ZZ0VNfMU=; b=XObcLOtAxN2uNJ+6pjkGqsBuCMmZSAFfPIzFfQef3zKVjOeVCuQGttRK 0BuI86/eU481p5V2o+t0MaJdoui9dSRUXKu329oVN2KlCWew5Nl0ncVK+ QL1KdFLR2CWYQTjd8wUniGT52MwmTtB6nkDqF8mC8ee+h55lnunm6uncI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAFmilCtJXG9/2dsb2JhbABEwjaBCIIeAQEBAwEBAQEPASc0CxALRicwGSKHXAYLnHigDYtoG4MvgkNhA5V2gReET4hsgWuDCw X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="135632491" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 26 Oct 2012 10:33:01 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-118.cisco.com [10.81.230.118]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9QAX13K023355; Fri, 26 Oct 2012 10:33:01 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Fri, 26 Oct 2012 06:33:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05E7FFC0-E893-4A52-8191-08941519F7AA@cisco.com> References: To: jasteven@rockwellcollins.com X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] Oct 2012 IEEE Communications Magazine article discussing DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 10:33:03 -0000 Jim Thanks for sharing this article. The MIT Team did a lot of great work! If you have specific requirements/suggestions for feed-forward needs, = please let us know. DLEP is also reserving a number of experimental TLVs. If needed, these = can be used to further develop various concepts. Thanks -Bo On Oct 25, 2012, at 3:32 PM, wrote: >=20 > I finally finished catching up on over a month of manet emails and = don't remember seeing any mention of the Oct 2012 IEEE Communications = Magazine article on "Radio-to-router interface technology and its = applicability on the tactical edge" by Bow-Nan Cheng, James Wheeler, and = Leonid Veytser of MIT Lincoln Laboratory.=20 >=20 > The article discusses the need for radio to router interface (R2RI) = protocols for smart cross-layer multihop routing. The article examines = and compares=20 > - RFC 5578 [PPP over Ethernet (PPPoE) Extensions for Credit Flow and = Link Metrics],=20 > - R2CP (Radio-to-Router Protocol), and=20 > - DLEP.=20 >=20 > The article can be found at=20 > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6316778=20 >=20 > I thought the article did a good job of discussing the issues of = developing such R2RI protocols and the advantages and disadvantages of = RFC 5578, R3CP, and DLEP.=20 >=20 > Some of the R2RI issues I thought particularly applicable to the manet = area I work in are paragraphs entitled "Flow Control", "Variable Rate = and Power Radio Systems", "R2RI Handling of Multicast Flows", "Link = Metric Dampening and Hysteresis", and "Link Load Affect on Link = Metrics". I also agreed with the statement that I think is general = (although only stated in the paragraph on RFC 5578 disadvantages) that = "Lack of a proper feed-forward mechanism [e.g., router-to-radio = requests]: Military radio systems often need some information about = incoming traffic to allocate time slots and perform resource = management."=20 >=20 > The article discusses in the paragraph entitled "Radios' Bridge-Mode = Capability" that "a basic assumption of R2RI is that future systems will = allow bypassing of built-in multihop routing techniques, allowing the = radio to merely act as a layer 2 RF link." I agree that this makes = sense for many (most?) cases, and in particular high-speed directional = backbone radios. However, I think that R2RI protocols should also = support radios to perform built-in multihop routing where it makes = sense, such as low capacity, edge, manets networks where the nodes often = only have a single network interface (i.e., the manet radio network) and = radio multihop routing optimizations can significantly improve = performance. =20 >=20 > Jim Stevens=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Fri Oct 26 17:28:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6821F8632 for ; Fri, 26 Oct 2012 17:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh6wCRVaqrgG for ; Fri, 26 Oct 2012 17:28:47 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 559F021F8644 for ; Fri, 26 Oct 2012 17:28:47 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TRuGc-0003Jj-Td for manet@ietf.org; Fri, 26 Oct 2012 20:28:46 -0400 Message-ID: <508B2AB9.10005@computer.org> Date: Fri, 26 Oct 2012 17:28:41 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad869c01916b64a7248cdf7cdda9cf35be11350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: [manet] Use of RFC 5444 in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 00:28:48 -0000 Hello folks, Several people have pointed out to me that DYMO and now AODVv2 have not really been conformant with the design of RFC 5444. I have studied this matter in some detail, and it turns out to be quite confusing. In order to avoid getting confused over and over again, I wrote up a long description of a design evolution, first correcting errors that had to be corrected, and aiming towards a more serviceable design for the "usual" cases that would be probably encountered in AODVv2 networks. I expect to include this as an appendix in the next revision of AODVv2, which I will make available next week. In the meantime, I have put the following text on my website, for anyone interested. http://www.psg.com/~charliep/AODVv2-rfc5444-ideas.txt I still need to proofread it, but it's mostly correct, and if it is acceptable then it will pretty much form a roadmap for the design of the RFC 5444 formats for other AODVv2 messages (RREP and RERR). I have also had several people express frustration that the document is not easy to read. I have always thought that myself, and I have come up with some changes in terminology that might go a long way towards helping with that. For instance, I define "router client" to be a host in an AODVv2 network that relies on the service of an AODVv2 router, but is not itself an AODVv2 router. It is intended that a "router client" doesn't have to know anything about AODVv2. This avoids having to use the previous terminology about "router responsibility" which did not seem to illuminate the concepts very well. I'll make a more complete proposal for changing terminology early next week. Please excuse the remaining errors in the recently released version of AODVv2. I wish I had started much much earlier to do these revisions. Lastly, it is my intention to submit these changes also as issues in the issue tracker. There are at least a half-dozen such issues that need to be included -- some small, some (like RFC 5444 compliance) not so small. -- Regards, Charlie P. From abdussalambaryun@gmail.com Sun Oct 28 04:00:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9921F85CB for ; Sun, 28 Oct 2012 04:00:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApYLYl8rUSmk for ; Sun, 28 Oct 2012 04:00:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3439F21F85C7 for ; Sun, 28 Oct 2012 04:00:29 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4673669vcb.31 for ; Sun, 28 Oct 2012 04:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3tB2RtapgjWadZ6ffhHCos9212wXHuV+XuhgT+usHS0=; b=Q2Q7gUnZIEX87tW1Fp4UEXi5aC9JOMB6bk7P84Tg0IeGnk+pG3J0frNiylw8BiJYCV DTSrlkcOpE3iRVV2STMu/rbhLyQPkyqFhX69Q96ztzAJLJBObTxGcpamY0iHY/6FI817 ZD8Pu7yBblydTd7asF3CJDV9ivVjtw4TX+r2jd1J+47LXcIoVyFmZBaVNoE+/+4r2sPo pTLCBLKGgnsd80zf/6RBaIGctqFrNVea4mgKkvoY3MQkxHDc6hu+oQGeGqtsS5M6ZjzZ 4qsT7k6B9s4YiVd8RRVibuqwra72LW/r6CJo1+evgg5Xd/uomK2yhhz6YHtNZG5elTOL 9d8Q== MIME-Version: 1.0 Received: by 10.58.137.7 with SMTP id qe7mr42738905veb.23.1351422028539; Sun, 28 Oct 2012 04:00:28 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sun, 28 Oct 2012 04:00:28 -0700 (PDT) In-Reply-To: <508B2AB9.10005@computer.org> References: <508B2AB9.10005@computer.org> Date: Sun, 28 Oct 2012 12:00:28 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Use of RFC 5444 in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 11:00:31 -0000 Hi Charlie, If you are suggesting to modify the RFC5444 packet format, I agree to make modification to RFC5444 to fit our reactive standards. AB On 10/27/12, Charles E. Perkins wrote: > > Hello folks, > > Several people have pointed out to me that DYMO and now AODVv2 have > not really been conformant with the design of RFC 5444. I have studied > this > matter in some detail, and it turns out to be quite confusing. In order to > avoid getting confused over and over again, I wrote up a long description > of a design evolution, first correcting errors that had to be corrected, > and > aiming towards a more serviceable design for the "usual" cases that would > be probably encountered in AODVv2 networks. > > I expect to include this as an appendix in the next revision of AODVv2, > which I will make available next week. In the meantime, I have put the > following text on my website, for anyone interested. > http://www.psg.com/~charliep/AODVv2-rfc5444-ideas.txt > I still need to proofread it, but it's mostly correct, and if it is > acceptable > then it will pretty much form a roadmap for the design of the RFC 5444 > formats for other AODVv2 messages (RREP and RERR). > > I have also had several people express frustration that the document is > not easy to read. I have always thought that myself, and I have come up > with some changes in terminology that might go a long way towards > helping with that. For instance, I define "router client" to be a host in > an AODVv2 network that relies on the service of an AODVv2 router, > but is not itself an AODVv2 router. It is intended that a "router client" > doesn't have to know anything about AODVv2. This avoids having to > use the previous terminology about "router responsibility" which did > not seem to illuminate the concepts very well. > > I'll make a more complete proposal for changing terminology early > next week. Please excuse the remaining errors in the recently released > version of AODVv2. I wish I had started much much earlier to do these > revisions. > > Lastly, it is my intention to submit these changes also as issues in the > issue tracker. There are at least a half-dozen such issues that need to be > included -- some small, some (like RFC 5444 compliance) not so small. > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From hrogge@googlemail.com Sun Oct 28 07:43:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0521F85F3 for ; Sun, 28 Oct 2012 07:43:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tN95iBsPyAp for ; Sun, 28 Oct 2012 07:43:57 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6160721F861F for ; Sun, 28 Oct 2012 07:43:57 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2792021pad.31 for ; Sun, 28 Oct 2012 07:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gVUDZYH/EKGmK3iHcfmLTINAnPI/mVSddPItF/XWHtU=; b=YcOF+LHb5y49vwuhKbBenWGduu7Z3Izf1g9vMDNYvIcKqL2GCU6NKOgr/qWU98bCVT 7kFwyMML7zDwgCcJH2ChfUcTJbTpBS2Uk8iUAyNptNdojjRWBIkIEuZbkrZKGqkJOtbo WPKsJXb4ZYNiUTwQnulM24wzdx4XQxBC9OwkH+EJhAN5SlqwWvnUNRQIVsbOuDNRrNga 6foIHg8y1a4pY7NmWl2U0g0aQUCSccuR+i742nd/rSe1rpHe6Sfputa7CxuuJXq2syKT 5qYNtFkwjM1M2NR2aA0uDC1WM/32GXvgB3hnXXVDPDIN0/3eYCIMc2Nt0LxkOkJTDFkn eugg== Received: by 10.68.226.162 with SMTP id rt2mr84976023pbc.62.1351435437135; Sun, 28 Oct 2012 07:43:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Sun, 28 Oct 2012 07:43:37 -0700 (PDT) In-Reply-To: References: <508B2AB9.10005@computer.org> From: Henning Rogge Date: Sun, 28 Oct 2012 15:43:37 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: MANET IETF Subject: Re: [manet] Use of RFC 5444 in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 14:43:58 -0000 I dont think we need to change RFC544 for reactive protocols. Henning Rogge Am 28.10.2012 12:00 schrieb "Abdussalam Baryun" : > > Hi Charlie, > > If you are suggesting to modify the RFC5444 packet format, I agree to > make modification to RFC5444 to fit our reactive standards. > > AB > > On 10/27/12, Charles E. Perkins wrote: > > > > Hello folks, > > > > Several people have pointed out to me that DYMO and now AODVv2 have > > not really been conformant with the design of RFC 5444. I have studied > > this > > matter in some detail, and it turns out to be quite confusing. In order to > > avoid getting confused over and over again, I wrote up a long description > > of a design evolution, first correcting errors that had to be corrected, > > and > > aiming towards a more serviceable design for the "usual" cases that would > > be probably encountered in AODVv2 networks. > > > > I expect to include this as an appendix in the next revision of AODVv2, > > which I will make available next week. In the meantime, I have put the > > following text on my website, for anyone interested. > > http://www.psg.com/~charliep/AODVv2-rfc5444-ideas.txt > > I still need to proofread it, but it's mostly correct, and if it is > > acceptable > > then it will pretty much form a roadmap for the design of the RFC 5444 > > formats for other AODVv2 messages (RREP and RERR). > > > > I have also had several people express frustration that the document is > > not easy to read. I have always thought that myself, and I have come up > > with some changes in terminology that might go a long way towards > > helping with that. For instance, I define "router client" to be a host in > > an AODVv2 network that relies on the service of an AODVv2 router, > > but is not itself an AODVv2 router. It is intended that a "router client" > > doesn't have to know anything about AODVv2. This avoids having to > > use the previous terminology about "router responsibility" which did > > not seem to illuminate the concepts very well. > > > > I'll make a more complete proposal for changing terminology early > > next week. Please excuse the remaining errors in the recently released > > version of AODVv2. I wish I had started much much earlier to do these > > revisions. > > > > Lastly, it is my intention to submit these changes also as issues in the > > issue tracker. There are at least a half-dozen such issues that need to be > > included -- some small, some (like RFC 5444 compliance) not so small. > > > > -- > > Regards, > > Charlie P. > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Mon Oct 29 07:27:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431C121F8529 for ; Mon, 29 Oct 2012 07:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nclDLh+GdaQy for ; Mon, 29 Oct 2012 07:27:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A86C121F866C for ; Mon, 29 Oct 2012 07:27:30 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5718460vcb.31 for ; Mon, 29 Oct 2012 07:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xwuYq3d2xiWPJ98N9xQWSCJrYx1GgjxM1exY6kh2lJI=; b=wexBuFEMW0bjonataMzeKsv3nh/VnAFU8tD3zgTnBsuNEtDwlFgSTuviuioeW5mSBB YvzGX2b7tGCNgMvIZnSKevTMfeuJJt3H07Nu+++i5aKNz0uSl3hX7rnemgnX6ZTql8MO uTvzHBi2VdzIfDrbVFY/iT0AnX7c2ljzSujTQY/kl2lJ3RCaxsikaj3q9/BvJW9+or7u F+gIpjNaF83wGQxKAtKURDEuKxIOUeQPeEDTFPORfMITX5XNaIenx9ichah9856+S4KJ JCrvop5C2GGnttSUriuS+LFA51PZphdn7Ab0nrZIS3A1313pjS/RgmN1WWjzi52y4zin w9eQ== MIME-Version: 1.0 Received: by 10.220.8.195 with SMTP id i3mr8870436vci.44.1351520850147; Mon, 29 Oct 2012 07:27:30 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 29 Oct 2012 07:27:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Oct 2012 15:27:29 +0100 Message-ID: From: Abdussalam Baryun To: jasteven@rockwellcollins.com Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Oct 2012 IEEE Communications Magazine article discussing DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:27:31 -0000 Hi On 10/25/12, jasteven@rockwellcollins.com wrote: > I finally finished catching up on over a month of manet emails and don't > remember seeing any mention of the Oct 2012 IEEE Communications Magazine > article on "Radio-to-router interface technology and its applicability on > the tactical edge" by Bow-Nan Cheng, James Wheeler, and Leonid Veytser of > MIT Lincoln Laboratory. It was not mentioned because it is new article, we are still in october 2012. I don't see that the article authors discussed DLEP work on the IETF MANET list. > > The article discusses the need for radio to router interface (R2RI) > protocols for smart cross-layer multihop routing. They argue issues but did not discuss with us. Could you explain what is smart cross-layer routing? do we have this kind of routing in MANET-IETF or is it out MANET-IETF? However, I agree that we need more work for R2RI mechanisms as we do with DLEP. > The article examines > and compares > - RFC 5578 [PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link > Metrics], > - R2CP (Radio-to-Router Protocol), and > - DLEP. > The article does not examine/tests the protocols, but compares features without performance including applicability issues. > I thought the article did a good job of discussing the issues of > developing such R2RI protocols and the advantages and disadvantages of RFC > 5578, R3CP, and DLEP. - You mean DLEP-02 not the final DLEP still discussions within MANET-WG - I don't agree with article's Figure 1, of the three componenets, I prefer the DLEP draft descriptions. However, Figure 4 is more clear. However, I agree that the article provide good introduction, maybe used as definition reference. Finally, there is still work going within R2RI area, including DLEP, but I think that DLEP seems special case of R2RI or maybe not a R2RI. AB From jpmacker@gmail.com Mon Oct 29 07:35:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC1C21F8714 for ; Mon, 29 Oct 2012 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pekjioiO2W8u for ; Mon, 29 Oct 2012 07:35:49 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9C1021F870A for ; Mon, 29 Oct 2012 07:35:49 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5729936vcb.31 for ; Mon, 29 Oct 2012 07:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z7vmVNKmrq7sxMErV/I+fZNnU3ex+ODLXzka+yrFPq8=; b=PVGhqcVii4Q8yCLDTJDRxeQU+CUZ5OkLIvaKLbtwDPuLlz2kHkoj/fUEaaE5xkUDuV u5ci/03YFe8q9MqGe5yQbnBGNr5h+Vkkh+4EtyKrlASvt3NE/9lFY5zjkwIemGHnYRpF glnUOVLlSb8k1hN5vuw512AZgk3vihK8cuRlHU5A7trRZdZiN1AR/BjP1DB/PLlARtnq hCNvifPaTYBDc/V6zi7ZTG6ywnEk/HAh1h7oGExRFXw7Wt2jeoqjSApCx2IeekwS8Xne x3BxC3A/ogzTULP5yBtM2YicQrrXfYzf6lPvVmXBoNDRB31N2kzwJHIJsx3gFF/1Vzrh op6w== MIME-Version: 1.0 Received: by 10.58.201.73 with SMTP id jy9mr53420116vec.29.1351521349117; Mon, 29 Oct 2012 07:35:49 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Mon, 29 Oct 2012 07:35:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Oct 2012 10:35:49 -0400 Message-ID: From: Joseph Macker To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b677afaeba50b04cd3395b0 Cc: manet@ietf.org, jasteven@rockwellcollins.com Subject: Re: [manet] Oct 2012 IEEE Communications Magazine article discussing DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:35:50 -0000 --047d7b677afaeba50b04cd3395b0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 29, 2012 at 10:27 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi > > On 10/25/12, jasteven@rockwellcollins.com > wrote: > > I finally finished catching up on over a month of manet emails and don't > > remember seeing any mention of the Oct 2012 IEEE Communications Magazine > > article on "Radio-to-router interface technology and its applicability on > > the tactical edge" by Bow-Nan Cheng, James Wheeler, and Leonid Veytser of > > MIT Lincoln Laboratory. > > It was not mentioned because it is new article, we are still in > october 2012. I don't see that the article authors discussed DLEP work > on the IETF MANET list. > FYI, the authors (Cheng) did provide an initial set of input to the manet WG in the form of a briefing and a personal Internet draft. If you see past minutes you will see a brief summary of what was discussed. > > > > > The article discusses the need for radio to router interface (R2RI) > > protocols for smart cross-layer multihop routing. > > They argue issues but did not discuss with us. Could you explain what > is smart cross-layer routing? do we have this kind of routing in > MANET-IETF or is it out MANET-IETF? > However, I agree that we need more work for R2RI mechanisms as we do with > DLEP. > > > The article examines > > and compares > > - RFC 5578 [PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link > > Metrics], > > - R2CP (Radio-to-Router Protocol), and > > - DLEP. > > > > The article does not examine/tests the protocols, but compares > features without performance including applicability issues. > > > I thought the article did a good job of discussing the issues of > > developing such R2RI protocols and the advantages and disadvantages of > RFC > > 5578, R3CP, and DLEP. > > - You mean DLEP-02 not the final DLEP still discussions within MANET-WG > - I don't agree with article's Figure 1, of the three componenets, I > prefer the DLEP draft descriptions. However, Figure 4 is more clear. > However, I agree that the article provide good introduction, maybe > used as definition reference. > > Finally, there is still work going within R2RI area, including DLEP, > but I think that DLEP seems special case of R2RI or maybe not a R2RI. > > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b677afaeba50b04cd3395b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 29, 2012 at 10:27 AM, Abdussalam Baryun <<= a href=3D"mailto:abdussalambaryun@gmail.com" target=3D"_blank">abdussalamba= ryun@gmail.com> wrote:
Hi

On 10/25/12, jasteven@rockw= ellcollins.com <jast= even@rockwellcollins.com> wrote:
> I finally finished catching up on over a month of manet emails and don= 't
> remember seeing any mention of the Oct 2012 IEEE Communications Magazi= ne
> article on "Radio-to-router interface technology and its applicab= ility on
> the tactical edge" by Bow-Nan Cheng, James Wheeler, and Leonid Ve= ytser of
> MIT Lincoln Laboratory.

It was not mentioned because it is new article, we are still in
october 2012. I don't see that the article authors discussed DLEP work<= br> on the IETF MANET list.

FYI, the authors (Cheng) d= id provide an initial set of input to the manet WG in the form of a briefin= g and a personal Internet draft. If you see past minutes you will see a bri= ef summary of what was discussed.

=A0

>
> The article discusses the need for radio to router interface (R2RI) > protocols for smart cross-layer multihop routing.

They argue issues but did not discuss with us. Could you explain what=
is smart cross-layer routing? do we have this kind of routing in
MANET-IETF or is it out MANET-IETF?
However, I agree that we need more work for R2RI mechanisms as we do with D= LEP.

> =A0The article examines
> and compares
> - RFC 5578 [PPP over Ethernet (PPPoE) Extensions for Credit Flow and L= ink
> Metrics],
> - R2CP (Radio-to-Router Protocol), and
> - DLEP.
>

The article does not examine/tests the protocols, but compares
features without =A0performance including applicability issues.

> I thought the article did a good job of discussing the issues of
> developing such R2RI protocols and the advantages and disadvantages of= RFC
> 5578, R3CP, and DLEP.

- You mean DLEP-02 not the final DLEP still discussions within MANET-= WG
- I don't agree with article's Figure 1, of the three componenets, = I
prefer the DLEP draft descriptions. However, Figure 4 is more clear.
However, I agree that the article provide good introduction, maybe
used as definition reference.

Finally, there is still work going within R2RI area, including DLEP,
but I think that DLEP seems special case of R2RI or maybe not a R2RI.

AB
_____________________= __________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b677afaeba50b04cd3395b0-- From charliep@computer.org Mon Oct 29 13:35:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1421F86EE for ; Mon, 29 Oct 2012 13:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tykXyeMKVab1 for ; Mon, 29 Oct 2012 13:35:02 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 056A021F86E5 for ; Mon, 29 Oct 2012 13:35:01 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TSw32-0000Lv-WF; Mon, 29 Oct 2012 16:35:01 -0400 Message-ID: <508EE874.1070809@computer.org> Date: Mon, 29 Oct 2012 13:35:00 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: <508B2AB9.10005@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86330f08d469fc9bfab5c1f26a2523e7d2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] Use of RFC 5444 in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:35:03 -0000 Hello Abdussalam, While studying whether AODVv2 was properly in compliance with RFC 5444, I found a few things that I feel should have been done differently. However: - there is no doubt that AODVv2 can be made conformant to RFC 5444, as you can see by reading through my longish note about the possible design alternatives for RREQ - Certain simple changes to RFC 5444 would allow for more compact message representation -- but, the savings are not so dramatic as to motivate immediate action on my part, and I don't really have time to carry on that argument right now. Maybe I'll write up a small proposal and send it to the list. However, the offline discussions I have had lead me to the conclusion that a lot of people are not that interested in saving header space, and that they strongly feel it is far too late to discuss the matter. This doesn't match my understanding of requirements from other groups, so maybe in the future we should reopen the discussion, I don't know. Regards, Charlie P. On 10/28/2012 4:00 AM, Abdussalam Baryun wrote: > Hi Charlie, > > If you are suggesting to modify the RFC5444 packet format, I agree to > make modification to RFC5444 to fit our reactive standards. > > AB > > On 10/27/12, Charles E. Perkins wrote: >> Hello folks, >> >> Several people have pointed out to me that DYMO and now AODVv2 have >> not really been conformant with the design of RFC 5444. I have studied >> this >> matter in some detail, and it turns out to be quite confusing. In order to >> avoid getting confused over and over again, I wrote up a long description >> of a design evolution, first correcting errors that had to be corrected, >> and >> aiming towards a more serviceable design for the "usual" cases that would >> be probably encountered in AODVv2 networks. >> >> I expect to include this as an appendix in the next revision of AODVv2, >> which I will make available next week. In the meantime, I have put the >> following text on my website, for anyone interested. >> http://www.psg.com/~charliep/AODVv2-rfc5444-ideas.txt >> I still need to proofread it, but it's mostly correct, and if it is >> acceptable >> then it will pretty much form a roadmap for the design of the RFC 5444 >> formats for other AODVv2 messages (RREP and RERR). >> >> I have also had several people express frustration that the document is >> not easy to read. I have always thought that myself, and I have come up >> with some changes in terminology that might go a long way towards >> helping with that. For instance, I define "router client" to be a host in >> an AODVv2 network that relies on the service of an AODVv2 router, >> but is not itself an AODVv2 router. It is intended that a "router client" >> doesn't have to know anything about AODVv2. This avoids having to >> use the previous terminology about "router responsibility" which did >> not seem to illuminate the concepts very well. >> >> I'll make a more complete proposal for changing terminology early >> next week. Please excuse the remaining errors in the recently released >> version of AODVv2. I wish I had started much much earlier to do these >> revisions. >> >> Lastly, it is my intention to submit these changes also as issues in the >> issue tracker. There are at least a half-dozen such issues that need to be >> included -- some small, some (like RFC 5444 compliance) not so small. >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> -- Regards, Charlie P. From Chris.Dearlove@baesystems.com Tue Oct 30 03:10:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2DE21F84A9 for ; Tue, 30 Oct 2012 03:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ibuuyzmXPIV for ; Tue, 30 Oct 2012 03:10:09 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B1F6421F84BE for ; Tue, 30 Oct 2012 03:10:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,679,1344207600"; d="scan'208";a="282146876" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 30 Oct 2012 10:10:02 +0000 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9UAA10g005521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 10:10:02 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Tue, 30 Oct 2012 10:10:01 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , Abdussalam Baryun Thread-Topic: [manet] Use of RFC 5444 in AODVv2 Thread-Index: AQHNs9oMjmgTJHgYx0SDD1VA4anr1ZfOjywAgAIy2wCAAOKx4A== Date: Tue, 30 Oct 2012 10:10:01 +0000 Message-ID: References: <508B2AB9.10005@computer.org> <508EE874.1070809@computer.org> In-Reply-To: <508EE874.1070809@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Use of RFC 5444 in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 10:10:10 -0000 A possibility (I'm not arguing for or against it, just putting it out there= ) is to specify the protocol in terms of message contents in an abstract ma= nner (though one described in terms of addresses and associated information= would be good) and then provide a mapping (a) of this to 5444, for use on = manet port, and which is flexible and extensible, and (b) a highly compress= ed representation for use over highly bandwidth constrained interfaces, pos= sibly not supporting all options, not easily extensible, possibly using e.g= . compressed addresses. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 29 October 2012 20:35 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] Use of RFC 5444 in AODVv2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Abdussalam, While studying whether AODVv2 was properly in compliance with RFC 5444, I found a few things that I feel should have been done differently. However: - there is no doubt that AODVv2 can be made conformant to RFC 5444, as you can see by reading through my longish note about the possible design alternatives for RREQ - Certain simple changes to RFC 5444 would allow for more compact message representation -- but, the savings are not so dramatic as to motivate immediate action on my part, and I don't really have time to carry on that argument right now. Maybe I'll write up a small proposal and send it to the list. However, the offline discussions I have had lead me to the conclusion that a lot of people are not that interested in saving header space, and that they strongly feel it is far too late to discuss the matter. This doesn't match my understanding of requirements from other groups, so maybe in the future we should reopen the discussion, I don't know. Regards, Charlie P. On 10/28/2012 4:00 AM, Abdussalam Baryun wrote: > Hi Charlie, > > If you are suggesting to modify the RFC5444 packet format, I agree to > make modification to RFC5444 to fit our reactive standards. > > AB > > On 10/27/12, Charles E. Perkins wrote: >> Hello folks, >> >> Several people have pointed out to me that DYMO and now AODVv2 have >> not really been conformant with the design of RFC 5444. I have studied >> this >> matter in some detail, and it turns out to be quite confusing. In order= to >> avoid getting confused over and over again, I wrote up a long descriptio= n >> of a design evolution, first correcting errors that had to be corrected, >> and >> aiming towards a more serviceable design for the "usual" cases that woul= d >> be probably encountered in AODVv2 networks. >> >> I expect to include this as an appendix in the next revision of AODVv2, >> which I will make available next week. In the meantime, I have put the >> following text on my website, for anyone interested. >> http://www.psg.com/~charliep/AODVv2-rfc5444-ideas.txt >> I still need to proofread it, but it's mostly correct, and if it is >> acceptable >> then it will pretty much form a roadmap for the design of the RFC 5444 >> formats for other AODVv2 messages (RREP and RERR). >> >> I have also had several people express frustration that the document is >> not easy to read. I have always thought that myself, and I have come up >> with some changes in terminology that might go a long way towards >> helping with that. For instance, I define "router client" to be a host = in >> an AODVv2 network that relies on the service of an AODVv2 router, >> but is not itself an AODVv2 router. It is intended that a "router clien= t" >> doesn't have to know anything about AODVv2. This avoids having to >> use the previous terminology about "router responsibility" which did >> not seem to illuminate the concepts very well. >> >> I'll make a more complete proposal for changing terminology early >> next week. Please excuse the remaining errors in the recently released >> version of AODVv2. I wish I had started much much earlier to do these >> revisions. >> >> Lastly, it is my intention to submit these changes also as issues in the >> issue tracker. There are at least a half-dozen such issues that need to= be >> included -- some small, some (like RFC 5444 compliance) not so small. >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> --=20 Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From abdussalambaryun@gmail.com Tue Oct 30 05:34:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9E21F8554 for ; Tue, 30 Oct 2012 05:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+jY8PSPHIK8 for ; Tue, 30 Oct 2012 05:34:05 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2460B21F854C for ; Tue, 30 Oct 2012 05:34:05 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so259949vcb.31 for ; Tue, 30 Oct 2012 05:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1u+xw77tgcKPq69YmmDRDi9rxp6QwXqgmVgUGnBO6Ec=; b=hPk1dq/SuawN+XqgPVozhX/m+2nsIGWxhsOay7i2242XQvyu+xNSiHr/jahNfz+7Tw QxGO4mUqUk8Od/ZWWci0zzm+41f7lcUqN/mcThnJjCGtckkay7zze+onjQAhBpTHRt8c njOS3ikSfICICeB2/G3tYWviyi/Ur2s0VDO5X3QeJ5gALflcYGfZojl1hxY2fPduTAvQ 1sQq5uXJEzr02RVWtB47oq0uGmpgSRj4QwGyWWUUsORi3OBkNNdgqj6MO2x6eCU67F91 V76/YV9oyFYK98BAlTyCJ6grIvI4ESpHb5nty+mvTIubDq0sItze9cloCg/ZMxNv9jum +VEQ== MIME-Version: 1.0 Received: by 10.220.8.195 with SMTP id i3mr13017310vci.44.1351600444555; Tue, 30 Oct 2012 05:34:04 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 30 Oct 2012 05:34:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Oct 2012 13:34:04 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:34:05 -0000 I would like to know the status of the below WG mib-draft (similar to olsrv2-mib), if possible to get someone give short input on the draft because it is in milestone for Nov. 2012: draft-ietf-manet-smf-mib-03 thanks AB On 10/25/12, Ulrich Herberg wrote: > Hello, > > I have uploaded an agenda draft to the meeting materials. > > This is a provisional draft agenda that has not yet been approved by the > chairs. The chairs would be within their rights to make multiple changes to > the agenda. I have only posted this as a starting point because I know both > chairs are away from Internet at the moment. As usual, please send your > comments to the list, and I am sure the chairs will pick them up and make > any changes necessary. > > Best regards > Ulrich > From charliep@computer.org Tue Oct 30 09:08:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7921F8661 for ; Tue, 30 Oct 2012 09:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vkd75KBGM8u for ; Tue, 30 Oct 2012 09:08:19 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 436AB21F865B for ; Tue, 30 Oct 2012 09:08:19 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTEMT-00026o-L8; Tue, 30 Oct 2012 12:08:17 -0400 Message-ID: <508FFB6E.9010408@computer.org> Date: Tue, 30 Oct 2012 09:08:14 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <508B2AB9.10005@computer.org> <508EE874.1070809@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86150f4f2a9bb01010efcef8941ad70b88350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] Use of RFC 5444 in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:08:19 -0000 Hello Chris, I think that this is what Ian had tried to do. I am in the process of basically completing his effort. I think that some attention to terminology is important for this effort, and I will make a proposal soon about that. Regards, Charlie P. On 10/30/2012 3:10 AM, Dearlove, Christopher (UK) wrote: > A possibility (I'm not arguing for or against it, just putting it out there) is to specify the protocol in terms of message contents in an abstract manner (though one described in terms of addresses and associated information would be good) and then provide a mapping (a) of this to 5444, for use on manet port, and which is flexible and extensible, and (b) a highly compressed representation for use over highly bandwidth constrained interfaces, possibly not supporting all options, not easily extensible, possibly using e.g. compressed addresses. > -- Regards, Charlie P. From charliep@computer.org Tue Oct 30 12:39:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C517B21F862E for ; Tue, 30 Oct 2012 12:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykGHGAonteAb for ; Tue, 30 Oct 2012 12:39:35 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0289321F85B8 for ; Tue, 30 Oct 2012 12:39:34 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTHew-00043h-4F for manet@ietf.org; Tue, 30 Oct 2012 15:39:34 -0400 Message-ID: <50902CF3.9070903@computer.org> Date: Tue, 30 Oct 2012 12:39:31 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864bf982ad224105d7fd3e63efcdfd99e7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: [manet] Flooding: how to make a normative reference? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:39:37 -0000 Hello folks, I think it is well recognized that brute force flooding often leads to poor performance in ad hoc networks with many nodes. Thus, we have RFC 6621 to describe various other approaches. Plus, we have MPR flooding as described in the OLSRv2 document. For reactive, it is quite important to enable "better" algorithms for flooding. AODVv2 could quite reasonable use a MPR-based flooding, or flooding based over any connected dominating set. It seems wrong to have AODVv2 cite OLSRv2 in any normative fashion, just to get access to the MPR flooding mechanism which can run independently of the routing protocol (and, perhaps, should do so). It also seems wrong to cite RFC 6621 in any normative fashion since that is an Experimental specification. Don't we need to have some Proposed Standard documents that specify more scalable approaches to flooding, that are independent of routing protocols? I guess it's too late to suggest that the MPR specification should be pulled out of OLSRv2 for this purpose... I looked back for some discussion about this on the list, but I didn't find it, but my search was hardly exhaustive. -- Regards, Charlie P. From jpmacker@gmail.com Tue Oct 30 13:25:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB3B21F864D for ; Tue, 30 Oct 2012 13:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASc4FhsxJie8 for ; Tue, 30 Oct 2012 13:25:52 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35221F8607 for ; Tue, 30 Oct 2012 13:25:45 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so850940vcb.31 for ; Tue, 30 Oct 2012 13:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iT1gE2GPcokr9JwQHfziZ25VEVGaOa2cYgMAJTdd+Ds=; b=LI/I3yyJOTkHOBrbpOzxvGs/3+ngSeL4UF0g77gtWt+zI62ymfqYxAUHq+m3JotMWk mUr5KQxAON8rRyrfOfXgTK6+CVwfbKVhGvajOZX55UFlnn3/eE7j/afQcuuo+z3MaWU3 v7djGQkmcsNbGFlwiUZvJOwEmOmriuUdULnOFz5f/s4gndSsftO8LEvu9RXYJbubgrPs p6QSm5W92WvY1tnur8UQo+kor/amaSHpe6AVxSaYyJ8aB2dBJcd4Bx7sYJ/+yCzDsGvs JropYgJgw7aw+E2LbvHsftpHHmGSXXjFnQMBIFvdxR4mrzuFn7/yWnBX25WJnez6xspS FIbA== MIME-Version: 1.0 Received: by 10.220.150.82 with SMTP id x18mr15243796vcv.73.1351628745367; Tue, 30 Oct 2012 13:25:45 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Tue, 30 Oct 2012 13:25:45 -0700 (PDT) In-Reply-To: <50902CF3.9070903@computer.org> References: <50902CF3.9070903@computer.org> Date: Tue, 30 Oct 2012 16:25:45 -0400 Message-ID: From: Joseph Macker To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=f46d043c7c1e3c60af04cd4c971f Cc: manet Subject: Re: [manet] Flooding: how to make a normative reference? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 20:25:53 -0000 --f46d043c7c1e3c60af04cd4c971f Content-Type: text/plain; charset=ISO-8859-1 We could take 6621 Standards Track. It is beginning to be adopted and conceptually used by others we are implementing both adaptive unicast and adaptive multicast schemes. I was going to suggest that as a short agenda item but with the bulk of the discussion to center around reactive protocol work status I was holding off on that. Still a good idea at some point. So that's one way forward. In the meantime, a suggestion might be that there are also publications outside the IETF that are citable which include distributed CDS algorithm pseudocode. I dont see what would be wrong with that? But perhaps someone will correct that the IETF must only cite IETF documents. I think the key thing is that its not a "work in progress". The following basically covers the algorithms in 6621. Macker, J., Downard, I., Dean, J., and R. Adamson, "Evaluation of Distributed Cover Set Algorithms in Mobile Ad hoc Network for Simplified Multicast Forwarding", ACM SIGMOBILE Mobile Computing and Communications Review, Volume 11, Issue 3, July 2007. This article had pseudocode for various CDS algorithms also cited in RFC 6621 so it may be an alternative normative reference for your purposes. I know there are other articles detailing other CDSes as well like MPR related variants. On Tue, Oct 30, 2012 at 3:39 PM, Charles E. Perkins wrote: > > Hello folks, > > I think it is well recognized that brute force flooding often leads to > poor performance in ad hoc networks with many nodes. Thus, we > have RFC 6621 to describe various other approaches. Plus, we have > MPR flooding as described in the OLSRv2 document. > > For reactive, it is quite important to enable "better" algorithms > for flooding. AODVv2 could quite reasonable use a MPR-based > flooding, or flooding based over any connected dominating set. > > It seems wrong to have AODVv2 cite OLSRv2 in any normative > fashion, just to get access to the MPR flooding mechanism which > can run independently of the routing protocol (and, perhaps, > should do so). It also seems wrong to cite RFC 6621 in any > normative fashion since that is an Experimental specification. > > Don't we need to have some Proposed Standard documents that > specify more scalable approaches to flooding, that are independent > of routing protocols? > > I guess it's too late to suggest that the MPR specification should > be pulled out of OLSRv2 for this purpose... > > I looked back for some discussion about this on the list, but I > didn't find it, but my search was hardly exhaustive. > > -- > Regards, > Charlie P. > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --f46d043c7c1e3c60af04cd4c971f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We could take 6621 Standards Track.=A0 It is beginning to be adopted an= d conceptually used by others we are implementing both adaptive unicast and= adaptive multicast schemes.=A0 I was going to suggest that as a short agen= da item but with the bulk of the discussion to center around reactive proto= col work status I was holding off on that. Still a good idea at some point.= So that's one way forward.

In the meantime, a suggestion might be that there are also publications= outside the IETF that are citable which include distributed CDS algorithm = pseudocode. I dont see what would be wrong with that? But perhaps someone w= ill correct that the IETF must only cite IETF documents. I think the key th= ing is that its not a "work in progress".

The following basically covers the algorithms in 6621.
Macker, =
J., Downard, I., Dean, J., and R. Adamson, "Evaluation of Distributed =
Cover Set Algorithms in Mobile
Ad hoc Network for Simplified Multicast Forwarding", ACM SIGMOBILE Mob=
ile Computing and Communications Review, Volume 11, Issue 3, July 2007.This article had pseudocode for various CDS algorithms also cited in RFC =
6621 so it may be an alternative normative reference for your purposes.=A0 =



I know there are other articles detailing other CDSes as well like MPR =
related variants.

On Tue, Oct 30, 2012 at=
 3:39 PM, Charles E. Perkins <charliep@computer.org> wro=
te:




Hello folks,



I think it is well recognized that brute force flooding often leads to

poor performance in ad hoc networks with many nodes. =A0Thus, we

have RFC 6621 to describe various other approaches. =A0Plus, we have

MPR flooding as described in the OLSRv2 document.



For reactive, it is quite important to enable "better" algorithms=


for flooding. =A0AODVv2 could quite reasonable use a MPR-based

flooding, or flooding based over any connected dominating set.



It seems wrong to have AODVv2 cite OLSRv2 in any normative

fashion, just to get access to the MPR flooding mechanism which

can run independently of the routing protocol (and, perhaps,

should do so). =A0It also seems wrong to cite RFC 6621 in any

normative fashion since that is an Experimental specification.



Don't we need to have some Proposed Standard documents that

specify more scalable approaches to flooding, that are independent

of routing protocols?



I guess it's too late to suggest that the MPR specification should

be pulled out of OLSRv2 for this purpose...



I looked back for some discussion about this on the list, but I

didn't find it, but my search was hardly exhaustive.



-- 

Regards,

Charlie P.



_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--f46d043c7c1e3c60af04cd4c971f--

From jpmacker@gmail.com  Tue Oct 30 16:13:49 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0622621F85EB for ; Tue, 30 Oct 2012 16:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.032
X-Spam-Level: 
X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.567,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xtlcGpnPsjL for ; Tue, 30 Oct 2012 16:13:48 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7E321F85E0 for ; Tue, 30 Oct 2012 16:13:48 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so994883vbb.31 for ; Tue, 30 Oct 2012 16:13:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dO+DwaeAwrhEn4TvpbrSprhZCwimyt4Bw11mvfQ4NRU=; b=IR6/MsvN6kelQpoMPO00g9cyGNcLjITZHmN8lsN2leN7okYqojCLK7whzLBTDXVG18 IQ1SYmGu7Oh4sfhJosnvwMwCPZ5scYD3cZCV8LyPOtcGOnPzV8R9BN1iBjVHH5++bPt/ JHF0yqkq/BXsEC90UhqH2x5zfQ+BTDCt6WVpuaB4hAzg2DiIm3dk6fC835UPG4ypSk49 a+1OAcyuijjqsBgSRuXnUNh/1RQbBX3MMwAM9oOYDN27OI3lwHjgZJbWrmwtoM6tiadt jn4W/S5IPdyc/rCHSqbQgGb6bL8C8pBgKZg9CtFcMxPoahqGoYRX2+npoCl8d8Oqq3+i PkHQ==
MIME-Version: 1.0
Received: by 10.59.6.39 with SMTP id cr7mr60911157ved.17.1351638827521; Tue, 30 Oct 2012 16:13:47 -0700 (PDT)
Received: by 10.58.161.206 with HTTP; Tue, 30 Oct 2012 16:13:47 -0700 (PDT)
Date: Tue, 30 Oct 2012 19:13:47 -0400
Message-ID: 
From: Joseph Macker 
To: manet@ietf.org
Content-Type: multipart/alternative; boundary=047d7bf0e95c2dd4f404cd4ef073
Subject: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Oct 2012 23:13:49 -0000

--047d7bf0e95c2dd4f404cd4ef073
Content-Type: text/plain; charset=ISO-8859-1

Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on
competing drafts for a MANET reactive protocol - DYMO (reviving the current
working group document that was parked due to inactivity), and LOADng. Many
months ago there was a somewhat authorship led movement towards a common
document effort and given positive feedback at the time we the chairs
thought this was the best approach given the authors potential to come
together and gain the best of both efforts.  Since that period, there has
been some fairly strident and rancorous "at times" debate between the
authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of
the co-authors of the two documents. Our guidance to the co-authors was to
find a way to merge the two documents into one, as it was perceived that
are not technically far apart and they both derive roughly from AODV
concepts and LOADng had fairly active authorship and implementation
efforts. We provided a co-editing proposal to the authors and gave them the
timeframe of the Atlanta to come up with an answer back to us regarding
this.  As of this writing, those discussions of a potential commonn
document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two
documents are divided, and it is unlikely that progress on a merged
document can be reached based upon recent author feedback. I have also
polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat
disengaged on the issue at the present time.  We see only 3 possible paths
forward:

1. Continue the work on the DYMO document, starting with whether there is
consensus on its continued approach and also the desire to rename it to
AODVv2.
2. Replace the existing DYMO document effort with the LOADng related
document effort, defusing ealier references to LLNs as recommended in the
last meeting minutes, and to focus more motivationally on general MANET
problem spaces (the authors seem to have agreed to this issue if its a WG
document).
3. Remove the working group charter for a reactive protocol, effectively
killing both documents, at least from a working group (WG) standpoint. This
would not be a reflection on the technology in either case, just an
admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been
some silent collecting initial feedback and waiting for author feedback at
this point.  Stan and I are both on travel prior to Atlanta so our
responses may be sparse and we will also likely be in a "receive mode" for
a few days.  So send your opinions.

-Joe

--047d7bf0e95c2dd4f404cd4ef073
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello MANET working group (form Stan and Joe),

As you are all probab=
ly aware, there has been WG activity lately on competing drafts for a MANET=
 reactive protocol - DYMO (reviving the current working group document that=
 was parked due to inactivity), and LOADng. Many months ago there was a som=
ewhat authorship led movement towards a common document effort and given po=
sitive feedback at the time we the chairs thought this was the best approac=
h given the authors potential to come together and gain the best of both ef=
forts.=A0 Since that period, there has been some fairly strident and rancor=
ous "at times" debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some =
of the co-authors of the two documents. Our guidance to the co-authors was =
to find a way to merge the two documents into one, as it was perceived that=
 are not technically far apart and they both derive roughly from AODV conce=
pts and LOADng had fairly active authorship and implementation efforts. We =
provided a co-editing proposal to the authors and gave them the timeframe o=
f the Atlanta to come up with an answer back to us regarding this.=A0 As of=
 this writing, those discussions of a potential commonn document and author=
ship merger have failed.


Therefore, we find ourselves at a crossroads. The authors of the two do=
cuments are divided, and it is unlikely that progress on a merged document =
can be reached based upon recent author feedback. I have also polled the ea=
rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the=
 issue at the present time.=A0 We see only 3 possible paths forward:


1. Continue the work on the DYMO document, starting with whether there =
is consensus on its continued approach and also the desire to rename it to =
AODVv2.
2. Replace the existing DYMO document effort with the LOADng rel=
ated document effort, defusing ealier references to LLNs as recommended in =
the last meeting minutes, and to focus more motivationally on general MANET=
 problem spaces (the authors seem to have agreed to this issue if its a WG =
document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.


The co-chairs request and need your opinions on the options.=A0 We have=
 been some silent collecting initial feedback and waiting for author feedba=
ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our =
responses may be sparse and we will also likely be in a "receive mode&=
quot; for a few days.=A0 So send your opinions.


-Joe


--047d7bf0e95c2dd4f404cd4ef073--

From ulrich@herberg.name  Tue Oct 30 16:39:18 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3AE21F8516 for ; Tue, 30 Oct 2012 16:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.269
X-Spam-Level: 
X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=1.707,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+VgnZqvMFDL for ; Tue, 30 Oct 2012 16:39:16 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A28C21F84FB for ; Tue, 30 Oct 2012 16:39:16 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so1013418vbb.31 for ; Tue, 30 Oct 2012 16:39:16 -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=17ZjzMVOlrePX8VIQwV0EG2RAJaZLzbIRhE6S1uu8Ew=; b=zBBZGJdRlGqWiF8dnfBtbhoyzFwB7YJof1Ls6+X3G/GZzUb1AD1gL7gjtUN0BC/1/o PdVzOGTBRZBQ4vnQDY7IfcEAXwu6WVn6xiqf6QDhPJV9btaNwSL6EIteDQ9qchIvaWmO Rjnm2tZAhifmciO+zhWnVlszcGZSd2AG6R+/4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=17ZjzMVOlrePX8VIQwV0EG2RAJaZLzbIRhE6S1uu8Ew=; b=XJgmKapFgkkiDRmZSY9lPTDjV0o/HjqIzbEd6vNcmoWY5epm9Rmmt7+TzERDMPIxVO 374CifbR+L1Ip1Ri552mGo2ZwD+qqy4JzfRLBHgtp9QeDjd7t1JmCUjoQ652fvzBCfRq 0mXA3kKD7p7vLTdsHBm4iwHGSLCPbi4cZOGZ0c1JUC8PAa4l3Xr54vfgFrlCXdZuXkwu Qf0PDKd5A6DhM8Pcc/xKWgzzfz5pX8Wpyf2dRdeYxn4ni9XsA4lJEb4f/dzrqeteo933 WyLAd7ed3otZ2bbewa1Bn1PsZNmznIuIrVyGciNQ26rkSv79+Za+ms3WD3hdS8LTnsvZ afiw==
MIME-Version: 1.0
Received: by 10.52.89.146 with SMTP id bo18mr44274266vdb.33.1351640356052; Tue, 30 Oct 2012 16:39:16 -0700 (PDT)
Received: by 10.58.94.103 with HTTP; Tue, 30 Oct 2012 16:39:16 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 30 Oct 2012 16:39:16 -0700
Message-ID: 
From: Ulrich Herberg 
To: Joseph Macker 
Content-Type: multipart/alternative; boundary=bcaec50162b549608404cd4f4b83
X-Gm-Message-State: ALoCoQmKL3WPN+1gBVPhkvbBvzlS/49P2aanI+plV7NQlqz1Qos9F0Rn/J8DuvHAFioREDCGbnpd
Cc: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Oct 2012 23:39:18 -0000

--bcaec50162b549608404cd4f4b83
Content-Type: text/plain; charset=ISO-8859-1

Hello Joe,

thank you for this summary of what happened. I will not comment on the
process or the discussions that we had the last few months, but rather on
the drafts. I speak for myself here, not for any other author of the LOADng
draft.

- There has been an enormous amount of effort in the LOADng draft
development, which is reflected by multiple large corporations working on
the specification, having deployments and planning products of LOADng by
2013.
- There is an active author team of 10 authors, willing to close remaining
issues as quickly as possible. Before the discussions that Joe mentioned
started, progress was very efficient, and we plan to go back to that speed
as soon as we know how to proceed.
- There are at least four interoperable implementations of the most recent
revision, documented in an interop draft. I am not aware of any recent DYMO
implementations, deployments or products.
- There is a MIB document that we actively work on.
- I believe the draft is very mature, easy to read and to implement. I have
implemented it myself in one day based on the specification.
- It is 100% RFC5444 compliant. I know RFC5444 very well, and am sure that
we did not break anything.
- The latest revision of LOADng makes clear that it is a MANET protocol, so
there will be no overlap with other working groups.

Fujitsu, which I represent in this draft, has a strong interest in having
this standard be completed soon. While we have our own proactive routing
solution, we believe that for certain customers, a reactive protocol is
needed.
I believe that if the WG adopts the draft, we are far closer to having a
standard, and more importantly, a standard that is actually used, deployed
and (soon) sold in products. I therefore opt for 2).

Best regards
Ulrich



On Tue, Oct 30, 2012 at 4:13 PM, Joseph Macker  wrote:

> Hello MANET working group (form Stan and Joe),
>
> As you are all probably aware, there has been WG activity lately on
> competing drafts for a MANET reactive protocol - DYMO (reviving the current
> working group document that was parked due to inactivity), and LOADng. Many
> months ago there was a somewhat authorship led movement towards a common
> document effort and given positive feedback at the time we the chairs
> thought this was the best approach given the authors potential to come
> together and gain the best of both efforts.  Since that period, there has
> been some fairly strident and rancorous "at times" debate between the
> authors of the two documents.
>
> During IETF 84 in Vancouver, the co-chairs held a discussion with some of
> the co-authors of the two documents. Our guidance to the co-authors was to
> find a way to merge the two documents into one, as it was perceived that
> are not technically far apart and they both derive roughly from AODV
> concepts and LOADng had fairly active authorship and implementation
> efforts. We provided a co-editing proposal to the authors and gave them the
> timeframe of the Atlanta to come up with an answer back to us regarding
> this.  As of this writing, those discussions of a potential commonn
> document and authorship merger have failed.
>
> Therefore, we find ourselves at a crossroads. The authors of the two
> documents are divided, and it is unlikely that progress on a merged
> document can be reached based upon recent author feedback. I have also
> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat
> disengaged on the issue at the present time.  We see only 3 possible paths
> forward:
>
> 1. Continue the work on the DYMO document, starting with whether there is
> consensus on its continued approach and also the desire to rename it to
> AODVv2.
> 2. Replace the existing DYMO document effort with the LOADng related
> document effort, defusing ealier references to LLNs as recommended in the
> last meeting minutes, and to focus more motivationally on general MANET
> problem spaces (the authors seem to have agreed to this issue if its a WG
> document).
> 3. Remove the working group charter for a reactive protocol, effectively
> killing both documents, at least from a working group (WG) standpoint. This
> would not be a reflection on the technology in either case, just an
> admission that we are not working together and reaching consensus.
>
> The co-chairs request and need your opinions on the options.  We have been
> some silent collecting initial feedback and waiting for author feedback at
> this point.  Stan and I are both on travel prior to Atlanta so our
> responses may be sparse and we will also likely be in a "receive mode" for
> a few days.  So send your opinions.
>
> -Joe
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--bcaec50162b549608404cd4f4b83
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Joe,

thank you for this summary of what happened. =
I will not comment on the process or the discussions that we had the last f=
ew months, but rather on the drafts. I speak for myself here, not for any o=
ther author of the LOADng draft.




- There has been an enormous amount of effort in the LO=
ADng draft development, which is reflected by multiple large corporations w=
orking on the specification, having deployments and planning products of LO=
ADng by 2013.



- There is an active author team of 10 authors, willing to close remai=
ning issues as quickly as possible. Before the discussions that Joe mention=
ed started, progress was very efficient, and we plan to go back to that spe=
ed as soon as we know how to proceed.



- There are at least four interoperable implementations of the most re=
cent revision, documented in an interop draft. I am not aware of any recent=
 DYMO implementations, deployments or products.
- There is a MIB =
document that we actively work on.=A0


- I believe the draft is very mature, easy to read and to implement. I=
 have implemented it myself in one day based on the specification.


- It is 100% RFC5444 compliant. I know RFC5444 very well, and am sure =
that we did not break anything.=A0
- The latest revision of LOADn=
g makes clear that it is a MANET protocol, so there will be no overlap with=
 other working groups.



Fujitsu, which I represent in this draft, has a strong =
interest in having this standard be completed soon. While we have our own p=
roactive routing solution, we believe that for certain customers, a reactiv=
e protocol is needed.=A0


I believe that if the WG adopts the draft, we are far closer to having=
 a standard, and more importantly, a standard that is actually used, deploy=
ed and (soon) sold in products. I therefore opt for 2).



Best regards
Ulrich




On Tue, Oct 30, 2012 at 4:13 PM, Joseph Macker <jpmacker@gmail.com>=
; wrote:


Hello MANET working group (form Stan and Joe),

As you are all probab=
ly aware, there has been WG activity lately on competing drafts for a MANET=
 reactive protocol - DYMO (reviving the current working group document that=
 was parked due to inactivity), and LOADng. Many months ago there was a som=
ewhat authorship led movement towards a common document effort and given po=
sitive feedback at the time we the chairs thought this was the best approac=
h given the authors potential to come together and gain the best of both ef=
forts.=A0 Since that period, there has been some fairly strident and rancor=
ous "at times" debate between the authors of the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some =
of the co-authors of the two documents. Our guidance to the co-authors was =
to find a way to merge the two documents into one, as it was perceived that=
 are not technically far apart and they both derive roughly from AODV conce=
pts and LOADng had fairly active authorship and implementation efforts. We =
provided a co-editing proposal to the authors and gave them the timeframe o=
f the Atlanta to come up with an answer back to us regarding this.=A0 As of=
 this writing, those discussions of a potential commonn document and author=
ship merger have failed.




Therefore, we find ourselves at a crossroads. The authors of the two do=
cuments are divided, and it is unlikely that progress on a merged document =
can be reached based upon recent author feedback. I have also polled the ea=
rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the=
 issue at the present time.=A0 We see only 3 possible paths forward:




1. Continue the work on the DYMO document, starting with whether there =
is consensus on its continued approach and also the desire to rename it to =
AODVv2.
2. Replace the existing DYMO document effort with the LOADng rel=
ated document effort, defusing ealier references to LLNs as recommended in =
the last meeting minutes, and to focus more motivationally on general MANET=
 problem spaces (the authors seem to have agreed to this issue if its a WG =
document).



3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.




The co-chairs request and need your opinions on the options.=A0 We have=
 been some silent collecting initial feedback and waiting for author feedba=
ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our =
responses may be sparse and we will also likely be in a "receive mode&=
quot; for a few days.=A0 So send your opinions.




-Joe


_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--bcaec50162b549608404cd4f4b83--

From salo@saloits.com  Tue Oct 30 16:51:36 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532D021F8589 for ; Tue, 30 Oct 2012 16:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ4ka4CG52oM for ; Tue, 30 Oct 2012 16:51:35 -0700 (PDT)
Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 68A3121F858F for ; Tue, 30 Oct 2012 16:51:35 -0700 (PDT)
Received: from [192.168.1.233] (mail.gdmfinancial.com [64.122.144.190] (may be forged)) by server.saloits.com (8.14.4/8.14.3) with ESMTP id q9UNpTiY018705; Tue, 30 Oct 2012 18:51:30 -0500
Message-ID: <50906802.9070904@saloits.com>
Date: Tue, 30 Oct 2012 18:51:30 -0500
From: "Timothy J. Salo" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0
MIME-Version: 1.0
To: Joseph Macker 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Oct 2012 23:51:36 -0000

> As you are all probably aware, there has been WG activity lately on
> competing drafts for a MANET reactive protocol - DYMO (reviving the
> current working group document that was parked due to inactivity), and
> LOADng.

I suggest not excluding what might be considered a fourth possible
course of action, namely: wait.

Based on what I have read and seen during meetings, I am concerned that
a decision to select one document over the other may be driven by
personalities, rather than technical content, the ability of the
authors to work with the members of the working group, or a
commitment by the authors to complete the process.

Sometimes, simply deferring a decision permits things to sort
themselves out naturally, and avoids unnecessarily expending a lot of
time, energy, and perhaps even ill will by forcing a decision
prematurely.

I can't say that deferring a decision will necessarily make the best
future path obvious.  But, it seems that the cost of not deciding at
this time is probably small (perhaps beyond the cost of additional
heated, even acrimonious, emails, posturing and positioning).

Having said that, let me argue the contrary.  Sometimes, the best
course of action is decision-by-fiat (e.g., the working group chairs
direct a solution).  It is possible that either document and document
authors would serve the working group equally well.  In this case, a
quick, mandated solution may permit the working group to focus its
energy on progressing the selected document.  This approach probably has
a couple of requirements.  First, the authors of the selected document
_must_ ensure that their document progresses to an RFC in a expeditious
manner.  Second, the selection process (e.g., working group chair
directive) must appear fair to all involved.  If all things really are
equal, there is a lot to be said for a coin toss.

-tjs


From ulrich@herberg.name  Tue Oct 30 17:08:44 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3364721F849A for ; Tue, 30 Oct 2012 17:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.777
X-Spam-Level: 
X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=0.533,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5sD9XEzTkvt for ; Tue, 30 Oct 2012 17:08:43 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFA521F8467 for ; Tue, 30 Oct 2012 17:08:43 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so1034395vbb.31 for ; Tue, 30 Oct 2012 17:08:42 -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=HwqcbLX6AiRtRwjcZ8q+b8TCN4DC//foqHFT8S7Q9RU=; b=swQKAV1eKAYgUy4NUNqZtZZsalj3hBUgVyLPm9OLhUgGCVfHdPJsA/LXwAg/BW7P+o /iS5ub5xVTTelt7Q1ZSvRuWihp4o2I1q0E57o7Cfft+pRMSDp+GdmUcSV1ARNfErkEfg jKSOA7D4AFPyQtn6q9fsc/kKHiTfuTEmNJZpY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=HwqcbLX6AiRtRwjcZ8q+b8TCN4DC//foqHFT8S7Q9RU=; b=ZzO2l5TJ03nYaX2iQLFrQNHfVBuo8y+l1Mcd08I4ScGliNMFJz+Dpcrr9L9mdVufrm ry2c/R5yomCkvMZVe+GLcj5/6pugClkdmOj6E2ObNFrAbMtK4Ftyyb6Zv+lQnzIrvDZp n/hv3TTC4Hb6UssO/+xgof17GYje6iNMfCf7LABr5DGzvYpdhI+yqcOMAL26uoLiNpfk yUkNade0uCaTaNWhS/489ck53IH01UBFo/kRI1TGRjpqVfUG/uCRg8h2toFv/IadQS4q Lc2kpwp2z2Yn+aGzWOYd1xwtJO9KXGa9iPq/SKkAPWho5dIeCcxdLDEr+747JEsMq/Wn mW9g==
MIME-Version: 1.0
Received: by 10.58.145.161 with SMTP id sv1mr55528883veb.52.1351642122558; Tue, 30 Oct 2012 17:08:42 -0700 (PDT)
Received: by 10.58.94.103 with HTTP; Tue, 30 Oct 2012 17:08:42 -0700 (PDT)
In-Reply-To: <50906802.9070904@saloits.com>
References:  <50906802.9070904@saloits.com>
Date: Tue, 30 Oct 2012 17:08:42 -0700
Message-ID: 
From: Ulrich Herberg 
To: "Timothy J. Salo" 
Content-Type: multipart/alternative; boundary=047d7b67613c941d2004cd4fb470
X-Gm-Message-State: ALoCoQkIj49TXgE9EuEA1r2q5vPhd83m1IelJ+9qgBbzKO7A0GU7JV3SGjoskCK8dlCKsDiM+pQK
Cc: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 00:08:44 -0000

--047d7b67613c941d2004cd4fb470
Content-Type: text/plain; charset=ISO-8859-1

Timothy,

our company has deadlines for coming up with products on the market and
customers waiting. I believe that the same is true for other companies. We
had discussions for more than half a year now that did not lead anywhere.

Regards
Ulrich

On Tue, Oct 30, 2012 at 4:51 PM, Timothy J. Salo  wrote:

> As you are all probably aware, there has been WG activity lately on
>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>> current working group document that was parked due to inactivity), and
>> LOADng.
>>
>
> I suggest not excluding what might be considered a fourth possible
> course of action, namely: wait.
>
> Based on what I have read and seen during meetings, I am concerned that
> a decision to select one document over the other may be driven by
> personalities, rather than technical content, the ability of the
> authors to work with the members of the working group, or a
> commitment by the authors to complete the process.
>
> Sometimes, simply deferring a decision permits things to sort
> themselves out naturally, and avoids unnecessarily expending a lot of
> time, energy, and perhaps even ill will by forcing a decision
> prematurely.
>
> I can't say that deferring a decision will necessarily make the best
> future path obvious.  But, it seems that the cost of not deciding at
> this time is probably small (perhaps beyond the cost of additional
> heated, even acrimonious, emails, posturing and positioning).
>
> Having said that, let me argue the contrary.  Sometimes, the best
> course of action is decision-by-fiat (e.g., the working group chairs
> direct a solution).  It is possible that either document and document
> authors would serve the working group equally well.  In this case, a
> quick, mandated solution may permit the working group to focus its
> energy on progressing the selected document.  This approach probably has
> a couple of requirements.  First, the authors of the selected document
> _must_ ensure that their document progresses to an RFC in a expeditious
> manner.  Second, the selection process (e.g., working group chair
> directive) must appear fair to all involved.  If all things really are
> equal, there is a lot to be said for a coin toss.
>
> -tjs
>
>
> ______________________________**_________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/**listinfo/manet
>

--047d7b67613c941d2004cd4fb470
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Timothy,

our company has deadlines for coming up with pr=
oducts on the market and customers waiting. I believe that the same is true=
 for other companies. We had discussions for more than half a year now that=
 did not lead anywhere.



Regards
Ulrich

On Tue, Oct 30, 2012 at 4:51 PM, Timothy J. Salo <=
salo@saloits.com&=
gt; wrote:



As you are all probably aware, there has been WG activity lately on

competing drafts for a MANET reactive protocol - DYMO (reviving the

current working group document that was parked due to inactivity), and

LOADng.





I suggest not excluding what might be considered a fourth possible

course of action, namely: wait.



Based on what I have read and seen during meetings, I am concerned that

a decision to select one document over the other may be driven by

personalities, rather than technical content, the ability of the

authors to work with the members of the working group, or a

commitment by the authors to complete the process.



Sometimes, simply deferring a decision permits things to sort

themselves out naturally, and avoids unnecessarily expending a lot of

time, energy, and perhaps even ill will by forcing a decision

prematurely.



I can't say that deferring a decision will necessarily make the best
future path obvious. =A0But, it seems that the cost of not deciding at

this time is probably small (perhaps beyond the cost of additional

heated, even acrimonious, emails, posturing and positioning).



Having said that, let me argue the contrary. =A0Sometimes, the best

course of action is decision-by-fiat (e.g., the working group chairs

direct a solution). =A0It is possible that either document and document

authors would serve the working group equally well. =A0In this case, a

quick, mandated solution may permit the working group to focus its

energy on progressing the selected document. =A0This approach probably has<=
br>
a couple of requirements. =A0First, the authors of the selected document
_must_ ensure that their document progresses to an RFC in a expeditious

manner. =A0Second, the selection process (e.g., working group chair

directive) must appear fair to all involved. =A0If all things really are
equal, there is a lot to be said for a coin toss.



-tjs




_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--047d7b67613c941d2004cd4fb470--

From charliep@computer.org  Tue Oct 30 17:08:47 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3E521F84A8 for ; Tue, 30 Oct 2012 17:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzIsRuRKFF7E for ; Tue, 30 Oct 2012 17:08:47 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2792221F84A0 for ; Tue, 30 Oct 2012 17:08:47 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTLrS-0006wE-5Z; Tue, 30 Oct 2012 20:08:46 -0400
Message-ID: <50906C0A.5040702@computer.org>
Date: Tue, 30 Oct 2012 17:08:42 -0700
From: "Charles E. Perkins" 
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: manet@ietf.org
References:  <50906802.9070904@saloits.com>
In-Reply-To: <50906802.9070904@saloits.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d6bbd771a7e48f38c147039d9047ee21350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Cc: "Timothy J. Salo" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 00:08:48 -0000

Hello folks,

I've been working away to get the DYMO now AODVv2 specification to
fit the needs of LOADng and also to make various major improvements
to readability, RFC 5444 compliance, etc.  I'm well along the way, even
though I had delayed starting the process until very recently, while
attempting to find the right process to join forces with the LOADng
authors.  In fact, the LOADng authors had asked me not to submit
any revised document during the meantime, and I eventually decided
to submit a revision only after I realized that the expected document
merge would just not happen.  Given the short amount of time (only
a few weeks), I think the progress has been very good.

I'd certainly like to continue that.  Since the agreement all along had
been make the WG reactive protocol compatible with LOADng, I can
suggest that the current specification be completed with design
choices that enable LOADng as a "subset".

Regards,
Charlie P.





On 10/30/2012 4:51 PM, Timothy J. Salo wrote:
>> As you are all probably aware, there has been WG activity lately on
>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>> current working group document that was parked due to inactivity), and
>> LOADng.
>
> I suggest not excluding what might be considered a fourth possible
> course of action, namely: wait.
>
> Based on what I have read and seen during meetings, I am concerned that
> a decision to select one document over the other may be driven by
> personalities, rather than technical content, the ability of the
> authors to work with the members of the working group, or a
> commitment by the authors to complete the process.
>
> Sometimes, simply deferring a decision permits things to sort
> themselves out naturally, and avoids unnecessarily expending a lot of
> time, energy, and perhaps even ill will by forcing a decision
> prematurely.
>
> I can't say that deferring a decision will necessarily make the best
> future path obvious.  But, it seems that the cost of not deciding at
> this time is probably small (perhaps beyond the cost of additional
> heated, even acrimonious, emails, posturing and positioning).
>
> Having said that, let me argue the contrary.  Sometimes, the best
> course of action is decision-by-fiat (e.g., the working group chairs
> direct a solution).  It is possible that either document and document
> authors would serve the working group equally well.  In this case, a
> quick, mandated solution may permit the working group to focus its
> energy on progressing the selected document.  This approach probably has
> a couple of requirements.  First, the authors of the selected document
> _must_ ensure that their document progresses to an RFC in a expeditious
> manner.  Second, the selection process (e.g., working group chair
> directive) must appear fair to all involved.  If all things really are
> equal, there is a lot to be said for a coin toss.
>
> -tjs
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


-- 
Regards,
Charlie P.


From axel-ietf@axelcdv.com  Tue Oct 30 17:09:43 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBF21F8646 for ; Tue, 30 Oct 2012 17:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.965
X-Spam-Level: 
X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Co0+1S-Iboe for ; Tue, 30 Oct 2012 17:09:42 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D59A221F8633 for ; Tue, 30 Oct 2012 17:09:42 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8CD44559067 for ; Tue, 30 Oct 2012 17:09:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0FAEF1BC894E; Tue, 30 Oct 2012 17:09:29 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [10.1.1.206] (Cs-136-214.CS.UCLA.EDU [131.179.136.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CC3401BC882F; Tue, 30 Oct 2012 17:09:28 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
In-Reply-To: <50906802.9070904@saloits.com>
Date: Tue, 30 Oct 2012 17:09:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <50906802.9070904@saloits.com>
To: "Timothy J. Salo" 
X-Mailer: Apple Mail (2.1499)
Cc: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 00:09:43 -0000

Hi all,

First, thank you Joe and Stan for your summary of the situation. I think =
it's good to discuss that here.

I am in full agreement with what Ulrich stated. In particular, I would =
like to stress the fact that LOADng is already backed by multiple =
industrials, making it even more likely that it will go to RFC as =
efficiently as possible, and the editing process behind the draft has =
proven to be effective.

Le 30 oct. 2012 =E0 16:51, "Timothy J. Salo"  a =E9crit =
:

>> As you are all probably aware, there has been WG activity lately on
>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>> current working group document that was parked due to inactivity), =
and
>> LOADng.
>=20
> I suggest not excluding what might be considered a fourth possible
> course of action, namely: wait.
>=20
> Based on what I have read and seen during meetings, I am concerned =
that
> a decision to select one document over the other may be driven by
> personalities, rather than technical content, the ability of the
> authors to work with the members of the working group, or a
> commitment by the authors to complete the process.
>=20
> Sometimes, simply deferring a decision permits things to sort
> themselves out naturally, and avoids unnecessarily expending a lot of
> time, energy, and perhaps even ill will by forcing a decision
> prematurely.
>=20
> I can't say that deferring a decision will necessarily make the best
> future path obvious.  But, it seems that the cost of not deciding at
> this time is probably small (perhaps beyond the cost of additional
> heated, even acrimonious, emails, posturing and positioning).

Allow me to disagree here. I think this situation has lingered for too =
long (4+ months), which show that things will probably not sort =
themselves out naturally. Not choosing now would, on the opposite, be a =
huge waste of time for the authors and the WG in general: having two =
competing documents stay much longer would divide the efforts, delaying =
the publication of an RFC for even more time. Hence it is a good thing =
that the chairs are trying to make a decision here.

>=20
> Having said that, let me argue the contrary.  Sometimes, the best
> course of action is decision-by-fiat (e.g., the working group chairs
> direct a solution).  It is possible that either document and document
> authors would serve the working group equally well.  In this case, a
> quick, mandated solution may permit the working group to focus its
> energy on progressing the selected document.  This approach probably =
has
> a couple of requirements.  First, the authors of the selected document
> _must_ ensure that their document progresses to an RFC in a =
expeditious
> manner.  Second, the selection process (e.g., working group chair
> directive) must appear fair to all involved.  If all things really are
> equal, there is a lot to be said for a coin toss.
>=20
> -tjs

I believe that the author group behind LOADng has shown in the past that =
they are willing to spend the time and engergy necessary to ensure the =
document's progress towards RFC status goes as fast as possible. The =
multiple implementations, interoperability report and MIB document make =
a strong case for the draft. After all, from what I've gathered the IETF =
only believes in "rough consensus and running code", and I think we have =
just that.

Best,

Axel

>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From boberry@cisco.com  Tue Oct 30 17:11:30 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1334B21F865E for ; Tue, 30 Oct 2012 17:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TdfcVL73vSQ for ; Tue, 30 Oct 2012 17:11:29 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 38E6D21F8633 for ; Tue, 30 Oct 2012 17:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2436; q=dns/txt; s=iport; t=1351642289; x=1352851889; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=b4WB9/Y7/xVavrpnI9jOODV023V7jDNgjPyxSiLrj2E=; b=CyTFqAO8bf9WX96rD7SWDtWGJ0mP4v4F55sICb8/WhGZ8neGP9RFur0E ftrqKTXCHcHrb4JoFa9WAOWJJbWcPmY8C3ADB3HGt81+iBw+KZ8j/kmtJ 8TXd3CI98y/cuExH9O68+mNbDCUlI2tP1fRMh74t8Ge74IdP+m9IYbqzf o=;
X-IronPort-AV: E=Sophos;i="4.80,683,1344211200"; d="scan'208";a="137107528"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 31 Oct 2012 00:11:29 +0000
Received: from [192.168.1.201] (ggsg-1vpn1-230-62.cisco.com [10.81.230.62]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9V0BSEe025307;  Wed, 31 Oct 2012 00:11:28 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Bo Berry 
In-Reply-To: <50906802.9070904@saloits.com>
Date: Tue, 30 Oct 2012 20:11:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <50906802.9070904@saloits.com>
To: Joseph Macker , "Stan Ratliff (sratliff)" , " List" , "Timothy J. Salo" 
X-Mailer: Apple Mail (2.1085)
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 00:11:30 -0000

Joe, Stan
Adding to Tim's option.

If the MANET WG removes reactive from the charter, is there similar =
technology in another WG?  Perhaps ROLL?  If so this may be another =
option as there is a lot of synergy-commonality.

-Bo


On Oct 30, 2012, at 7:51 PM, Timothy J. Salo wrote:

>> As you are all probably aware, there has been WG activity lately on
>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>> current working group document that was parked due to inactivity), =
and
>> LOADng.
>=20
> I suggest not excluding what might be considered a fourth possible
> course of action, namely: wait.
>=20
> Based on what I have read and seen during meetings, I am concerned =
that
> a decision to select one document over the other may be driven by
> personalities, rather than technical content, the ability of the
> authors to work with the members of the working group, or a
> commitment by the authors to complete the process.
>=20
> Sometimes, simply deferring a decision permits things to sort
> themselves out naturally, and avoids unnecessarily expending a lot of
> time, energy, and perhaps even ill will by forcing a decision
> prematurely.
>=20
> I can't say that deferring a decision will necessarily make the best
> future path obvious.  But, it seems that the cost of not deciding at
> this time is probably small (perhaps beyond the cost of additional
> heated, even acrimonious, emails, posturing and positioning).
>=20
> Having said that, let me argue the contrary.  Sometimes, the best
> course of action is decision-by-fiat (e.g., the working group chairs
> direct a solution).  It is possible that either document and document
> authors would serve the working group equally well.  In this case, a
> quick, mandated solution may permit the working group to focus its
> energy on progressing the selected document.  This approach probably =
has
> a couple of requirements.  First, the authors of the selected document
> _must_ ensure that their document progresses to an RFC in a =
expeditious
> manner.  Second, the selection process (e.g., working group chair
> directive) must appear fair to all involved.  If all things really are
> equal, there is a lot to be said for a coin toss.
>=20
> -tjs
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From jvasseur@cisco.com  Wed Oct 31 01:29:06 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45AC21F86DE for ; Wed, 31 Oct 2012 01:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4VIGiNYwFBP for ; Wed, 31 Oct 2012 01:29:05 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6815221F8464 for ; Wed, 31 Oct 2012 01:29:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10096; q=dns/txt; s=iport; t=1351672145; x=1352881745; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+1Pmej9bdYxk1ijP7/wz+k6O+GlJRj/W9DC5g3Dbonc=; b=fXG60175yNKqRdRQWUqx5V5Hhuslob/ny8h/YhI3lEezZ09CaZF4KDCD I87oxPyYvNxfAHvtt5/4WQJLWZQcnzsZGZoyypkvGWDl088DwmTJk3cop r5RskRp9HtTxurdaA+dJ+8BQVLiYgNlPlItzluy+6FuoHy421o1cLTpVO k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EABbhkFCtJV2b/2dsb2JhbABEw22BCIIfAQEEAQEBDwFZAggDEAIBCA4UHQcnCxQRAgQOBQgTB4dkC5tBoAUEi3gShUhhA4glnCiBa4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,685,1344211200";  d="scan'208,217";a="137234601"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2012 08:29:00 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9V8T0Va025737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 08:29:00 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 03:28:59 -0500
From: "JP Vasseur (jvasseur)" 
To: Joseph Macker 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0HGLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 08:28:59 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--32.575900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220419BBxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 08:29:06 -0000

--_000_03B78081B371D44390ED6E7BADBB4A77220419BBxmbrcdx02ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear chairs,

Remembering that I am not a co-authors of either of these drafts.

Not commenting on recent discussions but rather focussing on what I hope wi=
ll be a good solution for the WG and the Internet at large.

Option 3) is my opinion not desirable; I wish we could have a reactive rout=
ing protocol for MANET

Option 2) is an option I would be strongly opposed to for a number of techn=
ical reasons that I would be happy to elaborate on the
mailing list and/or in a new I-D (which I would, should option 2 be chosen)=
.

That being said, I am extremely supportive of option 1), especially in ligh=
t of what Charlie said. First of all DYMO is the working group
document and excellent progress has been made with recent revisions. But ev=
en more importantly, Charlie managed to make it compatible
with options, which is in my opinion the best of both worlds; calling it AO=
DVv2 is only not very sensible but avoids useful sensitivity around
names.

Thus I would strongly support Option 1), continue the work that Charlie has=
 started, which by the way is not far from completion. And
as WG,we need to remember that this had been the WG document, the result of=
 years of work. Still by making it compatible with other options,
this is technically flexible and sound.

Thanks.

JP.

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:

Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A77220419BBxmbrcdx02ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Dear chairs,






Remembering that I am not a co-authors of either of these drafts.







Not commenting on recent discussions but rather focussing on what I=
 hope will be a good solution for the WG and the Internet at large.






Option 3) is my opinion not desirable; I wish we could h=
ave a reactive routing protocol for MANET







Option 2) is an option I would be strongly opposed to fo=
r a number of technical reasons that I would be happy to elaborate on the

mailing list and/or in a new I-D (which I would, should option 2 be ch=
osen).







That being said, I am extremely supportive of option 1), esp=
ecially in light of what Charlie said. First of all DYMO is the working=
 group


document and excellent progress has been made with recent revisions. B=
ut even more importantly, Charlie managed to make it compatible 


with options, which is in my opinion the best of both worlds; calling it AODVv2 is only not very sensible but avoids useful sensitivi=
ty around 


names.







Thus I would strongly support Option 1), continue the work that Cha=
rlie has started, which by the way is not far from completion. And =
;


as WG,we need to remember that this had been the WG document, the resu=
lt of years of work. Still by making it compatible with other options, =
;


this is technically flexible and sound.







Thanks.







JP.







On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:




Hello MANET working group (form Stan and Joe),


As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet














--_000_03B78081B371D44390ED6E7BADBB4A77220419BBxmbrcdx02ciscoc_--

From jvasseur@cisco.com  Wed Oct 31 01:31:13 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCDF21F8715 for ; Wed, 31 Oct 2012 01:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce5wYuzci5FV for ; Wed, 31 Oct 2012 01:31:13 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 35F3921F8722 for ; Wed, 31 Oct 2012 01:31:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2805; q=dns/txt; s=iport; t=1351672273; x=1352881873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BichYtkx9FTBcaDU3GOdFiyMEnQKUxZDXhjwHlzmjQE=; b=YXhAK0/AqiDnxmyv3Vd1IraThvwaM66DhsBJkpa7879+JC5W/Ge8yluE svmo9Nbrxi0awPEqHrQJ7QfRqUOtL3BNBNe7Rjd/X93lEyGryj07wo/GP l35MMOyATucvRo4D+OkEKFfCn+/lUQUTl9HcsIXwAygqVNZhlgN32DgJN 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFLhkFCtJXG+/2dsb2JhbABEw22BCIIeAQEBAwEBAQEPAVsLBQsCAQgYCiQnCyUCBA4FCBMHh14GC5tBoAUEi3gShUhhA6RNgWuCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,685,1344211200"; d="scan'208";a="137272454"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 31 Oct 2012 08:31:12 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9V8VC8f014089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 08:31:12 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 03:31:11 -0500
From: "JP Vasseur (jvasseur)" 
To: "Bo Berry (boberry)" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0IULPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 08:31:11 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77220419F1@xmb-rcd-x02.cisco.com>
References:  <50906802.9070904@saloits.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--43.181300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <7A09E6F40590E144BD5C8F319BC45411@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Timothy J. Salo" , " List" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 08:31:13 -0000

Hi Bo,

On Oct 31, 2012, at 1:11 AM, Bo Berry wrote:

> Joe, Stan
> Adding to Tim's option.
>=20
> If the MANET WG removes reactive from the charter, is there similar techn=
ology in another WG?  Perhaps ROLL?  If so this may be another option as th=
ere is a lot of synergy-commonality.

As ROLL co-chair =85 we are currently not chartered to work on another prot=
ocol.

Thanks.

JP.

>=20
> -Bo
>=20
>=20
> On Oct 30, 2012, at 7:51 PM, Timothy J. Salo wrote:
>=20
>>> As you are all probably aware, there has been WG activity lately on
>>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>>> current working group document that was parked due to inactivity), and
>>> LOADng.
>>=20
>> I suggest not excluding what might be considered a fourth possible
>> course of action, namely: wait.
>>=20
>> Based on what I have read and seen during meetings, I am concerned that
>> a decision to select one document over the other may be driven by
>> personalities, rather than technical content, the ability of the
>> authors to work with the members of the working group, or a
>> commitment by the authors to complete the process.
>>=20
>> Sometimes, simply deferring a decision permits things to sort
>> themselves out naturally, and avoids unnecessarily expending a lot of
>> time, energy, and perhaps even ill will by forcing a decision
>> prematurely.
>>=20
>> I can't say that deferring a decision will necessarily make the best
>> future path obvious.  But, it seems that the cost of not deciding at
>> this time is probably small (perhaps beyond the cost of additional
>> heated, even acrimonious, emails, posturing and positioning).
>>=20
>> Having said that, let me argue the contrary.  Sometimes, the best
>> course of action is decision-by-fiat (e.g., the working group chairs
>> direct a solution).  It is possible that either document and document
>> authors would serve the working group equally well.  In this case, a
>> quick, mandated solution may permit the working group to focus its
>> energy on progressing the selected document.  This approach probably has
>> a couple of requirements.  First, the authors of the selected document
>> _must_ ensure that their document progresses to an RFC in a expeditious
>> manner.  Second, the selection process (e.g., working group chair
>> directive) must appear fair to all involved.  If all things really are
>> equal, there is a lot to be said for a coin toss.
>>=20
>> -tjs
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From jvasseur@cisco.com  Wed Oct 31 01:31:48 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA80421F872A for ; Wed, 31 Oct 2012 01:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.615
X-Spam-Level: 
X-Spam-Status: No, score=-9.615 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVe9LZ4zz84r for ; Wed, 31 Oct 2012 01:31:48 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B79B621F8722 for ; Wed, 31 Oct 2012 01:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7262; q=dns/txt; s=iport; t=1351672307; x=1352881907; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6HKU1GfzlD/YU5zKL7EWjEe0R3oE7j4w97e7O3EUAeU=; b=gQG7pgNxDdM0xs0MD+mTjhD2lPwzQalcF6KNs3KCrh47HY2fdr3AdEsP ziCcn0k48drPCKEfsDnSzsQ2wHHRyDVkPXVmuVQhS3H1XIlZe35g3amyw 4QqqV/mK9wh4uOuL0zt5SYl84/zMD34ElanFiw+iJYxcmPbnyWGGU/A28 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFLhkFCtJXG+/2dsb2JhbABEw22BCIIfAQEEAQEBDwFbCxACAQgiHQcnCxQRAgQOBQgTB4dkC5tBoAUEi3gShUhhA4glnCiBa4EugUGCGQ
X-IronPort-AV: E=Sophos;i="4.80,685,1344211200";  d="scan'208,217";a="137240066"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2012 08:31:36 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9V8VZtZ014590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 08:31:35 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 03:31:35 -0500
From: "JP Vasseur (jvasseur)" 
To: Ulrich Herberg 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0IiLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 08:31:34 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com>
References:  <50906802.9070904@saloits.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--33.139100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722041A10xmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 08:31:48 -0000

--_000_03B78081B371D44390ED6E7BADBB4A7722041A10xmbrcdx02ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ulrich,

On Oct 31, 2012, at 1:08 AM, Ulrich Herberg wrote:

Timothy,

our company has deadlines for coming up with products on the market and cus=
tomers waiting. I believe that the same is true for other companies. We had=
 discussions for more than half a year now that did not lead anywhere.

Note that IETF cannot be driven by company roadmap.


Regards
Ulrich

On Tue, Oct 30, 2012 at 4:51 PM, Timothy J. Salo > wrote:
As you are all probably aware, there has been WG activity lately on
competing drafts for a MANET reactive protocol - DYMO (reviving the
current working group document that was parked due to inactivity), and
LOADng.

I suggest not excluding what might be considered a fourth possible
course of action, namely: wait.

Based on what I have read and seen during meetings, I am concerned that
a decision to select one document over the other may be driven by
personalities, rather than technical content, the ability of the
authors to work with the members of the working group, or a
commitment by the authors to complete the process.

Sometimes, simply deferring a decision permits things to sort
themselves out naturally, and avoids unnecessarily expending a lot of
time, energy, and perhaps even ill will by forcing a decision
prematurely.

I can't say that deferring a decision will necessarily make the best
future path obvious.  But, it seems that the cost of not deciding at
this time is probably small (perhaps beyond the cost of additional
heated, even acrimonious, emails, posturing and positioning).

Having said that, let me argue the contrary.  Sometimes, the best
course of action is decision-by-fiat (e.g., the working group chairs
direct a solution).  It is possible that either document and document
authors would serve the working group equally well.  In this case, a
quick, mandated solution may permit the working group to focus its
energy on progressing the selected document.  This approach probably has
a couple of requirements.  First, the authors of the selected document
_must_ ensure that their document progresses to an RFC in a expeditious
manner.  Second, the selection process (e.g., working group chair
directive) must appear fair to all involved.  If all things really are
equal, there is a lot to be said for a coin toss.

-tjs


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

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


--_000_03B78081B371D44390ED6E7BADBB4A7722041A10xmbrcdx02ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <3E8DF310B4E1224591638141BD5AEAD2@cisco.com>
Content-Transfer-Encoding: quoted-printable






Hi Ulrich,




--_000_03B78081B371D44390ED6E7BADBB4A7722041A10xmbrcdx02ciscoc_--

From pthubert@cisco.com  Wed Oct 31 01:52:36 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E3C21F8692 for ; Wed, 31 Oct 2012 01:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYNd2Ndp7WsA for ; Wed, 31 Oct 2012 01:52:35 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22621F871F for ; Wed, 31 Oct 2012 01:52:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1666; q=dns/txt; s=iport; t=1351673549; x=1352883149; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wVnXCX3LUwMjBvXya+Lhgy6c8VQE5qMjCcqaE3UuTd0=; b=X6MM3IoWyefcoMg0Efno5fMOsN/S/qBCCfVeMYb2umx7+PO6j1Z9ji0K nNv/Cdwv0beRWFaenBywsDmJEBbCp6rLkmGHVYeK94jnQFNrC1re5hzil TtRL9+lerlAFxpG/4TxY0Y40FuiUUlgfOtk3wfIaTjx11Cjr6s/UGR6gh M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANnlkFCtJXG//2dsb2JhbABEw22BCIIfAQEEEgEnTwIBCCIUEDIlAgQbEweHZJtNoAiRUmEDpE2Ba4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137239921"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2012 08:52:17 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9V8qG8w005957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Oct 2012 08:52:16 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.178]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 03:52:15 -0500
From: "Pascal Thubert (pthubert)" 
To: "manet@ietf.org" 
Thread-Topic: URGENT -- Fwd: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0IptqZ3T600L0e13HWXQCXBZpfTF2Ww
Date: Wed, 31 Oct 2012 08:52:14 +0000
Deferred-Delivery: Wed, 31 Oct 2012 08:52:00 +0000
Message-ID: 
References:  <03B78081B371D44390ED6E7BADBB4A7722041A1A@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722041A1A@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.93.210]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--39.634400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [manet] URGENT -- Fwd:  Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 08:52:36 -0000

Hello Joe,

>1. Continue the work on the DYMO document, starting with whether there is =
consensus on its continued approach and also the desire to rename it to AOD=
Vv2.
>2. Replace the existing DYMO document effort with the LOADng related docum=
ent effort, defusing ealier references to LLNs as recommended in the last m=
eeting minutes, and to focus more motivationally on general MANET problem s=
paces (the authors seem to have agreed to this issue if its a WG document).
>3. Remove the working group charter for a reactive protocol, effectively k=
illing both documents, at least from a working group (WG) standpoint. This =
would not be a reflection on the technology in either case, just an admissi=
on that we are not working together and reaching consensus.

My vote would go for 1, and then 3.=20

For 1) I like the idea to rename DYMO as AODV2 or v2, because AODV is now a=
 well-known name and we probably want to cash on that as opposed to give th=
e impression that this is yet another protocol. Also, considering what happ=
ens to metro these days, I'd avoid a trade mark.

For 3) If we cannot standardize DYMO/AODV which has been on the works for q=
uite  a while, then we probably want to restart with a clean slate and cons=
ider all potential ideas including those coming from ROLL.
You'll note that  RPL P2P , which is experimental, is also reactive, and il=
lustrates a need to provide a reactive solution in the LLN space to cover s=
ome use cases, in particular in home and building automation.
Now, that can be done in ROLL, MANET, or a DMZ and probably the latter woul=
d make more sense.

Cheers,

Pascal

From Chris.Dearlove@baesystems.com  Wed Oct 31 02:54:01 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC121F8639 for ; Wed, 31 Oct 2012 02:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk3Ezo+As80A for ; Wed, 31 Oct 2012 02:53:59 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAAF21F8463 for ; Wed, 31 Oct 2012 02:53:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600"; d="scan'208";a="282464644"
Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Oct 2012 09:53:58 +0000
Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9V9rwUR002164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 09:53:58 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 09:53:58 +0000
From: "Dearlove, Christopher (UK)" 
To: "Charles E. Perkins" , manet 
Thread-Topic: [manet] Flooding: how to make a normative reference?
Thread-Index: AQHNttZPizoWnGi+KUmvqHsqqFTRBJfTKzIg
Date: Wed, 31 Oct 2012 09:53:58 +0000
Message-ID: 
References: <50902CF3.9070903@computer.org>
In-Reply-To: <50902CF3.9070903@computer.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [manet] Flooding: how to make a normative reference?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 09:54:01 -0000

Pulling MPR flooding out of OLSRv2 is, as you say, too late. In my ideal wo=
rld the five documents that make up OLSRv2 would be seven or eight (the for=
warding/processing mechanism is usefully reusable as well). However various=
 reasons (both the effort to do, and the effort to shepherd more documents =
through the process) argued against it.

But if using MPRs you will have to reference OLSRv2 normatively, as it defi=
nes the MPR TLV, and defining a new one just to avoid referencing it would =
not be acceptable.

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C=
harles E. Perkins
Sent: 30 October 2012 19:40
To: manet
Subject: [manet] Flooding: how to make a normative reference?

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hello folks,

I think it is well recognized that brute force flooding often leads to
poor performance in ad hoc networks with many nodes.  Thus, we
have RFC 6621 to describe various other approaches.  Plus, we have
MPR flooding as described in the OLSRv2 document.

For reactive, it is quite important to enable "better" algorithms
for flooding.  AODVv2 could quite reasonable use a MPR-based
flooding, or flooding based over any connected dominating set.

It seems wrong to have AODVv2 cite OLSRv2 in any normative
fashion, just to get access to the MPR flooding mechanism which
can run independently of the routing protocol (and, perhaps,
should do so).  It also seems wrong to cite RFC 6621 in any
normative fashion since that is an Experimental specification.

Don't we need to have some Proposed Standard documents that
specify more scalable approaches to flooding, that are independent
of routing protocols?

I guess it's too late to suggest that the MPR specification should
be pulled out of OLSRv2 for this purpose...

I looked back for some discussion about this on the list, but I
didn't find it, but my search was hardly exhaustive.

--=20
Regards,
Charlie P.

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


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


From c.chauvenet@watteco.com  Wed Oct 31 02:56:40 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E515B21F876D for ; Wed, 31 Oct 2012 02:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE31A9SGmOQ5 for ; Wed, 31 Oct 2012 02:56:40 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id D6B1021F8639 for ; Wed, 31 Oct 2012 02:56:39 -0700 (PDT)
Received: from mail40-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 09:56:39 +0000
Received: from mail40-tx2 (localhost [127.0.0.1])	by mail40-tx2-R.bigfish.com (Postfix) with ESMTP id F3E55300289; Wed, 31 Oct 2012 09:56:38 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VPS-21(zzc89bhc85dh1418Izz1202h1d1ah1d2ahz8dhz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h)
Received: from mail40-tx2 (localhost.localdomain [127.0.0.1]) by mail40-tx2 (MessageSwitch) id 1351677396242488_1303; Wed, 31 Oct 2012 09:56:36 +0000 (UTC)
Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.241])	by mail40-tx2.bigfish.com (Postfix) with ESMTP id 2E15A2C0043; Wed, 31 Oct 2012 09:56:36 +0000 (UTC)
Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 09:56:35 +0000
Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT003.eurprd05.prod.outlook.com ([10.255.67.166]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 09:56:32 +0000
From: C Chauvenet 
To: Joseph Macker 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvRAV6TKZOGU0EeXjdQ8Uxmd8pfTLhcA
Date: Wed, 31 Oct 2012 09:56:31 +0000
Message-ID: <97B69B30E0EF244B940B65EA541E3F2D2156CC7C@DBXPRD0510MB395.eurprd05.prod.outlook.com>
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.42.4]
Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D2156CC7CDBXPRD0510MB395_"
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 09:56:41 -0000

--_000_97B69B30E0EF244B940B65EA541E3F2D2156CC7CDBXPRD0510MB395_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Joseph, and thank you for this great summary.

My vote would go for option 1), and here is why, from my personal point of =
view :

Option 1) leverage on years of work within the MANET WG. I don't see a stro=
ng reason to discard this. Furthermore, naming it AODVv2 also leverage on a=
 well-know protocol name that would add clarity and visibility to the docum=
ent. I am very impressed about the amount of work conducted by Charles to a=
ddress the review of the last DYMO draft and update the document accordingl=
y. I think charles show us the willingness and ability to finish that work =
efficiently.

Option 2), would annihilate years of previous work realized for DYMO in the=
 MANET WG. Again, I don't see a reason to discard it with a protocol that p=
opped up in MANET 4 months ago. Moreover, the adoption of LOADng may add so=
me misunderstanding about the intend of such a protocol when readers will l=
ook at its history. The initial name signification of "LOADng" is a good ex=
ample, and the last update of the protocol roughly search & replace "LLN" w=
ording by "MANET" as we can see here : http://tools.ietf.org/rfcdiff?url1=
=3Ddraft-clausen-lln-loadng-05.txt. I think such a confusion will not drive=
 the future of internet in a good direction, as JP mentioned. My fear is th=
at it could create confusion and slow down both LLNs and MANET deployments.

Option 3) could be a final option... but it would be too bad to go here, as=
 I think that reactive protocol can bring great benefits in MANET. Moreover=
, this would collapse all work around reactive protocols in MANET, for both=
 LOADng and DYMO authors.

Best,
C=E9dric.

Le 31 oct. 2012 =E0 00:13, Joseph Macker a =E9crit :

Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--_000_97B69B30E0EF244B940B65EA541E3F2D2156CC7CDBXPRD0510MB395_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <940942FFBBCDDD43980B91F9644065A1@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






Hi Joseph, and thank you for this great summary.






My vote would go for option 1), and here is why, from my personal poin=
t of view : 







Option 1) leverage on years of work within the MANET WG. I don't see a=
 strong reason to discard this. Furthermore, naming it AODVv2 also leverage=
 on a well-know protocol name that would add clarity and visibility to the =
document. I am very impressed about
 the amount of work conducted by Charles to address the review of the last =
DYMO draft and update the document accordingly. I think charles show us the=
 willingness and ability to finish that work efficiently.







Option 2), would annihilate years of previous work realized for DYMO i=
n the MANET WG. Again, I don't see a reason to discard it with a protocol t=
hat popped up in MANET 4 months ago. Moreover, the adoption of LOADng may a=
dd some misunderstanding about the
 intend of such a protocol when readers will look at its history. The initi=
al name signification of "LOADng" is a good example, and the last=
 update of the protocol roughly search & replace "LLN" wordin=
g by "MANET" as we can see here : http://tools.ietf.or=
g/rfcdiff?url1=3Ddraft-clausen-lln-loadng-05.txt.
 I think such a confusion will not drive the future of internet in a good d=
irection, as JP mentioned. My fear is that it could create confusion and sl=
ow down both LLNs and MANET deployments. 









Option 3) could be a final option... but it would be too bad to go her=
e, as I think that reactive protocol can bring great benefits in MANET. Mor=
eover, this would collapse all work around reactive protocols in MANET, for=
 both LOADng and DYMO authors. 







Best,


C=E9dric.







Le 31 oct. 2012 =E0 00:13, Joseph Macker a =E9crit :




Hello MANET working group (form Stan and Joe),


As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet














--_000_97B69B30E0EF244B940B65EA541E3F2D2156CC7CDBXPRD0510MB395_--

From teco@inf-net.nl  Wed Oct 31 02:58:40 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83C121F85FF for ; Wed, 31 Oct 2012 02:58:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs2gd5OKHfwe for ; Wed, 31 Oct 2012 02:58:40 -0700 (PDT)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1365821F85FE for ; Wed, 31 Oct 2012 02:58:39 -0700 (PDT)
Received: by mail-ea0-f172.google.com with SMTP id k13so544780eaa.31 for ; Wed, 31 Oct 2012 02:58:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Gkctko458s/pTTLltHMqyTzHCBxPIbehZvpAowF70ps=; b=a4/OLCODY2TT0/Mka86qLb1LYy/X7e9fyVF0Xmz8Fmei6/dnk/Kliw+NBkpeh/Bm/a BrjMj9VDekOxZ00A5Aln+nmTv87b8qh67Xd+N00fAn1xvxVEXHxpYX1IzVY+lnt/HehT 9+BLYNEaQd1ybkJm6KOajyOe16UVFoxVNAplAs1AiSniktCxUWpC87yjuewv4BhFOxOK MBE8PwdysSaYhEDTTqI7wFgYzSD+fkhcZdXFCExot44RsS6TMSJmI1oPnXzQTyXNHIZg 87nIhPPSWAM/1ecG6Dh7BiZ+VXEZ04V6BLx7FAeONOBm2RAEp763ASMqe+q6WassaGP/ Uu0A==
Received: by 10.14.175.71 with SMTP id y47mr83762418eel.36.1351677519218; Wed, 31 Oct 2012 02:58:39 -0700 (PDT)
Received: from [172.20.10.2] ([84.241.214.97]) by mx.google.com with ESMTPS id f2sm6995142eep.2.2012.10.31.02.58.37 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 02:58:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Teco Boot 
In-Reply-To: 
Date: Wed, 31 Oct 2012 10:58:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Joseph Macker 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQmzjhnNhg+b+FGc0ueQCN+8soolsFYnraw89TboSvZXrcJuwOv3sEwhXUsYjAi5qIdg0A2a
Cc: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 09:58:41 -0000

Op 31 okt. 2012, om 00:13 heeft Joseph Macker het volgende geschreven:
> 1. Continue the work on the DYMO document, starting with whether there =
is consensus on its continued approach and also the desire to rename it =
to AODVv2.
> 2. Replace the existing DYMO document effort with the LOADng related =
document effort, defusing ealier references to LLNs as recommended in =
the last meeting minutes, and to focus more motivationally on general =
MANET problem spaces (the authors seem to have agreed to this issue if =
its a WG document).
> 3. Remove the working group charter for a reactive protocol, =
effectively killing both documents, at least from a working group (WG) =
standpoint. This would not be a reflection on the technology in either =
case, just an admission that we are not working together and reaching =
consensus.


I support rename our standards track reactive protocol, that has its =
roots in AODV, into AODVv2. This applies to options 1 and 2.

I'm not quite happy about the "my protocol is better, yours' is lousy" =
attitude. Even if this is the case, I prefer we, as a working group, =
work together and make good progress. With as a result a single standard =
protocol, that will be accepted and implemented by many organizations, =
if not all.

I did not see good reasons to start all over to define a standards track =
proactive MANET protocol in public. I see (too) many efforts to come up =
with yet another MANET protocol. Sometimes, proprietary is mentioned as =
a feature, or the protocol is called "better approach to". This doesn't =
help.

So I vote for option 1. This could be copy & paste large amounts of text =
from drafts, if WG decides so. I know this approach is tried before, =
without great success. Maybe we simply push somewhat harder.

Thanks.=20
Teco




From Chris.Dearlove@baesystems.com  Wed Oct 31 03:02:20 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12921F8781 for ; Wed, 31 Oct 2012 03:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVtkVBFw5zvU for ; Wed, 31 Oct 2012 03:02:19 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2862E21F842D for ; Wed, 31 Oct 2012 03:02:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600";  d="scan'208,217";a="239915531"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 31 Oct 2012 10:02:17 +0000
Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VA2F81032022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 10:02:16 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 10:02:16 +0000
From: "Dearlove, Christopher (UK)" 
To: "JP Vasseur (jvasseur)" , Joseph Macker 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfTFaOAgAAYXXA=
Date: Wed, 31 Oct 2012 10:02:16 +0000
Message-ID: 
References:  <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB40C3GLKXM0002VGREEN_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 10:02:20 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB40C3GLKXM0002VGREEN_
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

As someone who has not (yet) stated an opinion on the matter, except I also think option 3 is not good, I would very much like to hear technical arguments, so if you have technical arguments against LOADng, I think we need to hear them rather than just suggesting they exist. I haven't yet read LOADng carefully to form a view there. I have just recently read the AODVv2 draft carefully, and have some technical issues there (which overlap) regarding asymmetric links, possible dependency on NHDP, and the compatibility of options. If option 1 is followed, the draft needs work (which Charlie has acknowledged).

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: 
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.
Dear chairs,

Remembering that I am not a co-authors of either of these drafts.

Not commenting on recent discussions but rather focussing on what I hope will be a good solution for the WG and the Internet at large.

Option 3) is my opinion not desirable; I wish we could have a reactive routing protocol for MANET

Option 2) is an option I would be strongly opposed to for a number of technical reasons that I would be happy to elaborate on the
mailing list and/or in a new I-D (which I would, should option 2 be chosen).

That being said, I am extremely supportive of option 1), especially in light of what Charlie said. First of all DYMO is the working group
document and excellent progress has been made with recent revisions. But even more importantly, Charlie managed to make it compatible
with options, which is in my opinion the best of both worlds; calling it AODVv2 is only not very sensible but avoids useful sensitivity around
names.

Thus I would strongly support Option 1), continue the work that Charlie has started, which by the way is not far from completion. And
as WG,we need to remember that this had been the WG document, the result of years of work. Still by making it compatible with other options,
this is technically flexible and sound.

Thanks.

JP.

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:


Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competing drafts for a MANET reactive protocol - DYMO (reviving the current working group document that was parked due to inactivity), and LOADng. Many months ago there was a somewhat authorship led movement towards a common document effort and given positive feedback at the time we the chairs thought this was the best approach given the authors potential to come together and gain the best of both efforts.  Since that period, there has been some fairly strident and rancorous "at times" debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of the co-authors of the two documents. Our guidance to the co-authors was to find a way to merge the two documents into one, as it was perceived that are not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active authorship and implementation efforts. We provided a co-editing proposal to the authors and gave them the timeframe of the Atlanta to come up with an answer back to us regarding this.  As of this writing, those discussions of a potential commonn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two documents are divided, and it is unlikely that progress on a merged document can be reached based upon recent author feedback. I have also polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is consensus on its continued approach and also the desire to rename it to AODVv2.
2. Replace the existing DYMO document effort with the LOADng related document effort, defusing ealier references to LLNs as recommended in the last meeting minutes, and to focus more motivationally on general MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively killing both documents, at least from a working group (WG) standpoint. This would not be a reflection on the technology in either case, just an admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been some silent collecting initial feedback and waiting for author feedback at this point.  Stan and I are both on travel prior to Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


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


--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB40C3GLKXM0002VGREEN_
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit











As someone who has not (yet) stated an opinion on the matter, except I also think option 3 is not good, I would very much like to hear technical arguments,
 so if you have technical arguments against LOADng, I think we need to hear them rather than just suggesting they exist. I haven't yet read LOADng carefully to form a view there. I have just recently read the AODVv2 draft carefully, and have some technical
 issues there (which overlap) regarding asymmetric links, possible dependency on NHDP, and the compatibility of options. If option 1 is followed, the draft needs work (which Charlie has acknowledged).


 




--



Christopher Dearlove


Senior Principal Engineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124


chris.dearlove@baesystems.com
 | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687




 






From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]
On Behalf Of JP Vasseur (jvasseur)

Sent: 31 October 2012 08:29

To: Joseph Macker

Cc: <manet@ietf.org>

Subject: Re: [manet] Reactive Protocol Situation






 




 




*** WARNING ***







This message originates from outside our organisation, either from an external partner or the internet.

Keep this in mind if you answer this message.

Please see 
this process on how to deal with suspicious emails.






Dear chairs, 




 






Remembering that I am not a co-authors of either of these drafts.




 






Not commenting on recent discussions but rather focussing on what I hope will be a good solution for the WG and the Internet at large.






 






Option 3) is my opinion not desirable; I wish we could have a reactive routing protocol for MANET






 






Option 2) is an option I would be strongly opposed to for a number of technical reasons that I would be happy to elaborate on the






mailing list and/or in a new I-D (which I would, should option 2 be chosen).






 






That being said, I am extremely supportive of option 1),
especially in light of what Charlie said. First of all DYMO is the working group






document and excellent progress has been made with recent revisions. But even more importantly, Charlie managed to make it compatible 






with options, which is in my opinion the best of both worlds; calling it AODVv2 is only not very sensible but avoids useful sensitivity around 






names.






 






Thus I would strongly support Option 1), continue the work that Charlie has started, which by the way is not far from completion. And 






as WG,we need to remember that this had been the WG document, the result of years of work. Still by making it compatible with other options, 






this is technically flexible and sound.






 






Thanks.






 






JP.






 






On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:











Hello MANET working group (form Stan and Joe),



As you are all probably aware, there has been WG activity lately on competing drafts for a MANET reactive protocol - DYMO (reviving the current working group document that was parked due to inactivity), and LOADng. Many months ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback at the time we the chairs thought this was the best approach given the authors potential to come together and gain the best of both efforts.  Since that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of the co-authors of the two documents. Our guidance to the co-authors was to find a way to merge the two documents into one, as it was perceived that are not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active authorship and implementation efforts. We provided a co-editing proposal to the authors and gave them the timeframe of the Atlanta to come up with an answer back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and authorship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two documents are divided, and it is unlikely that progress on a merged document can be reached based upon recent author feedback. I have also polled the earlier WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We see only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is consensus on its continued approach and also the desire to rename it to AODVv2.

2. Replace the existing DYMO document effort with the LOADng related document effort, defusing ealier references to LLNs as recommended in the last meeting minutes, and to focus more motivationally on general MANET problem spaces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively killing both documents, at least from a working group (WG) standpoint. This would not be a reflection on the technology in either case, just an admission that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have been some silent collecting initial feedback and waiting for author feedback at this point.  Stan and I are both on travel prior to Atlanta so our responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet




 







 

********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************






--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB40C3GLKXM0002VGREEN_--

From c.chauvenet@watteco.com  Wed Oct 31 03:06:01 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42D21F8792 for ; Wed, 31 Oct 2012 03:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level: 
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpwbezuR7fln for ; Wed, 31 Oct 2012 03:05:57 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1721F875D for ; Wed, 31 Oct 2012 03:05:57 -0700 (PDT)
Received: from mail167-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 10:05:50 +0000
Received: from mail167-co9 (localhost [127.0.0.1])	by mail167-co9-R.bigfish.com (Postfix) with ESMTP id 3CC114C0152; Wed, 31 Oct 2012 10:05:50 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: VPS-24(zzbb2dI98dI9371Ic89bh1432Izz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail167-co9 (localhost.localdomain [127.0.0.1]) by mail167-co9 (MessageSwitch) id 1351677947926005_13873; Wed, 31 Oct 2012 10:05:47 +0000 (UTC)
Received: from CO9EHSMHS032.bigfish.com (unknown [10.236.132.225])	by mail167-co9.bigfish.com (Postfix) with ESMTP id DEFFA480043; Wed, 31 Oct 2012 10:05:47 +0000 (UTC)
Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by CO9EHSMHS032.bigfish.com (10.236.130.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 10:05:47 +0000
Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.67.167]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 10:05:47 +0000
From: C Chauvenet 
To: "Charles E. Perkins" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvRAV6TKZOGU0EeXjdQ8Uxmd8pfShQ4AgAAEzgCAAKbSAA==
Date: Wed, 31 Oct 2012 10:05:46 +0000
Message-ID: <97B69B30E0EF244B940B65EA541E3F2D2156CD16@DBXPRD0510MB395.eurprd05.prod.outlook.com>
References:  <50906802.9070904@saloits.com> <50906C0A.5040702@computer.org>
In-Reply-To: <50906C0A.5040702@computer.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.42.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 10:06:01 -0000

Hi Charles,=20

Le 31 oct. 2012 =E0 01:08, Charles E. Perkins a =E9crit :

>=20
> Hello folks,
>=20
> I've been working away to get the DYMO now AODVv2 specification to
> fit the needs of LOADng and also to make various major improvements
> to readability, RFC 5444 compliance, etc.  I'm well along the way, even
> though I had delayed starting the process until very recently, while
> attempting to find the right process to join forces with the LOADng
> authors.  In fact, the LOADng authors had asked me not to submit
> any revised document during the meantime, and I eventually decided
> to submit a revision only after I realized that the expected document
> merge would just not happen. =20

Ho, too bad.
I hoped merging efforts could have been a good solution...


> Given the short amount of time (only
> a few weeks), I think the progress has been very good.

Agree.

C=E9dric.

>=20
> I'd certainly like to continue that.  Since the agreement all along had
> been make the WG reactive protocol compatible with LOADng, I can
> suggest that the current specification be completed with design
> choices that enable LOADng as a "subset".
>=20
> Regards,
> Charlie P.
>=20
>=20
>=20
>=20
>=20
> On 10/30/2012 4:51 PM, Timothy J. Salo wrote:
>>> As you are all probably aware, there has been WG activity lately on
>>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>>> current working group document that was parked due to inactivity), and
>>> LOADng.
>>=20
>> I suggest not excluding what might be considered a fourth possible
>> course of action, namely: wait.
>>=20
>> Based on what I have read and seen during meetings, I am concerned that
>> a decision to select one document over the other may be driven by
>> personalities, rather than technical content, the ability of the
>> authors to work with the members of the working group, or a
>> commitment by the authors to complete the process.
>>=20
>> Sometimes, simply deferring a decision permits things to sort
>> themselves out naturally, and avoids unnecessarily expending a lot of
>> time, energy, and perhaps even ill will by forcing a decision
>> prematurely.
>>=20
>> I can't say that deferring a decision will necessarily make the best
>> future path obvious.  But, it seems that the cost of not deciding at
>> this time is probably small (perhaps beyond the cost of additional
>> heated, even acrimonious, emails, posturing and positioning).
>>=20
>> Having said that, let me argue the contrary.  Sometimes, the best
>> course of action is decision-by-fiat (e.g., the working group chairs
>> direct a solution).  It is possible that either document and document
>> authors would serve the working group equally well.  In this case, a
>> quick, mandated solution may permit the working group to focus its
>> energy on progressing the selected document.  This approach probably has
>> a couple of requirements.  First, the authors of the selected document
>> _must_ ensure that their document progresses to an RFC in a expeditious
>> manner.  Second, the selection process (e.g., working group chair
>> directive) must appear fair to all involved.  If all things really are
>> equal, there is a lot to be said for a coin toss.
>>=20
>> -tjs
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>=20
>=20
>=20
> --=20
> Regards,
> Charlie P.
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>=20



From Chris.Dearlove@baesystems.com  Wed Oct 31 03:06:45 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3F21F8786 for ; Wed, 31 Oct 2012 03:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R1saZ+srCqQ for ; Wed, 31 Oct 2012 03:06:44 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57B21F8764 for ; Wed, 31 Oct 2012 03:06:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600"; d="scan'208";a="282471223"
Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Oct 2012 10:06:43 +0000
Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VA6hHH020944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 10:06:43 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 10:06:42 +0000
From: "Dearlove, Christopher (UK)" 
To: "Timothy J. Salo" , Joseph Macker 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfShQ4AgACrU/A=
Date: Wed, 31 Oct 2012 10:06:41 +0000
Message-ID: 
References:  <50906802.9070904@saloits.com>
In-Reply-To: <50906802.9070904@saloits.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 10:06:45 -0000

I'm not in favour of either waiting or decision by fiat. Note that when I s=
ay I'm not in favour of waiting, that doesn't mean I'm not in favour of wor=
k that might cause a delay - I think whatever route we go down there is wor=
k to be done.

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T=
imothy J. Salo
Sent: 30 October 2012 23:52
To: Joseph Macker
Cc: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

> As you are all probably aware, there has been WG activity lately on
> competing drafts for a MANET reactive protocol - DYMO (reviving the
> current working group document that was parked due to inactivity), and
> LOADng.

I suggest not excluding what might be considered a fourth possible
course of action, namely: wait.

Based on what I have read and seen during meetings, I am concerned that
a decision to select one document over the other may be driven by
personalities, rather than technical content, the ability of the
authors to work with the members of the working group, or a
commitment by the authors to complete the process.

Sometimes, simply deferring a decision permits things to sort
themselves out naturally, and avoids unnecessarily expending a lot of
time, energy, and perhaps even ill will by forcing a decision
prematurely.

I can't say that deferring a decision will necessarily make the best
future path obvious.  But, it seems that the cost of not deciding at
this time is probably small (perhaps beyond the cost of additional
heated, even acrimonious, emails, posturing and positioning).

Having said that, let me argue the contrary.  Sometimes, the best
course of action is decision-by-fiat (e.g., the working group chairs
direct a solution).  It is possible that either document and document
authors would serve the working group equally well.  In this case, a
quick, mandated solution may permit the working group to focus its
energy on progressing the selected document.  This approach probably has
a couple of requirements.  First, the authors of the selected document
_must_ ensure that their document progresses to an RFC in a expeditious
manner.  Second, the selection process (e.g., working group chair
directive) must appear fair to all involved.  If all things really are
equal, there is a lot to be said for a coin toss.

-tjs

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


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


From Chris.Dearlove@baesystems.com  Wed Oct 31 03:16:12 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C20921F8727 for ; Wed, 31 Oct 2012 03:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRzQe51nlnza for ; Wed, 31 Oct 2012 03:16:11 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4303B21F8736 for ; Wed, 31 Oct 2012 03:16:11 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600"; d="scan'208";a="282475487"
Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Oct 2012 10:16:10 +0000
Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VAG9Ro027118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 10:16:09 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 10:16:09 +0000
From: "Dearlove, Christopher (UK)" 
To: Bo Berry , Joseph Macker , "Stan Ratliff (sratliff)" , " List" , "Timothy J. Salo" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfShQ4AgAAFsICAAKZZ8A==
Date: Wed, 31 Oct 2012 10:16:09 +0000
Message-ID: 
References:  <50906802.9070904@saloits.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 10:16:12 -0000

The ROLL WG participants who have been posting here have made it very clear=
 that they see LLNs as a distinct area, and have strongly resisted more gen=
eral purpose MANET routing protocols claiming applicability in LLNs. (I don=
't actually agree with that, but that's not my point here.) To reverse that=
 and say the ROLL WG should now be responsible for a general purpose reacti=
ve routing protocol is clearly incompatible with that.

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B=
o Berry
Sent: 31 October 2012 00:12
To: Joseph Macker; Stan Ratliff (sratliff);  List; Timothy =
J. Salo
Subject: Re: [manet] Reactive Protocol Situation

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Joe, Stan
Adding to Tim's option.

If the MANET WG removes reactive from the charter, is there similar technol=
ogy in another WG?  Perhaps ROLL?  If so this may be another option as ther=
e is a lot of synergy-commonality.

-Bo


On Oct 30, 2012, at 7:51 PM, Timothy J. Salo wrote:

>> As you are all probably aware, there has been WG activity lately on
>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>> current working group document that was parked due to inactivity), and
>> LOADng.
>=20
> I suggest not excluding what might be considered a fourth possible
> course of action, namely: wait.
>=20
> Based on what I have read and seen during meetings, I am concerned that
> a decision to select one document over the other may be driven by
> personalities, rather than technical content, the ability of the
> authors to work with the members of the working group, or a
> commitment by the authors to complete the process.
>=20
> Sometimes, simply deferring a decision permits things to sort
> themselves out naturally, and avoids unnecessarily expending a lot of
> time, energy, and perhaps even ill will by forcing a decision
> prematurely.
>=20
> I can't say that deferring a decision will necessarily make the best
> future path obvious.  But, it seems that the cost of not deciding at
> this time is probably small (perhaps beyond the cost of additional
> heated, even acrimonious, emails, posturing and positioning).
>=20
> Having said that, let me argue the contrary.  Sometimes, the best
> course of action is decision-by-fiat (e.g., the working group chairs
> direct a solution).  It is possible that either document and document
> authors would serve the working group equally well.  In this case, a
> quick, mandated solution may permit the working group to focus its
> energy on progressing the selected document.  This approach probably has
> a couple of requirements.  First, the authors of the selected document
> _must_ ensure that their document progresses to an RFC in a expeditious
> manner.  Second, the selection process (e.g., working group chair
> directive) must appear fair to all involved.  If all things really are
> equal, there is a lot to be said for a coin toss.
>=20
> -tjs
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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


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


From c.chauvenet@watteco.com  Wed Oct 31 03:17:57 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595E221F84CC for ; Wed, 31 Oct 2012 03:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level: 
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7QHNVKGc0FE for ; Wed, 31 Oct 2012 03:17:56 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB9121F84CA for ; Wed, 31 Oct 2012 03:17:56 -0700 (PDT)
Received: from mail131-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 10:17:55 +0000
Received: from mail131-ch1 (localhost [127.0.0.1])	by mail131-ch1-R.bigfish.com (Postfix) with ESMTP id 5D9EF400FE; Wed, 31 Oct 2012 10:17:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -19
X-BigFish: VPS-19(z555ehf7I1cekzc89bh1432Izz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail131-ch1 (localhost.localdomain [127.0.0.1]) by mail131-ch1 (MessageSwitch) id 1351678672942870_1555; Wed, 31 Oct 2012 10:17:52 +0000 (UTC)
Received: from CH1EHSMHS043.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233])	by mail131-ch1.bigfish.com (Postfix) with ESMTP id DA761260053;	Wed, 31 Oct 2012 10:17:52 +0000 (UTC)
Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 10:17:52 +0000
Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT003.eurprd05.prod.outlook.com ([10.255.67.166]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 10:17:45 +0000
From: C Chauvenet 
To: "Pascal Thubert (pthubert)" 
Thread-Topic: [manet] URGENT -- Fwd:  Reactive Protocol Situation
Thread-Index: AQHNt0IptqZ3T600L0e13HWXQCXBZpfTF2WwgAAcBQA=
Date: Wed, 31 Oct 2012 10:17:44 +0000
Message-ID: <97B69B30E0EF244B940B65EA541E3F2D2156CE04@DBXPRD0510MB395.eurprd05.prod.outlook.com>
References:  <03B78081B371D44390ED6E7BADBB4A7722041A1A@xmb-rcd-x02.cisco.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.42.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8BBBEF040EE86B4093CE9FFDBAFD3AD1@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "manet@ietf.org" 
Subject: Re: [manet] URGENT -- Fwd:  Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 10:17:57 -0000

Hi,=20

See inline,

Le 31 oct. 2012 =E0 09:52, Pascal Thubert (pthubert) a =E9crit :

> Hello Joe,
>=20
>> 1. Continue the work on the DYMO document, starting with whether there i=
s consensus on its continued approach and also the desire to rename it to A=
ODVv2.
>> 2. Replace the existing DYMO document effort with the LOADng related doc=
ument effort, defusing ealier references to LLNs as recommended in the last=
 meeting minutes, and to focus more motivationally on general MANET problem=
 spaces (the authors seem to have agreed to this issue if its a WG document=
).
>> 3. Remove the working group charter for a reactive protocol, effectively=
 killing both documents, at least from a working group (WG) standpoint. Thi=
s would not be a reflection on the technology in either case, just an admis=
sion that we are not working together and reaching consensus.
>=20
> My vote would go for 1, and then 3.=20
>=20
> For 1) I like the idea to rename DYMO as AODV2 or v2, because AODV is now=
 a well-known name and we probably want to cash on that as opposed to give =
the impression that this is yet another protocol. Also, considering what ha=
ppens to metro these days, I'd avoid a trade mark.
>=20
> For 3) If we cannot standardize DYMO/AODV which has been on the works for=
 quite  a while, then we probably want to restart with a clean slate and co=
nsider all potential ideas including those coming from ROLL.
> You'll note that  RPL P2P , which is experimental, is also reactive, and =
illustrates a need to provide a reactive solution in the LLN space to cover=
 some use cases, in particular in home and building automation.

Good point.
Actually things are rather simple :=20

For LLN : IETF created ROLL to design a dedicated protocol, RPL with a pro-=
active approach.
If reactive is needed, RPL-P2P is there.

For MANET : IETF created MANET to design a dedicated protocol, OLSR with a =
pro-active approach.
For the reactive approach, DYMO has been fleshed out, and it is now time to=
 complete it.
I don't see a problem to enhance DYMO with LOADng mechanisms (for flooding =
for instance) if this can benefit to the internet, but it seems that the me=
rge has failed.

C=E9dric.

> Now, that can be done in ROLL, MANET, or a DMZ and probably the latter wo=
uld make more sense.
>=20
> Cheers,
>=20
> Pascal
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>=20



From ietf@thomasclausen.org  Wed Oct 31 03:31:06 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E405321F8797 for ; Wed, 31 Oct 2012 03:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level: 
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knu2wwJUaAdu for ; Wed, 31 Oct 2012 03:31:05 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AA89121F8793 for ; Wed, 31 Oct 2012 03:31:05 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 38D49A663C for ; Wed, 31 Oct 2012 03:31:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A29031BCB27C; Wed, 31 Oct 2012 03:31:02 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [10.155.173.79] (unknown [37.160.22.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C58221BCB274; Wed, 31 Oct 2012 03:30:54 -0700 (PDT)
References: <50902CF3.9070903@computer.org> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E122AA0-CC27-4FF5-8EED-ED8574B6949C@thomasclausen.org>
X-Mailer: iPhone Mail (10A403)
From: Thomas Heide Clausen 
Date: Wed, 31 Oct 2012 11:30:49 +0100
To: "Dearlove, Christopher (UK)" 
Cc: manet 
Subject: Re: [manet] Flooding: how to make a normative reference?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 10:31:07 -0000

Agree 100% with Chris here.=20

Thomas

--=20
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for=20
  experiments, and they wander off through equation=20
  after equation, and eventually  build a structure=20
  which has no relation to reality."
 - Nikola Tesla,=20
    Modern Mechanics and Inventions, July, 1934

On 31 oct. 2012, at 10:53, "Dearlove, Christopher (UK)"  wrote:

> Pulling MPR flooding out of OLSRv2 is, as you say, too late. In my ideal w=
orld the five documents that make up OLSRv2 would be seven or eight (the for=
warding/processing mechanism is usefully reusable as well). However various r=
easons (both the effort to do, and the effort to shepherd more documents thr=
ough the process) argued against it.
>=20
> But if using MPRs you will have to reference OLSRv2 normatively, as it def=
ines the MPR TLV, and defining a new one just to avoid referencing it would n=
ot be acceptable.
>=20
> --=20
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>=20
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,=
 Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>=20
>=20
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C=
harles E. Perkins
> Sent: 30 October 2012 19:40
> To: manet
> Subject: [manet] Flooding: how to make a normative reference?
>=20
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
> Hello folks,
>=20
> I think it is well recognized that brute force flooding often leads to
> poor performance in ad hoc networks with many nodes.  Thus, we
> have RFC 6621 to describe various other approaches.  Plus, we have
> MPR flooding as described in the OLSRv2 document.
>=20
> For reactive, it is quite important to enable "better" algorithms
> for flooding.  AODVv2 could quite reasonable use a MPR-based
> flooding, or flooding based over any connected dominating set.
>=20
> It seems wrong to have AODVv2 cite OLSRv2 in any normative
> fashion, just to get access to the MPR flooding mechanism which
> can run independently of the routing protocol (and, perhaps,
> should do so).  It also seems wrong to cite RFC 6621 in any
> normative fashion since that is an Experimental specification.
>=20
> Don't we need to have some Proposed Standard documents that
> specify more scalable approaches to flooding, that are independent
> of routing protocols?
>=20
> I guess it's too late to suggest that the MPR specification should
> be pulled out of OLSRv2 for this purpose...
>=20
> I looked back for some discussion about this on the list, but I
> didn't find it, but my search was hardly exhaustive.
>=20
> --=20
> Regards,
> Charlie P.
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>=20
>=20
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

From yi.jiazi@gmail.com  Wed Oct 31 04:01:08 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE2521F865E for ; Wed, 31 Oct 2012 04:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdvqL+CDu2GP for ; Wed, 31 Oct 2012 04:01:07 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF07C21F8512 for ; Wed, 31 Oct 2012 04:01:06 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so610996wgb.13 for ; Wed, 31 Oct 2012 04:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Rs6j2QeQJzCSALxN9+1pyDjkZV6OE3B5KBLrJ2X42k8=; b=n8qM6oZ+74X5RWNDAkiyHKK+skFUC02LuoKyQMrE9f4o8UjVay7ARSiIpZonteSDZe YeAOtuJJ9bnIXv9ZaRxgwH6Lfvie6G5j2+eYCq49oRJrYwQTQEhgB18ir86AFvP+aQLo DwduOE6+i+V+5saEysPlWke+fQC1yX8iC4gw94j3YXTAWRR4QiOr0VC8PdHLqFw0kEuB Lo6I7CssCv8RP3bbEHbOOVKBBK94lDJhImTnGQP5WMUygxCwd0qMUV6x9B/s8MBamC18 EyItYcR9re1wYUUiyTWdIy+JOjdfFPAtSPbDJ6un3Jrx9vrrsD50wemsQU3G0Kh1MMQ6 /YbA==
Received: by 10.180.77.38 with SMTP id p6mr1937530wiw.1.1351681265866; Wed, 31 Oct 2012 04:01:05 -0700 (PDT)
Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id bi9sm5269145wib.11.2012.10.31.04.01.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 04:01:04 -0700 (PDT)
Sender: Jiazi YI 
Content-Type: multipart/alternative; boundary="Apple-Mail=_101BE71F-AADB-4239-A9F5-C3D098C1611F"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Jiazi YI 
In-Reply-To: 
Date: Wed, 31 Oct 2012 12:01:03 +0100
Message-Id: 
References: 
To: Joseph Macker 
X-Mailer: Apple Mail (2.1499)
Cc: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 11:01:08 -0000

--Apple-Mail=_101BE71F-AADB-4239-A9F5-C3D098C1611F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Dear all,=20

Thanks Joe for briefing what had happened in the last several months.=20

I really don't want to dig into the history, but as long as someone =
mentioned "results of years of work", I think those facts are clear with =
my short memory of MANET:

1. In IETF 87 Maastricht 2010, DYMO was "parked" because the editors =
"lost the passion" to continue the work, disregarding the comments made =
for dymo from the mailing list.=20

2. After that, LOADng was born to meet real needs of the industry. Great =
efforts have been invested in the last two years, with hundreds =
iterations on the draft from ~10 authors, interop test, real =
implementations. Now with concrete results, interop report, mib =
document, etc.=20

3. After the DYMO draft sleeping for two years, the editor of DYMO says =
sorry for the "long delay", and begin to address the comments.=20
Plus, the main efforts from the parked dymo-21 to the current revision, =
is to be "compatible" with LOADng.=20

Ulrich has made very good arguments on LOADng, with running code wide =
industry support.=20

On the other hand, DYMO (AODVv2) is taking the design of LOADng to be =
"compatible", even when the LOADng authors have explicitly expressed =
that they don't appreciate that.=20

Maybe it's because I'm so young and so naive that I still believe =
"running code is the king" in IETF, I don't get the logic why we should =
force a sophisticated and active document adapt to the one that has been =
slept for two years.=20
btw, I have read the latest DYMO revision in detail. A general comments =
here for DYMO-23 is that, a proof reading is needed first. There are =
numerous inconsistency in the document:  terminologies, using =
nonexistent fields ... even duplicated paragraphs (section 5.5.2). =20

The arguments that made for DYMO are:

1) DYMO had been the WG document
	=3D=3D> true. Actually, it has been there for long time (and can =
be WG document even forever), but the history told us that this can't =
help the document evolving.=20

2) DYMO is the result of years of work.
	=3D=3D> In the contrast, the current situation of reactive =
protocol in MANET is the result of years of *NO* work on DYMO. IF DYMO =
had taken the comments from the WG, when reviews were posted around =
Maastricht, and evolved rather than be dormant for years, then LOADng =
had not needed to exist.  But unfortunately, there is no magic time =
machine to bring us back to 2010.=20

Therefore, I would support WG chairs'  option 2) replace DYMO with =
LOADng, and strongly against 1) continue with DYMO: the DYMO editors =
have clearly shown that they couldn't or wouldn't evolve the =
specification according to feedback, and as there is an industrial need =
for a reactive protocol for some types of MANETs, we cannot keep sitting =
around doing nothing while waiting for a miracle.=20

best

Jiazi




On Oct 31, 2012, at 12:13 AM, Joseph Macker  wrote:

> Hello MANET working group (form Stan and Joe),
>=20
> As you are all probably aware, there has been WG activity lately on =
competing drafts for a MANET reactive protocol - DYMO (reviving the =
current working group document that was parked due to inactivity), and =
LOADng. Many months ago there was a somewhat authorship led movement =
towards a common document effort and given positive feedback at the time =
we the chairs thought this was the best approach given the authors =
potential to come together and gain the best of both efforts.  Since =
that period, there has been some fairly strident and rancorous "at =
times" debate between the authors of the two documents.
>=20
> During IETF 84 in Vancouver, the co-chairs held a discussion with some =
of the co-authors of the two documents. Our guidance to the co-authors =
was to find a way to merge the two documents into one, as it was =
perceived that are not technically far apart and they both derive =
roughly from AODV concepts and LOADng had fairly active authorship and =
implementation efforts. We provided a co-editing proposal to the authors =
and gave them the timeframe of the Atlanta to come up with an answer =
back to us regarding this.  As of this writing, those discussions of a =
potential commonn document and authorship merger have failed.
>=20
> Therefore, we find ourselves at a crossroads. The authors of the two =
documents are divided, and it is unlikely that progress on a merged =
document can be reached based upon recent author feedback. I have also =
polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat =
disengaged on the issue at the present time.  We see only 3 possible =
paths forward:
>=20
> 1. Continue the work on the DYMO document, starting with whether there =
is consensus on its continued approach and also the desire to rename it =
to AODVv2.
> 2. Replace the existing DYMO document effort with the LOADng related =
document effort, defusing ealier references to LLNs as recommended in =
the last meeting minutes, and to focus more motivationally on general =
MANET problem spaces (the authors seem to have agreed to this issue if =
its a WG document).
> 3. Remove the working group charter for a reactive protocol, =
effectively killing both documents, at least from a working group (WG) =
standpoint. This would not be a reflection on the technology in either =
case, just an admission that we are not working together and reaching =
consensus.
>=20
> The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author =
feedback at this point.  Stan and I are both on travel prior to Atlanta =
so our responses may be sparse and we will also likely be in a "receive =
mode" for a few days.  So send your opinions.
>=20
> -Joe
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_101BE71F-AADB-4239-A9F5-C3D098C1611F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Dear =
all, 





On Oct 31, 2012, at 1:08 AM, Ulrich Herberg wrote:




Timothy,






our company has deadlines for coming up with products on the market an=
d customers waiting. I believe that the same is true for other companies. W=
e had discussions for more than half a year now that did not lead anywhere.=










Note that IETF cannot be driven by company roadmap.











Regards


Ulrich




On Tue, Oct 30, 2012 at 4:51 PM, Timothy J. Salo=
 
<salo@saloits.com<=
/a>> wrote:







As you are all probably aware, there has been WG activity lately on

competing drafts for a MANET reactive protocol - DYMO (reviving the

current working group document that was parked due to inactivity), and

LOADng.







I suggest not excluding what might be considered a fourth possible

course of action, namely: wait.



Based on what I have read and seen during meetings, I am concerned that

a decision to select one document over the other may be driven by

personalities, rather than technical content, the ability of the

authors to work with the members of the working group, or a

commitment by the authors to complete the process.



Sometimes, simply deferring a decision permits things to sort

themselves out naturally, and avoids unnecessarily expending a lot of

time, energy, and perhaps even ill will by forcing a decision

prematurely.



I can't say that deferring a decision will necessarily make the best

future path obvious.  But, it seems that the cost of not deciding at
this time is probably small (perhaps beyond the cost of additional

heated, even acrimonious, emails, posturing and positioning).



Having said that, let me argue the contrary.  Sometimes, the best

course of action is decision-by-fiat (e.g., the working group chairs

direct a solution).  It is possible that either document and document<=
br>
authors would serve the working group equally well.  In this case, a
quick, mandated solution may permit the working group to focus its

energy on progressing the selected document.  This approach probably h=
as

a couple of requirements.  First, the authors of the selected document=


_must_ ensure that their document progresses to an RFC in a expeditious

manner.  Second, the selection process (e.g., working group chair

directive) must appear fair to all involved.  If all things really are=


equal, there is a lot to be said for a coin toss.



-tjs







_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet













_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet








Thanks Joe =
for briefing what had happened in the last several =
months. 
I really =
don't want to dig into the history, but as long as someone mentioned =
"results of years of work", I think those facts are clear with my short =
memory of MANET:
1. In IETF 87 =
Maastricht 2010, DYMO was "parked" because the editors "lost the =
passion" to continue the work, disregarding the comments made for dymo =
from the mailing list. 
2. After =
that, LOADng was born to meet real needs of the industry. Great efforts =
have been invested in the last two years, with hundreds iterations on =
the draft from ~10 authors, interop test, real implementations. Now with =
concrete results, interop report, mib document, =
etc. 
3. After the =
DYMO draft sleeping for two years, the editor of DYMO says sorry for the =
"long delay", and begin to address the =
comments. 
Plus, the main efforts from the parked =
dymo-21 to the current revision, is to be "compatible" with =
LOADng. 

Ulrich has made very good =
arguments on LOADng, with running code wide industry =
support. 

On the other hand, DYMO (AODVv2) =
is taking the design of LOADng to be "compatible", even when the LOADng =
authors have explicitly expressed that they don't appreciate =
that. 

Maybe it's because I'm so young and =
so naive that I still believe "running code is the king" in IETF, I =
don't get the logic why we should force a sophisticated and active =
document adapt to the one that has been slept for two =
years. 
btw, I have read the latest DYMO revision in =
detail. A general comments here for DYMO-23 is that, a proof reading is =
needed first. There are numerous inconsistency in the document: =
 terminologies, using nonexistent fields ... even duplicated =
paragraphs (section 5.5.2).  

The =
arguments that made for DYMO are:

1) DYMO had =
been the WG document
	=3D=3D> true. Actually, it has =
been there for long time (and can be WG document even forever), but the =
history told us that this can't help the document =
evolving. 

2) DYMO is the result of =
years of work.
	=3D=3D> In the contrast, the =
current situation of reactive protocol in MANET is the result of years =
of *NO* work on DYMO. IF DYMO had =
taken the comments from the WG, when reviews were posted around =
Maastricht, and evolved rather than be dormant for years, then LOADng =
had not needed to exist.  But unfortunately, there is =
no magic time machine to bring us back to =
2010. 

Therefore, I would support WG =
chairs'  option 2) replace DYMO with LOADng, and strongly =
against 1) continue with DYMO: =
the DYMO editors have clearly shown that they couldn't or wouldn't =
evolve the specification according to feedback, and as there is an =
industrial need for a reactive protocol for some types of MANETs, we =
cannot keep sitting around doing nothing while waiting for a =
miracle. 

best

Jiazi





On Oct 31, 2012, at 12:13 AM, Joseph Macker <jpmacker@gmail.com> =
wrote:

Hello MANET working group (form Stan and Joe),

As =
you are all probably aware, there has been WG activity lately on =
competing drafts for a MANET reactive protocol - DYMO (reviving the =
current working group document that was parked due to inactivity), and =
LOADng. Many months ago there was a somewhat authorship led movement =
towards a common document effort and given positive feedback at the time =
we the chairs thought this was the best approach given the authors =
potential to come together and gain the best of both efforts.  =
Since that period, there has been some fairly strident and rancorous "at =
times" debate between the authors of the two documents.


During IETF 84 in Vancouver, the co-chairs held a discussion with =
some of the co-authors of the two documents. Our guidance to the =
co-authors was to find a way to merge the two documents into one, as it =
was perceived that are not technically far apart and they both derive =
roughly from AODV concepts and LOADng had fairly active authorship and =
implementation efforts. We provided a co-editing proposal to the authors =
and gave them the timeframe of the Atlanta to come up with an answer =
back to us regarding this.  As of this writing, those discussions =
of a potential commonn document and authorship merger have failed.


Therefore, we find ourselves at a crossroads. The authors of the two =
documents are divided, and it is unlikely that progress on a merged =
document can be reached based upon recent author feedback. I have also =
polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat =
disengaged on the issue at the present time.  We see only 3 =
possible paths forward:


1. Continue the work on the DYMO document, starting with whether =
there is consensus on its continued approach and also the desire to =
rename it to AODVv2.
2. Replace the existing DYMO document effort =
with the LOADng related document effort, defusing ealier references to =
LLNs as recommended in the last meeting minutes, and to focus more =
motivationally on general MANET problem spaces (the authors seem to have =
agreed to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively =
killing both documents, at least from a working group (WG) standpoint. =
This would not be a reflection on the technology in either case, just an =
admission that we are not working together and reaching consensus.


The co-chairs request and need your opinions on the options.  =
We have been some silent collecting initial feedback and waiting for =
author feedback at this point.  Stan and I are both on travel prior =
to Atlanta so our responses may be sparse and we will also likely be in =
a "receive mode" for a few days.  So send your opinions.


-Joe

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

=

--Apple-Mail=_101BE71F-AADB-4239-A9F5-C3D098C1611F--

From c.chauvenet@watteco.com  Wed Oct 31 04:19:24 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4D221F86FC for ; Wed, 31 Oct 2012 04:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.932
X-Spam-Level: 
X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqZ5RByfqz+y for ; Wed, 31 Oct 2012 04:19:23 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96021F8732 for ; Wed, 31 Oct 2012 04:19:23 -0700 (PDT)
Received: from mail170-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 11:19:22 +0000
Received: from mail170-co1 (localhost [127.0.0.1])	by mail170-co1-R.bigfish.com (Postfix) with ESMTP id E6E6A6C0070; Wed, 31 Oct 2012 11:19:21 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: VPS-23(zz98dI9371Ic89bhc85dh1dbaIzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h)
Received: from mail170-co1 (localhost.localdomain [127.0.0.1]) by mail170-co1 (MessageSwitch) id 1351682359541768_27154; Wed, 31 Oct 2012 11:19:19 +0000 (UTC)
Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.232])	by mail170-co1.bigfish.com (Postfix) with ESMTP id 77DF9860110; Wed, 31 Oct 2012 11:19:19 +0000 (UTC)
Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 11:19:18 +0000
Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT003.eurprd05.prod.outlook.com ([10.255.67.166]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 11:19:18 +0000
From: C Chauvenet 
To: Jiazi YI 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvRAV6TKZOGU0EeXjdQ8Uxmd8pfTQCCAgAAFFwA=
Date: Wed, 31 Oct 2012 11:19:17 +0000
Message-ID: <97B69B30E0EF244B940B65EA541E3F2D2156D0E1@DBXPRD0510MB395.eurprd05.prod.outlook.com>
References:  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.42.4]
Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D2156D0E1DBXPRD0510MB395_"
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: MANET IETF 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 11:19:24 -0000

--_000_97B69B30E0EF244B940B65EA541E3F2D2156D0E1DBXPRD0510MB395_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Le 31 oct. 2012 =E0 12:01, Jiazi YI a =E9crit :

Dear all,

Thanks Joe for briefing what had happened in the last several months.

I really don't want to dig into the history, but as long as someone mention=
ed "results of years of work"

I take it for my own.
Thank you for participating.

Here is a copy of my arguments against option 2) :

C.C> Option 2), would annihilate years of previous work realized for DYMO i=
n the MANET WG.

I get your comment on that.

C.C> Again, I don't see a reason to discard it with a protocol that popped =
up in MANET 4 months ago. Moreover, the adoption of LOADng may add some mis=
understanding about the intend of such a protocol when readers will look at=
 its history. The initial name signification of "LOADng" is a good example,=
 and the last update of the protocol roughly search & replace "LLN" wording=
 by "MANET" as we can see here : http://tools.ietf.org/rfcdiff?url1=3Ddraft=
-clausen-lln-loadng-05.txt. I think such a confusion will not drive the fut=
ure of internet in a good direction, as JP mentioned. My fear is that it co=
uld create confusion and slow down both LLNs and MANET deployments.

What do you think about the rest of my argumentation ?
My "fear" about the confusion is stressed by the "need for a reactive proto=
col for some types of MANETs" that you just mentioned.

Regards,

C=E9dric.

, I think those facts are clear with my short memory of MANET:

1. In IETF 87 Maastricht 2010, DYMO was "parked" because the editors "lost =
the passion" to continue the work, disregarding the comments made for dymo =
from the mailing list.

2. After that, LOADng was born to meet real needs of the industry. Great ef=
forts have been invested in the last two years, with hundreds iterations on=
 the draft from ~10 authors, interop test, real implementations. Now with c=
oncrete results, interop report, mib document, etc.

3. After the DYMO draft sleeping for two years, the editor of DYMO says sor=
ry for the "long delay", and begin to address the comments.
Plus, the main efforts from the parked dymo-21 to the current revision, is =
to be "compatible" with LOADng.

Ulrich has made very good arguments on LOADng, with running code wide indus=
try support.

On the other hand, DYMO (AODVv2) is taking the design of LOADng to be "comp=
atible", even when the LOADng authors have explicitly expressed that they d=
on't appreciate that.

Maybe it's because I'm so young and so naive that I still believe "running =
code is the king" in IETF, I don't get the logic why we should force a soph=
isticated and active document adapt to the one that has been slept for two =
years.
btw, I have read the latest DYMO revision in detail. A general comments her=
e for DYMO-23 is that, a proof reading is needed first. There are numerous =
inconsistency in the document:  terminologies, using nonexistent fields ...=
 even duplicated paragraphs (section 5.5.2).

The arguments that made for DYMO are:

1) DYMO had been the WG document
=3D=3D> true. Actually, it has been there for long time (and can be WG docu=
ment even forever), but the history told us that this can't help the docume=
nt evolving.

2) DYMO is the result of years of work.
=3D=3D> In the contrast, the current situation of reactive protocol in MANE=
T is the result of years of *NO* work on DYMO. IF DYMO had taken the commen=
ts from the WG, when reviews were posted around Maastricht, and evolved rat=
her than be dormant for years, then LOADng had not needed to exist.  But un=
fortunately, there is no magic time machine to bring us back to 2010.

Therefore, I would support WG chairs'  option 2) replace DYMO with LOADng, =
and strongly against 1) continue with DYMO: the DYMO editors have clearly s=
hown that they couldn't or wouldn't evolve the specification according to f=
eedback, and as there is an industrial need for a reactive protocol for som=
e types of MANETs, we cannot keep sitting around doing nothing while waitin=
g for a miracle.

best

Jiazi




On Oct 31, 2012, at 12:13 AM, Joseph Macker > wrote:

Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

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


--_000_97B69B30E0EF244B940B65EA541E3F2D2156D0E1DBXPRD0510MB395_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <433AC6DA4845C7418145168D666C50F8@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






Hi, 






Le 31 oct. 2012 =E0 12:01, Jiazi YI a =E9crit :








Dear
 all, 







Thanks
 Joe for briefing what had happened in the last several months. 







I
 really don't want to dig into the history, but as long as someone mentione=
d "results of years of work"











I take it for my own.


Thank you for participating.







Here is a copy of my arguments against option 2) : 







C.C> Option 2), would annihilate years of previous work real=
ized for DYMO in the MANET WG. 







I get your comment on that. 







C.C> Again, I don't see a reason to discard it with a protocol that=
 popped up in MANET 4 months ago. Moreover, the adoption of LOADng may add =
some misunderstanding about the intend of such a protocol when readers will=
 look at its history. The initial name
 signification of "LOADng" is a good example, and the last update=
 of the protocol roughly search & replace "LLN" wording by &q=
uot;MANET" as we can see here : http://tools.ietf.org/rfcdi=
ff?url1=3Ddraft-clausen-lln-loadng-05.txt.
 I think such a confusion will not drive the future of internet in a good d=
irection, as JP mentioned. My fear is that it could create confusion and sl=
ow down both LLNs and MANET deployments. 







What do you think about the rest of my argumentation ?


My "fear" about the confusion is stressed by the "need for a reactive=
 protocol for
some types of MANETs" that you just mentioned.







Regards,







C=E9dric.








,
 I think those facts are clear with my short memory of MANET:







1.
 In IETF 87 Maastricht 2010, DYMO was "parked" because the e=
ditors "lost the passion" to continue the work, disregarding the =
comments made for dymo from the mailing list. 







2.
 After that, LOADng was born to meet real needs of the industry. Great effo=
rts have been invested in the last two years, with hundreds iterations on t=
he draft from ~10 authors, interop test, real implementations. Now with con=
crete results, interop report, mib
 document, etc. 







3.
 After the DYMO draft sleeping for two years, the editor of DYMO says sorry=
 for the "long delay", and begin to address the comments. 


Plus, the main efforts from the parked dymo-21 to the current revision=
, is to be "compatible" with LOADng. 







Ulrich has made very good arguments on LOADng, with running code wide =
industry support. 







On the other hand, DYMO (AODVv2) is taking the design of LOADng to be =
"compatible", even when the LOADng authors have explicitly expres=
sed that they don't appreciate that. 







Maybe it's because I'm so young and so naive that I still believe &quo=
t;running code is the king" in IETF, I don't get the logic why we shou=
ld force a sophisticated and active document adapt to the one that has been=
 slept for two years. 


btw, I have read the latest DYMO revision in detail. A general comment=
s here for DYMO-23 is that, a proof reading is needed first. There are nume=
rous inconsistency in the document:  terminologies, using nonexistent =
fields ... even duplicated paragraphs
 (section 5.5.2).  







The arguments that made for DYMO are:







1) DYMO had been the WG document


=3D=3D=
> true. Actually, it has been there for long time (and can be WG documen=
t even forever), but the history told us that this can't help the document =
evolving. 







2) DYMO is the result of years of work.


=3D=3D=
> In the contrast, the current situation of reactive protocol in MANET i=
s the result of years of *NO* work on DYMO. IF DYMO had taken the comments from the WG,
 when reviews were posted around Maastricht, and evolved rather than be dor=
mant for years, then LOADng had not needed to exist.  But =
unfortunately, there is no magic time machine to bring us back to 2010.&nbs=
p;







Therefore, I would support WG chairs'  option 2) replace DYMO wit=
h LOADng, and strongly against 1) co=
ntinue with DYMO: the DYMO editors have clearly shown that they couldn't or=
 wouldn't evolve the specification according
 to feedback, and as there is an industrial need for a reactive protocol fo=
r some types of MANETs, we cannot keep sitting around doing nothing while w=
aiting for a miracle. 







best







Jiazi




























On Oct 31, 2012, at 12:13 AM, Joseph Macker <jpmacker@gmail.com> wrote:




Hello MANET working group (form Stan and Joe),


As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.or=
g/mailman/listinfo/manet









_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet












--_000_97B69B30E0EF244B940B65EA541E3F2D2156D0E1DBXPRD0510MB395_--

From A.Hardy@2009.ljmu.ac.uk  Wed Oct 31 05:45:50 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF55E21F89D8 for ; Wed, 31 Oct 2012 05:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxon89B8UxYo for ; Wed, 31 Oct 2012 05:45:50 -0700 (PDT)
Received: from EXHUBCAS2.jmu.ac.uk (exhubcas2.jmu.ac.uk [150.204.215.11]) by ietfa.amsl.com (Postfix) with ESMTP id 848D521F8928 for ; Wed, 31 Oct 2012 05:45:46 -0700 (PDT)
Received: from EXHUBCAS0.jmu.ac.uk (150.204.55.21) by EXHUBCAS2.jmu.ac.uk (150.204.215.11) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 31 Oct 2012 12:45:44 +0000
Received: from [192.168.1.66] (87.194.103.86) by smtp.ljmu.ac.uk (150.204.55.28) with Microsoft SMTP Server (TLS) id 14.1.421.2; Wed, 31 Oct 2012 12:45:41 +0000
Message-ID: <50911D76.1040602@2009.ljmu.ac.uk>
Date: Wed, 31 Oct 2012 12:45:42 +0000
From: Andrew Hardy 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [87.194.103.86]
Subject: [manet] AODV RFC - Interpretation of in which cases one may choose "local repair"
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: a.hardy@2009.ljmu.ac.uk
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 12:45:50 -0000

I am a student researcher and part of my work means I need to look at AODV.

I have been given an interpretation by an implementer of the
circumstance under which "local repair" may be appropriate and I am
having difficulty reconciling this with the RFC.
This interpretation says that, if chosen to be turned on, "local repair"
will be actioned if a line break occurs for ANY kind of packet,
including RREP, RERR and so on and NOT JUST for 'data' packets.

Therefore, for example, in the case of a line break for a RREP, if local
repair is configured, the RREP is buffered and a RREQ for the original
RREQ originator node is issued.  If this latest RREQ results in a RREP
arriving back at the node which encountered the line break then the
buffered RREP is unicast again, but if such a RREP does not arrive back
then the the node which encountered the line break for the RREP it was
trying to send, sends a RERR back on the precursors towards the
destination of the original RREQ, i.e. the originator of the RREP.

If find this difficult to reconcile with the RFC and I will do my best
to explain why

1)
Under local repair the text regarding buffering the text explicitly says
'data' packets are buffered.  Perhaps implying not other packets.

2)
RERRs are sent on the precursor.  I had thought that precursors by
definition were created from the next hop forwarding node of each RREP,
in which case there would be no precursors in the direction of the
destination of the original RREQ at the node with the line break on
sending the RREP.  The last sentence of 6.7 may have something to say
against this but I  am finding that piece hard to understand.

3)
Regarding 2) even if a RERR IS issued following failed forwarding of a
RREP, this RERR will arrive back at the destination of the original RREQ
and I can find no instructions that say a destination will reissue a
RREP on receipt of a RERR.

4)
6.12 'Local Repair' begins "when a line break ocurrs in an 'active'
route...", I am thinking that the the route the RREP is about to be
forwarded on is, though valid, not actually an 'active' route and so
"local Repair" does not apply.
When a RREP is processed the route to the destination (i.e. the
destination requested by the originating RREQ) is marked as 'active'.
However there seems to be nothing to say that the route to originator on
which the RREP is next forwarded is marked as active before forwarding
and nothing in the processing of RREQs to say that the route to the
originator is marked as active, so I am assuming that this reverse route
TO the originator is NOT an active route.

5)
6.7 describes forwarding of RREP and refers to 6.8 which describes
possible actions if a RREP fails.  If "local repair" were an option for
failed RREPs, one might expect some reference to it here, but there is not.

6)
Finally perhaps I am misreading the RFC, but informally it doesn't seem
obvious to me from the RFC that "local repair" may be chosen for failed
RREP, RERR, RREP_ACK and so on.  Anecdotally, using the implementation
in question, I have a network which has high density and high path loss
and some congestion from time to time.  With local repair turned off
occasionally a route requested is repeated, but with local repair turned
on, one failed RREP seems to snow ball into more and more congestion.

Perhaps part of the confusion arises out of the fact that in some
implementations the destination can use the reverse route (to the
originator of the original route requested) for the purpose of sending
data.  However I don't see where this route is 'marked as active',
unless active is not a mark/flag, but is simply a 'valid' route which
has an in time active_route_timeout.  If this is the case, then perhaps
the reverse route used by the RREP IS active and therefore "local
repair" does apply to RREPs, but some how, intuitively, it doesn't seem
right.

I hope this has made some sense.  Any guidance would be gratefully received=
.

Thank you


________________________________
Important Notice: the information in this email and any attachments is for =
the sole use of the intended recipient(s). If you are not an intended recip=
ient, or a person responsible for delivering it to an intended recipient, y=
ou should delete it from your system immediately without disclosing its con=
tents elsewhere and advise the sender by returning the email or by telephon=
ing a number contained in the body of the email. No responsibility is accep=
ted for loss or damage arising from viruses or changes made to this message=
 after it was sent. The views contained in this email are those of the auth=
or and not necessarily those of Liverpool John Moores University.

From Chris.Dearlove@baesystems.com  Wed Oct 31 06:30:58 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D31521F84BD for ; Wed, 31 Oct 2012 06:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpVVqw918-6F for ; Wed, 31 Oct 2012 06:30:56 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B87D321F87A4 for ; Wed, 31 Oct 2012 06:30:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600";  d="scan'208,217";a="282567056"
Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Oct 2012 13:30:55 +0000
Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VDUsJH021098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 13:30:54 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 13:30:53 +0000
From: "Dearlove, Christopher (UK)" 
To: C Chauvenet , Jiazi YI 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfTQCCAgAAFGICAACJuIA==
Date: Wed, 31 Oct 2012 13:30:54 +0000
Message-ID: 
References:   <97B69B30E0EF244B940B65EA541E3F2D2156D0E1@DBXPRD0510MB395.eurprd05.prod.outlook.com>
In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D2156D0E1@DBXPRD0510MB395.eurprd05.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4233GLKXM0002VGREEN_"
MIME-Version: 1.0
Cc: MANET IETF 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 13:30:58 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4233GLKXM0002VGREEN_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

How much previous work (by anyone) is negated is not the point; that is the=
 sunk cost (aka Concorde) fallacy.

The technical question is how much effort to get from where we are, regardl=
ess of how we got here, and where we would get to (how good it the final so=
lution will be). If two approaches got to the same point by spending differ=
ent amounts of effort, how much effort was spent by each is not the point. =
Whether they really are at the same point would be.

Of course it's not that simple, and there are matters of people, companies,=
 etc. that matter in practice. (I would consider issues like running code t=
o be part of the how much effort to get where we want to go issue.)

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C=
 Chauvenet
Sent: 31 October 2012 11:19
To: Jiazi YI
Cc: MANET IETF
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Hi,

Le 31 oct. 2012 =E0 12:01, Jiazi YI a =E9crit :


Dear all,


Thanks Joe for briefing what had happened in the last several months.


I really don't want to dig into the history, but as long as someone mention=
ed "results of years of work"

I take it for my own.
Thank you for participating.

Here is a copy of my arguments against option 2) :

C.C> Option 2), would annihilate years of previous work realized for DYMO i=
n the MANET WG.

I get your comment on that.

C.C> Again, I don't see a reason to discard it with a protocol that popped =
up in MANET 4 months ago. Moreover, the adoption of LOADng may add some mis=
understanding about the intend of such a protocol when readers will look at=
 its history. The initial name signification of "LOADng" is a good example,=
 and the last update of the protocol roughly search & replace "LLN" wording=
 by "MANET" as we can see here : http://tools.ietf.org/rfcdiff?url1=3Ddraft=
-clausen-lln-loadng-05.txt. I think such a confusion will not drive the fut=
ure of internet in a good direction, as JP mentioned. My fear is that it co=
uld create confusion and slow down both LLNs and MANET deployments.

What do you think about the rest of my argumentation ?
My "fear" about the confusion is stressed by the "need for a reactive proto=
col for some types of MANETs" that you just mentioned.

Regards,

C=E9dric.


, I think those facts are clear with my short memory of MANET:


1. In IETF 87 Maastricht 2010, DYMO was "parked" because the editors "lost =
the passion" to continue the work, disregarding the comments made for dymo =
from the mailing list.


2. After that, LOADng was born to meet real needs of the industry. Great ef=
forts have been invested in the last two years, with hundreds iterations on=
 the draft from ~10 authors, interop test, real implementations. Now with c=
oncrete results, interop report, mib document, etc.


3. After the DYMO draft sleeping for two years, the editor of DYMO says sor=
ry for the "long delay", and begin to address the comments.
Plus, the main efforts from the parked dymo-21 to the current revision, is =
to be "compatible" with LOADng.

Ulrich has made very good arguments on LOADng, with running code wide indus=
try support.

On the other hand, DYMO (AODVv2) is taking the design of LOADng to be "comp=
atible", even when the LOADng authors have explicitly expressed that they d=
on't appreciate that.

Maybe it's because I'm so young and so naive that I still believe "running =
code is the king" in IETF, I don't get the logic why we should force a soph=
isticated and active document adapt to the one that has been slept for two =
years.
btw, I have read the latest DYMO revision in detail. A general comments her=
e for DYMO-23 is that, a proof reading is needed first. There are numerous =
inconsistency in the document:  terminologies, using nonexistent fields ...=
 even duplicated paragraphs (section 5.5.2).

The arguments that made for DYMO are:

1) DYMO had been the WG document
=3D=3D> true. Actually, it has been there for long time (and can be WG docu=
ment even forever), but the history told us that this can't help the docume=
nt evolving.

2) DYMO is the result of years of work.
=3D=3D> In the contrast, the current situation of reactive protocol in MANE=
T is the result of years of *NO* work on DYMO. IF DYMO had taken the commen=
ts from the WG, when reviews were posted around Maastricht, and evolved rat=
her than be dormant for years, then LOADng had not needed to exist.  But un=
fortunately, there is no magic time machine to bring us back to 2010.

Therefore, I would support WG chairs'  option 2) replace DYMO with LOADng, =
and strongly against 1) continue with DYMO: the DYMO editors have clearly s=
hown that they couldn't or wouldn't evolve the specification according to f=
eedback, and as there is an industrial need for a reactive protocol for som=
e types of MANETs, we cannot keep sitting around doing nothing while waitin=
g for a miracle.

best

Jiazi




On Oct 31, 2012, at 12:13 AM, Joseph Macker > wrote:


Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

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


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


--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4233GLKXM0002VGREEN_
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable











How much previous work (b=
y anyone) is negated is not the point; that is the sunk cost (aka Concorde)=
 fallacy.


 <=
/p>

The technical question is=
 how much effort to get from where we are, regardless of how we got here, a=
nd where we would get to (how good it the final solution
 will be). If two approaches got to the same point by spending different am=
ounts of effort, how much effort was spent by each is not the point. Whethe=
r they really are at the same point would be.


 <=
/p>

Of course it's not that s=
imple, and there are matters of people, companies, etc. that matter in prac=
tice. (I would consider issues like running code to be part
 of the how much effort to get where we want to go issue.)


 <=
/p>



chris.dearlove@baesystems.com
 | http://www.baesystems.com



BAE Systems (O=
perations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687




 <=
/p>





From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org=
]
On Behalf Of C Chauvenet

Sent: 31 October 2012 11:19

To: Jiazi YI

Cc: MANET IETF

Subject: Re: [manet] Reactive Protocol Situation





 




 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see 
this process on how to deal with suspicious emails.<=
/i>






Hi,  




 






Le 31 oct. 2012 =E0 12:01, Jiazi YI a =E9crit :=
















Dear=
 all, 

















Than=
ks Joe for briefing what had happened in the last several months. 

















I re=
ally don't want to dig into the history, but as long as someone mentioned &=
quot;results of years of work"








 






I take it for my own.






Thank you for participating.






 






Here is a copy of my arguments against option 2) :&n=
bsp;






 






C.C> Option 2), would annihilate years of prev=
ious work realized for DYMO in the MANET WG. 






 






I get your comment on that. 






 






C.C> Again, I don't see a reason to discard it wi=
th a protocol that popped up in MANET 4 months ago. Moreover, the adoption =
of LOADng may add some misunderstanding about the intend of such a protocol=
 when readers will look at its history.
 The initial name signification of "LOADng" is a good example, an=
d the last update of the protocol roughly search & replace "LLN&qu=
ot; wording by "MANET" as we can see here : http://too=
ls.ietf.org/rfcdiff?url1=3Ddraft-clausen-lln-loadng-05.txt.
 I think such a confusion will not drive the future of internet in a good d=
irection, as JP mentioned. My fear is that it could create confusion and sl=
ow down both LLNs and MANET deployments. 






 






What do you think about the rest of my argumentation=
 ?






My "fear" about the confusion is stressed =
by the "need for a reactive protocol for
some types of MANETs" that you just mentioned.






 






Regards,






 






C=E9dric.















, I =
think those facts are clear with my short memory of MANET:

















1. I=
n IETF 87 Maastricht 2010, DYMO was "parked" because the edi=
tors "lost the passion" to continue the work, disregarding the co=
mments made
 for dymo from the mailing list. 

















2. A=
fter that, LOADng was born to meet real needs of the industry. Great effort=
s have been invested in the last two years, with hundreds
 iterations on the draft from ~10 authors, interop test, real implementatio=
ns. Now with concrete results, interop report, mib document, etc. 

















3. A=
fter the DYMO draft sleeping for two years, the editor of DYMO says sorry f=
or the "long delay", and begin to address the comments. 






Plus, the main efforts from the parked dymo-21 to th=
e current revision, is to be "compatible" with LOADng. =







 






Ulrich has made very good arguments on LOADng, with =
running code wide industry support. 






 






On the other hand, DYMO (AODVv2) is taking the desig=
n of LOADng to be "compatible", even when the LOADng authors have=
 explicitly expressed that they don't appreciate that. 






 






Maybe it's because I'm so young and so naive that I =
still believe "running code is the king" in IETF, I don't get the=
 logic why we should force a sophisticated and active document adapt to the=
 one that has been slept for two years. 






btw, I have read the latest DYMO revision in detail.=
 A general comments here for DYMO-23 is that, a proof reading is needed fir=
st. There are numerous inconsistency in the document:  terminologies, =
using nonexistent fields ... even duplicated
 paragraphs (section 5.5.2).  






 






The arguments that made for DYMO are:






 






1) DYMO had been the WG document






=3D=3D> true. Actually, it has been there for lon=
g time (and can be WG document even forever), but the history told us that =
this can't help the document evolving. 






 






2) DYMO is the result of years of work.






=3D=3D> In the contrast, the current situation of=
 reactive protocol in MANET is the result of years of *NO* work on DYMO.&nb=
sp;IF DYMO had taken the comments from the =
WG, when reviews were posted around Maastricht,
 and evolved rather than be dormant for years, then LOADng had not needed t=
o exist.  But unfortunately, there is no magic time machin=
e to bring us back to 2010. 






 






Therefore, I would support WG chairs'  option 2=
) replace DYMO with LOADng, and strongly against 1) continue with DYMO: the DYMO editors have clearly shown that =
they couldn't or wouldn't evolve the specification
 according to feedback, and as there is an industrial need for a reactive p=
rotocol for some types of MANETs, we cannot keep sitting around doing nothi=
ng while waiting for a miracle. 






 






best






 






Jiazi












 

















 






On Oct 31, 2012, at 12:13 AM, Joseph Macker <jpmacker@gmail.com> wrote:











Hello MANET working group (form Stan and Joe),



As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.or=
g/mailman/listinfo/manet




 




_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet




 





 

********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************






--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4233GLKXM0002VGREEN_--

From jvasseur@cisco.com  Wed Oct 31 07:02:59 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9435F21F84B2 for ; Wed, 31 Oct 2012 07:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA2Affyu2Udk for ; Wed, 31 Oct 2012 07:02:58 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E204521F849D for ; Wed, 31 Oct 2012 07:02:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27841; q=dns/txt; s=iport; t=1351692178; x=1352901778; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u+1Zdqzd/XMHPnn+RjBB+bh7cgFmWhYz2JcM+hWeWLQ=; b=ETCD4J1p/bjkeGsAihk883W30oQb2+ikEdnIw/hsr8G8ttyqdypNX9/k vdIO5KiMJqWFziQL7sH66D6LzVJkMeEm3XqDNwrmXs0Y0e3kMkWVK2iyt +AOVrjZzCwLIDK4p1nY9q2xTWLQnDvI9CatAvdGo2GMoHSkbjRYF0FN3X A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8FAF4ukVCtJXHA/2dsb2JhbABEgkm4I4kAgQiCHgEBAQICAQEBDwFCFwIDBQMQAgEIEQQBAQsWBwcnCxQJCAIEDgUIEweHZAucBqAPi3gSAg6FOGEDlxCNPYFrgm+BWwkXHg
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200";  d="scan'208,217";a="137340932"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 31 Oct 2012 14:02:57 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9VE2uqq016558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 14:02:56 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 09:02:56 -0500
From: "JP Vasseur (jvasseur)" 
To: "Dearlove, Christopher (UK)" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0HGLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 14:02:55 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com>
References:  <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.147.19.15]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--53.002800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722042AFBxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 14:02:59 -0000

--_000_03B78081B371D44390ED6E7BADBB4A7722042AFBxmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Completely agreeing with you. 1) with some work needed, as agreed by Charli=
e.

JP.

On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher (UK) wrote:

As someone who has not (yet) stated an opinion on the matter, except I also=
 think option 3 is not good, I would very much like to hear technical argum=
ents, so if you have technical arguments against LOADng, I think we need to=
 hear them rather than just suggesting they exist. I haven't yet read LOADn=
g carefully to form a view there. I have just recently read the AODVv2 draf=
t carefully, and have some technical issues there (which overlap) regarding=
 asymmetric links, possible dependency on NHDP, and the compatibility of op=
tions. If option 1 is followed, the draft needs work (which Charlie has ack=
nowledged).

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-b=
ounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: >
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Dear chairs,

Remembering that I am not a co-authors of either of these drafts.

Not commenting on recent discussions but rather focussing on what I hope wi=
ll be a good solution for the WG and the Internet at large.

Option 3) is my opinion not desirable; I wish we could have a reactive rout=
ing protocol for MANET

Option 2) is an option I would be strongly opposed to for a number of techn=
ical reasons that I would be happy to elaborate on the
mailing list and/or in a new I-D (which I would, should option 2 be chosen)=
.

That being said, I am extremely supportive of option 1), especially in ligh=
t of what Charlie said. First of all DYMO is the working group
document and excellent progress has been made with recent revisions. But ev=
en more importantly, Charlie managed to make it compatible
with options, which is in my opinion the best of both worlds; calling it AO=
DVv2 is only not very sensible but avoids useful sensitivity around
names.

Thus I would strongly support Option 1), continue the work that Charlie has=
 started, which by the way is not far from completion. And
as WG,we need to remember that this had been the WG document, the result of=
 years of work. Still by making it compatible with other options,
this is technically flexible and sound.

Thanks.

JP.

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:


Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


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



--_000_03B78081B371D44390ED6E7BADBB4A7722042AFBxmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Completely agreeing with you. 1) with some work needed, as agreed by Charli=
e.






JP.







On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher (UK) wrote:











As someone who has not (yet) stated an opinion on the mat=
ter, except I also think option 3 is not good, I would very much like to he=
ar technical arguments, so if you
 have technical arguments against LOADng, I think we need to hear them rath=
er than just suggesting they exist. I haven't yet read LOADng carefully to =
form a view there. I have just recently read the AODVv2 draft carefully, an=
d have some technical issues there
 (which overlap) regarding asymmetric links, possible dependency on NHDP, a=
nd the compatibility of options. If option 1 is followed, the draft needs w=
ork (which Charlie has acknowledged).



 





--



Christopher Dearlove



Senior Principal Engineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124



chris.dearlove@baesystems.com<=
span class=3D"Apple-converted-space"> | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687





 







From:&nbs=
p;manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On
 Behalf Of JP Vasseur=
 (jvasseur)

Sent: 31 October 2=
012 08:29

To: Joseph Macker<=
br>
Cc: <manet@ietf.org>

Subject: Re: [mane=
t] Reactive Protocol Situation







 





 <=
/o:p>





*** WARNING ***







This message originates from outside our organisation=
, either from an external partner or the internet.

Keep this in mind if y=
ou answer this message.

Please see this
 process on how to de=
al with suspicious emails.







Dear chairs,





 







Remembering that I am not a co-authors of either of these drafts.





 







Not commenting on recent discussions but rather focussing on what I hope=
 will be a good solution for the WG and the Internet at large.







 







Option 3) is my opinion <=
b>not desirabl=
e; I wish we could have a reactive routing protocol for MANET






 







Option 2) is an option I would be&nbs=
p;strongly =
opposed to for a number of technical reasons that I would be happy t=
o elaborate on the







mailing list and/or in a new I-D (which I would, should option 2 be chosen)=
.







 







That being said, I am =
extremely supportive of option 1), especially in light of what Charlie said. First of all=
 DYMO is the working group







document and excellent progress has been made with recent revisions. But ev=
en more importantly, Charlie managed to make it compatible =








with options, which is in my opinion the best of both worlds; calling it AODVv2 is only =
not very sensible but avoids useful sensitivity around 






names.







 







Thus I would strongly support Option 1), continue the work that Charlie =
has started, which by the way is not far from completion. And 







as WG,we need to remember that this had been the WG document, the result of=
 years of work. Still by making it compatible with other options, 







this is technically flexible and sound.







 







Thanks.







 







JP.







 







On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:













Hello MANET working group (form Stan and Joe),



As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/mane=
t





 









********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************
















--_000_03B78081B371D44390ED6E7BADBB4A7722042AFBxmbrcdx02ciscoc_--

From thierry.lys@erdfdistribution.fr  Wed Oct 31 07:53:41 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3B121F851E for ; Wed, 31 Oct 2012 07:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.834
X-Spam-Level: 
X-Spam-Status: No, score=-7.834 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AYZpko8ucHD for ; Wed, 31 Oct 2012 07:53:41 -0700 (PDT)
Received: from mtagate3.edf.fr (mtagate3.edf.fr [192.196.142.11]) by ietfa.amsl.com (Postfix) with ESMTP id AB3DB21F851C for ; Wed, 31 Oct 2012 07:53:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344204000"; d="scan'208";a="131265654"
Received: from unknown (HELO XHUB003BU.notes.edfgdf.fr) ([192.196.9.98]) by PCYF1MTA3.edf.fr with ESMTP; 31 Oct 2012 15:40:09 +0100
To: manet@ietf.org
MIME-Version: 1.0
X-KeepSent: 7B8B8379:803B0FA3-C1257AA8:005169BA; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 7.0.2 HF1260 October 14, 2008
From: Thierry LYS 
Message-ID: 
Date: Wed, 31 Oct 2012 15:53:36 +0100
Content-Type: multipart/alternative; boundary="=_alternative 0051CE7DC1257AA8_="
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 14:53:41 -0000

Message en plusieurs parties au format MIME
--=_alternative 0051CE7DC1257AA8_=
Content-Type: text/plain; charset="US-ASCII"

Hi Joe,

I speak in the name of EDF group. 

We started first to use LOAD as a routing algorithm and deployed 2000 
PLC-meters for smart grid purposes in 2011. Taking advantage of this field 
test, we have been actively participating to the working group to adopt 
enhancements in the LOADng specification.
We are now extremely pleased with what LOADng is capable of and are 
confident that future deployements will be equipped with it.

"We believe in rough consensus and running code"

rough consensus : Don't you think we have a rough consensus on LOADng 
compared to DYMO ? 10 authors and major companies are supporters of 
LOADng. 

running code : interoperability has been checked with 4 sources and other 
implementations are in progress.

We hope that IETF will realize how urgent and promising is the market for 
the smart grid.
So to answer your question : We opt for answer 2 !

Best regards,

Thierry Lys (ERDF, EDF Group)
and Cedric Lavenu (EDF R&D, EDF Group)
--=_alternative 0051CE7DC1257AA8_=
Content-Type: text/html; charset="US-ASCII"



Hi Joe,



I speak in the name of EDF group. 



We started first to use LOAD as a routing
algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.
Taking advantage of this field test, we have been actively participating
to the working group to adopt enhancements in the LOADng specification.

We are now extremely pleased with what
LOADng is capable of and are confident that future deployements will be
equipped with it.



"We believe in rough consensus
and running code"



rough consensus : Don't you think we
have a rough consensus on LOADng compared to DYMO ? 10 authors and major
companies are supporters of LOADng. 



running code : interoperability has
been checked with 4 sources and other implementations are in progress.



We hope that IETF will realize how urgent
and promising is the market for the smart grid.

So to answer your question : We opt
for answer 2 !



Best regards,



Thierry Lys (ERDF, EDF Group)

and Cedric Lavenu (EDF R&D, EDF
Group)
--=_alternative 0051CE7DC1257AA8_=--

From Chris.Dearlove@baesystems.com  Wed Oct 31 08:11:44 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5F721F88FE for ; Wed, 31 Oct 2012 08:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.298
X-Spam-Level: 
X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1xD9o375uxe for ; Wed, 31 Oct 2012 08:11:42 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B322C21F8818 for ; Wed, 31 Oct 2012 08:11:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600";  d="scan'208,217";a="282609909"
Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Oct 2012 15:11:34 +0000
Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VFBYkB029691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 15:11:34 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 15:11:32 +0000
From: "Dearlove, Christopher (UK)" 
To: "JP Vasseur (jvasseur)" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfTFaOAgAAYXXCAAETwgIAAEoRA
Date: Wed, 31 Oct 2012 15:11:33 +0000
Message-ID: 
References:  <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42DCGLKXM0002VGREEN_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 15:11:44 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42DCGLKXM0002VGREEN_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I take it those are two separate sentences. You can agree with me, and you =
can support 1. But you can't agree with me supporting 1, as I haven't (nor =
have I supported 2).

As indicated, I would like to hear the technical arguments you have against=
 LOADng. Here on list would seem the best place.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
Sent: 31 October 2012 14:03
To: Dearlove, Christopher (UK)
Cc: Joseph Macker; 
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Completely agreeing with you. 1) with some work needed, as agreed by Charli=
e.

JP.

On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher (UK) wrote:


As someone who has not (yet) stated an opinion on the matter, except I also=
 think option 3 is not good, I would very much like to hear technical argum=
ents, so if you have technical arguments against LOADng, I think we need to=
 hear them rather than just suggesting they exist. I haven't yet read LOADn=
g carefully to form a view there. I have just recently read the AODVv2 draf=
t carefully, and have some technical issues there (which overlap) regarding=
 asymmetric links, possible dependency on NHDP, and the compatibility of op=
tions. If option 1 is followed, the draft needs work (which Charlie has ack=
nowledged).

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-b=
ounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: >
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Dear chairs,

Remembering that I am not a co-authors of either of these drafts.

Not commenting on recent discussions but rather focussing on what I hope wi=
ll be a good solution for the WG and the Internet at large.

Option 3) is my opinion not desirable; I wish we could have a reactive rout=
ing protocol for MANET

Option 2) is an option I would be strongly opposed to for a number of techn=
ical reasons that I would be happy to elaborate on the
mailing list and/or in a new I-D (which I would, should option 2 be chosen)=
.

That being said, I am extremely supportive of option 1), especially in ligh=
t of what Charlie said. First of all DYMO is the working group
document and excellent progress has been made with recent revisions. But ev=
en more importantly, Charlie managed to make it compatible
with options, which is in my opinion the best of both worlds; calling it AO=
DVv2 is only not very sensible but avoids useful sensitivity around
names.

Thus I would strongly support Option 1), continue the work that Charlie has=
 started, which by the way is not far from completion. And
as WG,we need to remember that this had been the WG document, the result of=
 years of work. Still by making it compatible with other options,
this is technically flexible and sound.

Thanks.

JP.

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:



Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


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


--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42DCGLKXM0002VGREEN_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I take it those are two s=
eparate sentences. You can agree with me, and you can support 1. But you ca=
n't agree with me supporting 1, as I haven't (nor have I
 supported 2).


 <=
/p>

As indicated, I would lik=
e to hear the technical arguments you have against LOADng. Here on list wou=
ld seem the best place.


 <=
/p>



chris.dearlove@baesystems.com
 | http://www.baesystems.com



BAE Systems (O=
perations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687




 <=
/p>





From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]


Sent: 31 October 2012 14:03

To: Dearlove, Christopher (UK)

Cc: Joseph Macker; <manet@ietf.org>

Subject: Re: [manet] Reactive Protocol Situation





 




 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see 
this process on how to deal with suspicious emails.<=
/i>






Completely agreeing with you. 1) with some work need=
ed, as agreed by Charlie.





 






JP.






 






On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher =
(UK) wrote:















As someone who has not (y=
et) stated an opinion on the matter, except I also think option 3 is not go=
od, I would very much like to hear technical arguments,
 so if you have technical arguments against LOADng, I think we need to hear=
 them rather than just suggesting they exist. I haven't yet read LOADng car=
efully to form a view there. I have just recently read the AODVv2 draft car=
efully, and have some technical
 issues there (which overlap) regarding asymmetric links, possible dependen=
cy on NHDP, and the compatibility of options. If option 1 is followed, the =
draft needs work (which Charlie has acknowledged).






 <=
/p>







--






Christopher Dearlove






Senior Principal Engineer=
, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124<=
/o:p>






=
chris.dearlove@baesystems.com | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687








 <=
/p>









From: ma=
net-bounces@ietf.org =
[mailto:manet-bounces@ietf.org] =
On
 Behalf Of JP Vasseur=
 (jvasseur)

Sent: 31 October 2=
012 08:29

To: Joseph Macker<=
br>
Cc: <manet@ietf.org>

Subject: Re: [mane=
t] Reactive Protocol Situation










 






 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see =
this
 process =
on=
 how to deal with suspicious emails.








Dear chairs,








 










Remembering that I am not a co-authors of either of =
these drafts.








 










Not commenting on recent discussions but rather f=
ocussing on what I hope will be a good solution for the WG and the Internet=
 at large.










 










Option 3) is my opinion not desirable; I wish we could have a reactive routing protocol =
for MANET










 










Option 2) is an option I would be strongly opposed to for a number of technical reasons =
that I would be happy to elaborate on the










mailing list and/or in a new I-D (which I would, sho=
uld option 2 be chosen).










 










That being said, I am extremely supportive of option 1), especially in light of what Charlie=
 said. First of all DYMO is the working group










document and excellent progress has been made with r=
ecent revisions. But even more importantly, Charlie managed to make it comp=
atible 










with options, which is in my opinion the best of both worlds; cal=
ling it AODVv2 is only not very sensible but avoids useful sensitivity arou=
nd 










names.










 










Thus I would strongly support Option 1), continue=
 the work that Charlie has started, which by the way is not far from co=
mpletion. And 










as WG,we need to remember that this had been the WG =
document, the result of years of work. Still by making it compatible with o=
ther options, 










this is technically flexible and sound.









 










Thanks.










 










JP.










 










On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:





















Hello MANET working group (form Stan and Joe),



As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.or=
g/mailman/listinfo/manet








 










********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************






 








--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42DCGLKXM0002VGREEN_--

From Chris.Dearlove@baesystems.com  Wed Oct 31 08:15:52 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161121F8829 for ; Wed, 31 Oct 2012 08:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.548
X-Spam-Level: 
X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uHrErD56xx6 for ; Wed, 31 Oct 2012 08:15:51 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF521F881F for ; Wed, 31 Oct 2012 08:15:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600";  d="scan'208,217";a="282612224"
Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Oct 2012 15:15:48 +0000
Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VFFmoh032459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 15:15:48 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 15:15:47 +0000
From: "Dearlove, Christopher (UK)" 
To: Thierry LYS , "manet@ietf.org" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt3eBKZyE8G8hv0Kl9ZhEgIu1eJfThTrA
Date: Wed, 31 Oct 2012 15:15:47 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42F5GLKXM0002VGREEN_"
MIME-Version: 1.0
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 15:15:52 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42F5GLKXM0002VGREEN_
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

While I would like there to be rough consensus one way or the other, I've seen significant numbers of people taking each of the two sides (I don't think 3 is getting much traction) and, while of course I am just one participant with an opinion (which does not yet extend to coming down on one side or the other) that opinion is that I would consider claiming a consensus existed either way as premature.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Thierry LYS
Sent: 31 October 2012 14:54
To: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Hi Joe,

I speak in the name of EDF group.

We started first to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantage of this field test, we have been actively participating to the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what LOADng is capable of and are confident that future deployements will be equipped with it.

"We believe in rough consensus and running code"

rough consensus : Don't you think we have a rough consensus on LOADng compared to DYMO ? 10 authors and major companies are supporters of LOADng.

running code : interoperability has been checked with 4 sources and other implementations are in progress.

We hope that IETF will realize how urgent and promising is the market for the smart grid.
So to answer your question : We opt for answer 2 !

Best regards,

Thierry Lys (ERDF, EDF Group)
and Cedric Lavenu (EDF R&D, EDF Group)

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


--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42F5GLKXM0002VGREEN_
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit











While I would like there to be rough consensus one way or the other, I've seen significant numbers of people taking each of the two sides (I don't think 3 is
 getting much traction) and, while of course I am just one participant with an opinion (which does not yet extend to coming down on one side or the other) that opinion is that I would consider claiming a consensus existed either way as premature.


 


--



Christopher Dearlove


Senior Principal Engineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124


chris.dearlove@baesystems.com
 | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687


 


From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]
On Behalf Of Thierry LYS

Sent: 31 October 2012 14:54

To: manet@ietf.org

Subject: Re: [manet] Reactive Protocol Situation


 




 




*** WARNING ***







This message originates from outside our organisation, either from an external partner or the internet.

Keep this in mind if you answer this message.

Please see 
this process on how to deal with suspicious emails.








Hi Joe, 



I speak in the name of EDF group.




We started first to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantage of this field test, we have been actively participating to the
 working group to adopt enhancements in the LOADng specification. 

We are now extremely pleased with what LOADng is capable of and are confident that future deployements will be equipped with it.




"We believe in rough consensus and running code"




rough consensus : Don't you think we have a rough consensus on LOADng compared to DYMO ? 10 authors and major companies are supporters of LOADng.




running code : interoperability has been checked with 4 sources and other implementations are in progress.




We hope that IETF will realize how urgent and promising is the market for the smart grid.


So to answer your question : We opt for answer 2 !




Best regards,




Thierry Lys (ERDF, EDF Group)


and Cedric Lavenu (EDF R&D, EDF Group)



 

********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************






--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB42F5GLKXM0002VGREEN_--

From ulrich@herberg.name  Wed Oct 31 08:25:06 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA1E21F8230 for ; Wed, 31 Oct 2012 08:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.126
X-Spam-Level: 
X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=1.077,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57uUvJ039vYG for ; Wed, 31 Oct 2012 08:25:05 -0700 (PDT)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDAB421F8498 for ; Wed, 31 Oct 2012 08:25:05 -0700 (PDT)
Received: by mail-da0-f44.google.com with SMTP id h15so693433dan.31 for ; Wed, 31 Oct 2012 08:25:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=JmSBX5bgQpBeDQDMXfzlPhgB7wTv7TlCBrCHeVxGTMc=; b=0nnUebOzW2hrdWd6j8TZWiNTBtwwq0NlAPpew8SeyEgqVpPRFptUDUQdCLEpqPHhqZ smtXMQmTzBDCXX1ACx0omm11GMDBxR/NH2bBYDjmH2gXn8FfmGP2xu3tzONVzxAyTf0A /3/zpfoNdGdyxqiRgrBzdjdSOmNPfDq2PwHoQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=JmSBX5bgQpBeDQDMXfzlPhgB7wTv7TlCBrCHeVxGTMc=; b=J2otq0XgAS4ciWhMVsVpx+ACdnP2SJ/mkPkRozODmregEyV8jT+IpkZKVQtgU8Iyeu U+ckpM/N2VJGgdkbEZbhwJsv9xC4MAp4URABbXgPHUP8qaAN5Q9rM2t2G/x78NwbeEcH iPy0v8B2dXx5AwayX7SPmgJsLeYueNCQssNSQ4iqIovW3PkDF8SIeIhY9xOrbA1ezlqE Ij5gDLMqc/sKkcNxlUFBnwbd/mNiCGqnt2grJhY5VVP1H0CEGn+UnWuuGOdJELxDOPcR IbxIACIS2qW3nW+z8ctPXtvti0T/90leCkHy+mOAkGlIYtpuRKTsXrAOmzz96I6CBZ9q mLWw==
Received: by 10.66.75.74 with SMTP id a10mr103065172paw.46.1351697105258; Wed, 31 Oct 2012 08:25:05 -0700 (PDT)
Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id mt15sm2438989pbc.49.2012.10.31.08.25.03 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 08:25:04 -0700 (PDT)
References:  <50906802.9070904@saloits.com>  <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: 
X-Mailer: iPad Mail (10A403)
From: Ulrich Herberg 
Date: Wed, 31 Oct 2012 08:25:02 -0700
To: "JP Vasseur (jvasseur)" 
X-Gm-Message-State: ALoCoQk7OYxFUbUnYaSoNSeOtaRlIfBG7f/tlG5+BkePmqDnzqnM8ZsHVQbJfy3o7mcWCEjHf6UQ
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 15:25:06 -0000

Hi JP,
>=20
> Note that IETF cannot be driven by company roadmap.

Then please let me hear your technical arguments. So far, you have been only=
 saying that one protocol is in a "GREAT" shape, the other is not, and I bel=
ieve it is no secret that Cisco also has a company roadmap in this space.

Best
Ulrich=

From john.dowdell@cassidian.com  Wed Oct 31 08:56:12 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7CC21F872A for ; Wed, 31 Oct 2012 08:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG6FtMd5VSou for ; Wed, 31 Oct 2012 08:56:12 -0700 (PDT)
Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 91B3C21F87AC for ; Wed, 31 Oct 2012 08:56:09 -0700 (PDT)
Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 31 Oct 2012 16:56:04 +0100
Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381);  Wed, 31 Oct 2012 16:56:06 +0100
Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 31 Oct 2012 16:56:03 +0100
Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 31 Oct 2012 16:56:03 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDB780.246A10E8"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 31 Oct 2012 15:56:02 -0000
Message-ID: <1B40484159234F4FB6FE11D4C2F408DE01FFC29A@SUKNPT8108.cogent-dsn.local>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: Ac23d5nPIAtsSDAjToGvf5vCSc61xAABsFmQ
References: 
From: "Dowdell, John" 
To: "Thierry LYS" , 
X-OriginalArrivalTime: 31 Oct 2012 15:56:03.0195 (UTC) FILETIME=[3AB06CB0:01CDB780]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19326.000
X-TM-AS-Result: No--16.666100-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 15:56:13 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CDB780.246A10E8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thierry

=20

While I am very pleased for you and your co-authors that the LOADng work
has been so fruitful, I am not really sure that smart meters are really
the kind of MANET devices that the working group was intended to
address. I have been party to the conversations for only a year or two,
so I am very happy to be corrected by those with longer histories, but
MANET to me means dynamically moving nodes, with links being established
and broken often and without prior warning. Examples may be
communications networks built out of nodes contained in cars, trucks and
aircraft of all sizes. I appreciate a comment on the list a while back
that the RF environment for smart metering is actually more difficult
than one would think, but I would suggest to the chairs that unless
LOADng has applications in this dynamically mobile environment (and I
have to admit I have not read the spec in enough detail to determine if
this is the case), then we come to the conclusion that the DYMO/AODVv2
path should be followed unless we collectively feel that such a
direction is not worth pursuing (and note I am definitely not proposing
that view).

=20

In the two years or so that I have been working with MANETs, the only
conclusion I have come to is that very many use cases exist, and that
one size does not fit all.

=20

Regards

=20

John

________________________________

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
Of Thierry LYS
Sent: 31 October 2012 14:54
To: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation

=20


Hi Joe,=20

I speak in the name of EDF group.=20

We started first to use LOAD as a routing algorithm and deployed 2000
PLC-meters for smart grid purposes in 2011. Taking advantage of this
field test, we have been actively participating to the working group to
adopt enhancements in the LOADng specification.=20
We are now extremely pleased with what LOADng is capable of and are
confident that future deployements will be equipped with it.=20

"We believe in rough consensus and running code"=20

rough consensus : Don't you think we have a rough consensus on LOADng
compared to DYMO ? 10 authors and major companies are supporters of
LOADng.=20

running code : interoperability has been checked with 4 sources and
other implementations are in progress.=20

We hope that IETF will realize how urgent and promising is the market
for the smart grid.=20
So to answer your question : We opt for answer 2 !=20

Best regards,=20

Thierry Lys (ERDF, EDF Group)=20
and Cedric Lavenu (EDF R&D, EDF Group)


------_=_NextPart_001_01CDB780.246A10E8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















Thierry
=



 



While I am very pleased for you and =
your
co-authors that the LOADng work has been so fruitful, I am not really =
sure that
smart meters are really the kind of MANET devices that the working group =
was
intended to address. I have been party to the conversations for only a =
year or two,
so I am very happy to be corrected by those with longer histories, but =
MANET to
me means dynamically moving nodes, with links being established and =
broken often
and without prior warning. Examples may be communications networks built =
out of
nodes contained in cars, trucks and aircraft of all sizes. I appreciate =
a
comment on the list a while back that the RF environment for smart =
metering is
actually more difficult than one would think, but I would suggest to the =
chairs
that unless LOADng has applications in this dynamically mobile =
environment (and
I have to admit I have not read the spec in enough detail to determine =
if this
is the case), then we come to the conclusion that the DYMO/AODVv2 path =
should
be followed unless we collectively feel that such a direction is not =
worth
pursuing (and note I am definitely not proposing that =
view).



 



In the two years or so that I have =
been
working with MANETs, the only conclusion I have come to is that very =
many use
cases exist, and that one size does not fit =
all.



 



Regards
=



 






John


















From:
manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Thierry LYS

Sent: 31 October 2012 =
14:54

To: manet@ietf.org

Subject: Re: [manet] =
Reactive
Protocol Situation






 





Hi Joe, 



I
speak in the name of EDF group. 



We
started first to use LOAD as a routing algorithm and deployed 2000 =
PLC-meters
for smart grid purposes in 2011. Taking advantage of this field test, we =
have
been actively participating to the working group to adopt enhancements =
in the
LOADng specification. 

We
are now extremely pleased with what LOADng is capable of and are =
confident that
future deployements will be equipped with it. 



"We
believe in rough consensus and running code" 



rough
consensus : Don't you think we have a rough consensus on LOADng compared =
to
DYMO ? 10 authors and major companies are supporters of LOADng. =




running
code : interoperability has been checked with 4 sources and other
implementations are in progress. 



We
hope that IETF will realize how urgent and promising is the market for =
the
smart grid. 

So
to answer your question : We opt for answer 2 ! 



Best
regards, 



Thierry
Lys (ERDF, EDF Group) 

and
Cedric Lavenu (EDF R&D, EDF Group)









------_=_NextPart_001_01CDB780.246A10E8--

From jvasseur@cisco.com  Wed Oct 31 09:36:55 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0951721F85A9 for ; Wed, 31 Oct 2012 09:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.221
X-Spam-Level: 
X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnw7ICZDiyjo for ; Wed, 31 Oct 2012 09:36:54 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E927921F8567 for ; Wed, 31 Oct 2012 09:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5245; q=dns/txt; s=iport; t=1351701414; x=1352911014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hmpyeFC00GtedHdCfPN7cdFFWtEG6foK22d5cUlq0mw=; b=em867Nj0ywDAfHkKPqb0z1Wqfknhj/TsjGYREiXlUPj4CjvyPkevKvQq +GlRU8vt5j2FMXVNDYUjXgc2kF1c8RNkbrELwe9xtc0DkTVV8qiC8O2f9 bSqCX8VmcVwaz9TxKMduJK4OFhqdeliYO4hHURFt5zoJ/gVtYq+jYc8vZ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFADNSkVCtJXG8/2dsb2JhbABEw3CBCIIeAQEBAwEBAQEPAUIZAwgFBwQCAQgRBAEBAQodBycLFAkIAgQOAwIIEweHXgYLnEugFYt4EgIOhThhA4glnCiBa4JvP4EcCRce
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137183721"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2012 16:36:53 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGarvh023338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:36:53 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:36:52 -0500
From: "JP Vasseur (jvasseur)" 
To: "Dearlove, Christopher (UK)" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt4XuLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 16:36:52 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77220448F7@xmb-rcd-x02.cisco.com>
References:  <50906802.9070904@saloits.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--56.288500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Timothy J. Salo" , " List" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 16:36:55 -0000

On Oct 31, 2012, at 11:16 AM, Dearlove, Christopher (UK) wrote:

> The ROLL WG participants who have been posting here have made it very cle=
ar that they see LLNs as a distinct area, and have strongly resisted more g=
eneral purpose MANET routing protocols claiming applicability in LLNs. (I d=
on't actually agree with that, but that's not my point here.) To reverse th=
at and say the ROLL WG should now be responsible for a general purpose reac=
tive routing protocol is clearly incompatible with that.

You are correct - the ROLLWG is not responsible for general reactive protoc=
ol by any means. We are chartered for one protocol for LLN, which is RFC655=
0.

Thanks.

JP.

>=20
> --=20
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>=20
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre=
, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>=20
>=20
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of=
 Bo Berry
> Sent: 31 October 2012 00:12
> To: Joseph Macker; Stan Ratliff (sratliff);  List; Timoth=
y J. Salo
> Subject: Re: [manet] Reactive Protocol Situation
>=20
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
> Joe, Stan
> Adding to Tim's option.
>=20
> If the MANET WG removes reactive from the charter, is there similar techn=
ology in another WG?  Perhaps ROLL?  If so this may be another option as th=
ere is a lot of synergy-commonality.
>=20
> -Bo
>=20
>=20
> On Oct 30, 2012, at 7:51 PM, Timothy J. Salo wrote:
>=20
>>> As you are all probably aware, there has been WG activity lately on
>>> competing drafts for a MANET reactive protocol - DYMO (reviving the
>>> current working group document that was parked due to inactivity), and
>>> LOADng.
>>=20
>> I suggest not excluding what might be considered a fourth possible
>> course of action, namely: wait.
>>=20
>> Based on what I have read and seen during meetings, I am concerned that
>> a decision to select one document over the other may be driven by
>> personalities, rather than technical content, the ability of the
>> authors to work with the members of the working group, or a
>> commitment by the authors to complete the process.
>>=20
>> Sometimes, simply deferring a decision permits things to sort
>> themselves out naturally, and avoids unnecessarily expending a lot of
>> time, energy, and perhaps even ill will by forcing a decision
>> prematurely.
>>=20
>> I can't say that deferring a decision will necessarily make the best
>> future path obvious.  But, it seems that the cost of not deciding at
>> this time is probably small (perhaps beyond the cost of additional
>> heated, even acrimonious, emails, posturing and positioning).
>>=20
>> Having said that, let me argue the contrary.  Sometimes, the best
>> course of action is decision-by-fiat (e.g., the working group chairs
>> direct a solution).  It is possible that either document and document
>> authors would serve the working group equally well.  In this case, a
>> quick, mandated solution may permit the working group to focus its
>> energy on progressing the selected document.  This approach probably has
>> a couple of requirements.  First, the authors of the selected document
>> _must_ ensure that their document progresses to an RFC in a expeditious
>> manner.  Second, the selection process (e.g., working group chair
>> directive) must appear fair to all involved.  If all things really are
>> equal, there is a lot to be said for a coin toss.
>>=20
>> -tjs
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>=20
>=20
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From jvasseur@cisco.com  Wed Oct 31 09:39:40 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B5021F86E2 for ; Wed, 31 Oct 2012 09:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.315
X-Spam-Level: 
X-Spam-Status: No, score=-10.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7hspzyAIQO5 for ; Wed, 31 Oct 2012 09:39:39 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 08C5B21F8524 for ; Wed, 31 Oct 2012 09:39:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14834; q=dns/txt; s=iport; t=1351701572; x=1352911172; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/MWYrSdaJVZnX/dAExNUuQWdgUZ0IdRt0LJfnbEQuLA=; b=ZNSXeNYQLWB94dPWa+Clvn42HQv6czWIR/R9rOUgUIu5Se0U/6KlDQfc ejpInBE7OgD72qkYyWeprPxFueBOFiz4EoObyV0ouQ/QHBcLPU5GUAxp1 bB7zlTjIjsfaYQyv2GkYUw7ywmBgwXiUKUZuDTtQOPYw2+EKzRdoV0oaF E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAGRTkVCtJXG8/2dsb2JhbABEgknBJ4EIgh8BAQQBAQEPAVkCCAMQAgEIIh0HIQYLFBECBA4FCBMHh1IDDwucS5Y0DYlQBIsRZxKFSGEDiCWLfI0GgyaBa4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200";  d="scan'208,217";a="137447687"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 31 Oct 2012 16:39:31 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGdVwI026010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:39:31 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:39:31 -0500
From: "JP Vasseur (jvasseur)" 
To: Jiazi YI 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt4ZMLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 16:39:30 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A772204490C@xmb-rcd-x02.cisco.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--22.666600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204490Cxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 16:39:41 -0000

--_000_03B78081B371D44390ED6E7BADBB4A772204490Cxmbrcdx02ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[snip]


On the other hand, DYMO (AODVv2) is taking the design of LOADng to be "comp=
atible", even when the LOADng authors have explicitly expressed that they d=
on't appreciate that.

JP> Not sure to understand why - Isn't it the right for the Internet anyhow=
 ?


Maybe it's because I'm so young and so naive that I still believe "running =
code is the king" in IETF, I don't get the logic why we should force a soph=
isticated and active document adapt to the one that has been slept for two =
years.
btw, I have read the latest DYMO revision in detail. A general comments her=
e for DYMO-23 is that, a proof reading is needed first. There are numerous =
inconsistency in the document:  terminologies, using nonexistent fields ...=
 even duplicated paragraphs (section 5.5.2).

The arguments that made for DYMO are:

1) DYMO had been the WG document
=3D=3D> true. Actually, it has been there for long time (and can be WG docu=
ment even forever), but the history told us that this can't help the docume=
nt evolving.

2) DYMO is the result of years of work.
=3D=3D> In the contrast, the current situation of reactive protocol in MANE=
T is the result of years of *NO* work on DYMO. IF DYMO had taken the commen=
ts from the WG, when reviews were posted around Maastricht, and evolved rat=
her than be dormant for years, then LOADng had not needed to exist.  But un=
fortunately, there is no magic time machine to bring us back to 2010.

Therefore, I would support WG chairs'  option 2) replace DYMO with LOADng, =
and strongly against 1) continue with DYMO: the DYMO editors have clearly s=
hown that they couldn't or wouldn't evolve the specification according to f=
eedback, and as there is an industrial need for a reactive protocol for som=
e types of MANETs, we cannot keep sitting around doing nothing while waitin=
g for a miracle.

JP> we all agree that we need to close on this work and that there is still=
 work with both solutions.


best

Jiazi




On Oct 31, 2012, at 12:13 AM, Joseph Macker > wrote:

Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

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


--_000_03B78081B371D44390ED6E7BADBB4A772204490Cxmbrcdx02ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <77E58A6FD5A5F943AB9A993A15E7AB51@cisco.com>
Content-Transfer-Encoding: quoted-printable






[snip]

















On the other hand, DYMO (AODVv2) is taking the design of LOADng to be =
"compatible", even when the LOADng authors have explicitly expres=
sed that they don't appreciate that. 











JP> Not sure to understand why - Isn't it the right for the Interne=
t anyhow ?













Maybe it's because I'm so young and so naive that I still believe &quo=
t;running code is the king" in IETF, I don't get the logic why we shou=
ld force a sophisticated and active document adapt to the one that has been=
 slept for two years. 


btw, I have read the latest DYMO revision in detail. A general comment=
s here for DYMO-23 is that, a proof reading is needed first. There are nume=
rous inconsistency in the document:  terminologies, using nonexistent =
fields ... even duplicated paragraphs
 (section 5.5.2).  







The arguments that made for DYMO are:







1) DYMO had been the WG document


=3D=3D=
> true. Actually, it has been there for long time (and can be WG documen=
t even forever), but the history told us that this can't help the document =
evolving. 







2) DYMO is the result of years of work.


=3D=3D=
> In the contrast, the current situation of reactive protocol in MANET i=
s the result of years of *NO* work on DYMO. IF DYMO had taken the comments from the WG,
 when reviews were posted around Maastricht, and evolved rather than be dor=
mant for years, then LOADng had not needed to exist.  But =
unfortunately, there is no magic time machine to bring us back to 2010.&nbs=
p;







Therefore, I would support WG chairs'  option 2) replace DYMO wit=
h LOADng, and strongly against 1) co=
ntinue with DYMO: the DYMO editors have clearly shown that they couldn't or=
 wouldn't evolve the specification according
 to feedback, and as there is an industrial need for a reactive protocol fo=
r some types of MANETs, we cannot keep sitting around doing nothing while w=
aiting for a miracle. 











JP> we all agree that we need to close on this work and that there =
is still work with both solutions.













best







Jiazi




























On Oct 31, 2012, at 12:13 AM, Joseph Macker <jpmacker@gmail.com> wrote:




Hello MANET working group (form Stan and Joe),


As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.or=
g/mailman/listinfo/manet









_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet














--_000_03B78081B371D44390ED6E7BADBB4A772204490Cxmbrcdx02ciscoc_--

From jvasseur@cisco.com  Wed Oct 31 09:45:10 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E929221F85BB for ; Wed, 31 Oct 2012 09:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.372
X-Spam-Level: 
X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbypX-roS5LE for ; Wed, 31 Oct 2012 09:45:09 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0B21F8472 for ; Wed, 31 Oct 2012 09:45:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4783; q=dns/txt; s=iport; t=1351701908; x=1352911508; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=flkkfmy6bDLno8bTexQ9Am+1Bu82oIZGkVaAMQkYjoE=; b=FD+KAaomi1Bew0CHWLvK7cx0njfoIFAaXSJh+DeJtDPbzYmLvNGMPRbK PkDMnVKuZr0f/jDim1Zc9H5WSgaFHFXOVPjcJOilgVm7JvRxy5ZaKhd62 7JDooZZ+IhsTJjcwZ1IlcmBSnGgn3y9LpafKctcig0z9Pgu95/Ke2J+zy 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAMZUkVCtJXHB/2dsb2JhbABEw3CBCIIfAQEEAQEBDwFbCxACAQgEHh0HJwsUEQIEDgUIGodkC5xLoBQEi3iFWmEDpE2Ba4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200";  d="scan'208,217";a="137384313"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2012 16:45:08 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGj8sR024282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:45:08 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:45:07 -0500
From: "JP Vasseur (jvasseur)" 
To: Thierry LYS 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt4cVLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 16:45:07 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722044983@xmb-rcd-x02.cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--29.453700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722044983xmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 16:45:10 -0000

--_000_03B78081B371D44390ED6E7BADBB4A7722044983xmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

On Oct 31, 2012, at 3:53 PM, Thierry LYS wrote:


Hi Joe,

I speak in the name of EDF group.


JP> Note that we are all individuals at the IETF though.

We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m=
eters for smart grid purposes in 2011. Taking advantage of this field test,=
 we have been actively participating to the working group to adopt enhancem=
ents in the LOADng specification.
We are now extremely pleased with what LOADng is capable of and are confide=
nt that future deployements will be equipped with it.

"We believe in rough consensus and running code"

JP> Fully Agree Thierry.


rough consensus : Don't you think we have a rough consensus on LOADng compa=
red to DYMO ? 10 authors and major companies are supporters of LOADng.


JP> Well let's see what the chairs think of course. Having all authors of L=
oad-NG supporting it was expected though.

running code : interoperability has been checked with 4 sources and other i=
mplementations are in progress.

JP> This is very important, but true for both.


We hope that IETF will realize how urgent and promising is the market for t=
he smart grid.
So to answer your question : We opt for answer 2 !

Best regards,

Thierry Lys (ERDF, EDF Group)
and Cedric Lavenu (EDF R&D, EDF Group)_____________________________________=
__________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A7722044983xmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <580C36E21D3CE744A8B2B6C0FAAF240E@cisco.com>
Content-Transfer-Encoding: quoted-printable






Hi,






On Oct 31, 2012, at 3:53 PM, Thierry LYS wrote:






Hi Joe, 



I speak in the name of EDF group. 











JP> Note that we are all individuals at the IETF though.




We started f=
irst to use LOAD as a routing algorithm and deployed 2000 PLC-meters for sm=
art grid purposes in 2011. Taking advantage of this field test, we have bee=
n actively participating to the working
 group to adopt enhancements in the LOADng specification. 

We are now extremely pleased with what=
 LOADng is capable of and are confident that future deployements will be eq=
uipped with it.




"We believe in rough consensus an=
d running code"










JP> Fully Agree Thierry.






rough consensus : Don't you think we h=
ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com=
panies are supporters of LOADng.












JP> Well let's see what the chairs think of course. Having all auth=
ors of Load-NG supporting it was expected though.




running code=
 : interoperability has been checked with 4 sources and other implementatio=
ns are in progress.










JP> This is very important, but true for both.






We hope that IETF will realize how urg=
ent and promising is the market for the smart grid.


So to answer your question : We opt fo=
r answer 2 !




Best regards, 



Thierry Lys (ERDF, EDF Group) <=
br>
and Cedric Lavenu (EDF R&D, EDF Gr=
oup)_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet












--_000_03B78081B371D44390ED6E7BADBB4A7722044983xmbrcdx02ciscoc_--

From jvasseur@cisco.com  Wed Oct 31 09:47:49 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A755421F86EB for ; Wed, 31 Oct 2012 09:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.109
X-Spam-Level: 
X-Spam-Status: No, score=-10.109 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI67oPe6kju0 for ; Wed, 31 Oct 2012 09:47:48 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AE24421F84A9 for ; Wed, 31 Oct 2012 09:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42128; q=dns/txt; s=iport; t=1351702067; x=1352911667; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VcVsbRmur0wCQlemRWKrOZewD/LEf28IaWHak40iO68=; b=HL58tfdUbHB5h/rfqSU+Abz5lLR/ZoBnKui49GdtuwIMZesU2pzx1TZ5 qjwIvgOckBLrVVqDGggqm+Pn8IA7uZ33LoLw6eEVVTI0OSGNp/B2YjVue ebShG2f+p4kue4o50Lc/uTWUMSuNV216qaN1JO0hYAace9FLmrZpV6sSk A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8FALdVkVCtJXG9/2dsb2JhbABEgkm4J4kAgQiCHgEBAQICAQEBDwFCFwIDBQMQAgEIEQQBAQsWAQYHJwsUCQgCBA4FCBMHh2QLnFOgGIt4EgIOhThhA5cQjT2Ba4JvgVsJFx4
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200";  d="scan'208,217";a="137450883"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 31 Oct 2012 16:47:47 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGlkWV026336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:47:46 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:47:29 -0500
From: "JP Vasseur (jvasseur)" 
To: "Dearlove, Christopher (UK)" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0HGLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 16:47:29 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com>
References:  <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--54.686100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220449D8xmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 16:47:49 -0000

--_000_03B78081B371D44390ED6E7BADBB4A77220449D8xmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


On Oct 31, 2012, at 4:11 PM, Dearlove, Christopher (UK) wrote:

I take it those are two separate sentences. You can agree with me, and you =
can support 1. But you can't agree with me supporting 1, as I haven't (nor =
have I supported 2).


I was agreeing on the fact that there was work to be done. Still strongly a=
dvocating for the option1, especially since Charlie is
working to make compatibility.

As indicated, I would like to hear the technical arguments you have against=
 LOADng. Here on list would seem the best place.


I am more than happy to share lots of results showing why LOAD-ng may be a =
severe issue for LLNs, since this was mentioned
as a clear use cases in the LOAD-ng document.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
Sent: 31 October 2012 14:03
To: Dearlove, Christopher (UK)
Cc: Joseph Macker; >
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Completely agreeing with you. 1) with some work needed, as agreed by Charli=
e.

JP.

On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher (UK) wrote:


As someone who has not (yet) stated an opinion on the matter, except I also=
 think option 3 is not good, I would very much like to hear technical argum=
ents, so if you have technical arguments against LOADng, I think we need to=
 hear them rather than just suggesting they exist. I haven't yet read LOADn=
g carefully to form a view there. I have just recently read the AODVv2 draf=
t carefully, and have some technical issues there (which overlap) regarding=
 asymmetric links, possible dependency on NHDP, and the compatibility of op=
tions. If option 1 is followed, the draft needs work (which Charlie has ack=
nowledged).

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-b=
ounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: >
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Dear chairs,

Remembering that I am not a co-authors of either of these drafts.

Not commenting on recent discussions but rather focussing on what I hope wi=
ll be a good solution for the WG and the Internet at large.

Option 3) is my opinion not desirable; I wish we could have a reactive rout=
ing protocol for MANET

Option 2) is an option I would be strongly opposed to for a number of techn=
ical reasons that I would be happy to elaborate on the
mailing list and/or in a new I-D (which I would, should option 2 be chosen)=
.

That being said, I am extremely supportive of option 1), especially in ligh=
t of what Charlie said. First of all DYMO is the working group
document and excellent progress has been made with recent revisions. But ev=
en more importantly, Charlie managed to make it compatible
with options, which is in my opinion the best of both worlds; calling it AO=
DVv2 is only not very sensible but avoids useful sensitivity around
names.

Thus I would strongly support Option 1), continue the work that Charlie has=
 started, which by the way is not far from completion. And
as WG,we need to remember that this had been the WG document, the result of=
 years of work. Still by making it compatible with other options,
this is technically flexible and sound.

Thanks.

JP.

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:



Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


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



--_000_03B78081B371D44390ED6E7BADBB4A77220449D8xmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable












On Oct 31, 2012, at 4:11 PM, Dearlove, Christopher (UK) wrote:











I take it those are two separate sentences. You can agree=
 with me, and you can support 1. But you can't agree with me supporting 1, =
as I haven't (nor have I supported
 2).



 













I was agreeing on the fact that there was work to be done. Still stron=
gly advocating for the option1, especially since Charlie is


working to make compatibility.











As indicated, I would like to hear the technical argument=
s you have against LOADng. Here on list would seem the best place.



 













I am more than happy to share lots of results showing why LOAD-ng may =
be a severe issue for LLNs, since this was mentioned


as a clear use cases in the LOAD-ng document.













--



Christopher Dearlove



Senior Principal Engineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124



chris.dearlove@baesystems.com<=
span class=3D"Apple-converted-space"> | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687





 







From:&nbs=
p;JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] 

Sent: 31 October 2=
012 14:03

To: Dearlove, Chri=
stopher (UK)

Cc: Joseph Macker;=
 <manet@ietf.org>

Subject: Re: [mane=
t] Reactive Protocol Situation







 





 <=
/o:p>





*** WARNING ***







This message originates from outside our organisation=
, either from an external partner or the internet.

Keep this in mind if y=
ou answer this message.

Please see this
 process on how to de=
al with suspicious emails.







Completely agreeing with you. 1) with some work needed, as agreed by Charli=
e.





 







JP.







 







On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher (UK) wrote:<=
/div>
















As someone who has not (yet) stated an opinion on the mat=
ter, except I also think option 3 is not good, I would very much like to he=
ar technical arguments, so if you
 have technical arguments against LOADng, I think we need to hear them rath=
er than just suggesting they exist. I haven't yet read LOADng carefully to =
form a view there. I have just recently read the AODVv2 draft carefully, an=
d have some technical issues there
 (which overlap) regarding asymmetric links, possible dependency on NHDP, a=
nd the compatibility of options. If option 1 is followed, the draft needs w=
ork (which Charlie has acknowledged).







 









--







Christopher Dearlove







Senior Principal Engineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124<=
/o:p>







chris.dearlove@baesystems.com<=
span class=3D"apple-converted-space"> | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687









 











From:&nb=
sp;manet-bounces@ietf.org [mailto:manet-bounces@ietf.org=
] On
 Behalf Of JP Vasseur=
 (jvasseur)

Sent: 31 October 2=
012 08:29

To: Joseph Macker<=
br>
Cc: <manet@ietf.org>

Subject: Re: [mane=
t] Reactive Protocol Situation











 







 





*** WARNING ***







This message originates from outside our organisation=
, either from an external partner or the internet.

Keep this in mind if y=
ou answer this message.

Please see=
 this
 process =
on how to deal with su=
spicious emails.









Dear chairs,









 











Remembering that I am not a co-authors of either of these drafts.









 











Not commenting on recent discussions but rather focussing on what I hope=
 will be a good solution for the WG and the Internet at large.











 











Option 3) is my opinion <=
b>not desirabl=
e; I wish we could have a reactive routing protocol for MANET










 











Option 2) is an option I would be&nbs=
p;strongly =
opposed to for a number of technical reasons that I would be happy t=
o elaborate on the











mailing list and/or in a new I-D (which I would, should option 2 be chosen)=
.











 











That being said, I am =
extremely supportive of option 1), especially in light of what Charlie said. First of all=
 DYMO is the working group











document and excellent progress has been made with recent revisions. But ev=
en more importantly, Charlie managed to make it compatible =












with options, which is in my opinion the best of both worlds; calling it AODVv2 is only =
not very sensible but avoids useful sensitivity around 










names.











 











Thus I would strongly support Option 1), continue the work that Charlie =
has started, which by the way is not far from completion. And 











as WG,we need to remember that this had been the WG document, the result of=
 years of work. Still by making it compatible with other options, 











this is technically flexible and sound.











 











Thanks.











 











JP.











 











On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:























Hello MANET working group (form Stan and Joe),



As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/mane=
t









 










********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************







 
















--_000_03B78081B371D44390ED6E7BADBB4A77220449D8xmbrcdx02ciscoc_--

From jvasseur@cisco.com  Wed Oct 31 09:49:39 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7050C21F88FB for ; Wed, 31 Oct 2012 09:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.394
X-Spam-Level: 
X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhjpPAMCycmD for ; Wed, 31 Oct 2012 09:49:39 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EC53721F88FA for ; Wed, 31 Oct 2012 09:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=813; q=dns/txt; s=iport; t=1351702179; x=1352911779; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AWAKJqxjI87prQkBhfgUYvNceWcEuZd7fvNilDAkF74=; b=LjBGmdIYjVXHZZmF+MCZw1x2uO/SggVZfC88LN7E0I/w5SCgzsdrkrmq xEnwhtKT284PxLKgqsGfRzkfFCnilpoUAQ1vznVndM+2uGCizSmmmTxwi aCGZrIQT71DpIvKLB3MoJDaLWSWafGEzXn2dtNCAjIpvO7VOn5euF9aej A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApAFALdVkVCtJV2c/2dsb2JhbABEhVC+IIEIgh4BAQEDAQEBAQ8BWwsFCwIBCCIkJwslAgQOBQgah14GC5xToBQEi3iFWmEDpE2Ba4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137188519"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2012 16:49:38 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGncNJ009561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:49:38 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:49:37 -0500
From: "JP Vasseur (jvasseur)" 
To: Ulrich Herberg 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0IiLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 16:49:36 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com>
References:  <50906802.9070904@saloits.com>  <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--37.935000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <712DAD3A0F7585408937EA661D217E3F@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 16:49:39 -0000

On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:

> Hi JP,
>>=20
>> Note that IETF cannot be driven by company roadmap.
>=20
> Then please let me hear your technical arguments. So far, you have been o=
nly saying that one protocol is in a "GREAT" shape, the other is not, and I=
 believe it is no secret that Cisco also has a company roadmap in this spac=
e.

Let's not go that route =85 this won't be productive. I am speaking as an i=
ndividual having spent years working on such issues
as many did too. What would you like ? Lots of experimental and simulation =
results showing why Load-NG will not work at
scale in LLN ?=20

>=20
> Best
> Ulrich
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From jvasseur@cisco.com  Wed Oct 31 09:50:37 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7EA21F87A5 for ; Wed, 31 Oct 2012 09:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.419
X-Spam-Level: 
X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sCpEeCRtepz for ; Wed, 31 Oct 2012 09:50:36 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1AA21F8795 for ; Wed, 31 Oct 2012 09:50:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14529; q=dns/txt; s=iport; t=1351702236; x=1352911836; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MMKG09N3PQppema/usjfwjFGZttD0+O+0y106eLmQYE=; b=aVad1dtW4ueRlfyafaQNwB+/xP2wMM+Fq6kXOAiXGf5n2mM1gRhGfiaD 7WmiR0OvKmJuuZxQiBv8IoCFbsaoHTWPaq/BkyDFHb/zbq9RosXTBSku+ i7xYHb8+Glic8KU0MvmZoZF6RBUYY8IbUV7gnJPxxIl+tBPu6wDAJmAxo k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFALdVkVCtJXHB/2dsb2JhbABEgknBJ4EIgh4BAQEEAQEBDwFbCxACAQgRBAEBCx0HJwsUCQgCBA4FCBqHZAucU6AUBIt4hVphA6RNgWuCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200";  d="scan'208,217";a="137451950"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 31 Oct 2012 16:50:35 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGoZSn029282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:50:35 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:50:35 -0500
From: "JP Vasseur (jvasseur)" 
To: "Dowdell, John" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt4fYLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 16:50:34 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722044A6D@xmb-rcd-x02.cisco.com>
References:  <1B40484159234F4FB6FE11D4C2F408DE01FFC29A@SUKNPT8108.cogent-dsn.local>
In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01FFC29A@SUKNPT8108.cogent-dsn.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--44.593100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722044A6Dxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" , Thierry LYS 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 16:50:37 -0000

--_000_03B78081B371D44390ED6E7BADBB4A7722044A6Dxmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Thierry,

I cannot agree more with you.

Thanks.

JP.

On Oct 31, 2012, at 4:56 PM, Dowdell, John wrote:

Thierry

While I am very pleased for you and your co-authors that the LOADng work ha=
s been so fruitful, I am not really sure that smart meters are really the k=
ind of MANET devices that the working group was intended to address. I have=
 been party to the conversations for only a year or two, so I am very happy=
 to be corrected by those with longer histories, but MANET to me means dyna=
mically moving nodes, with links being established and broken often and wit=
hout prior warning. Examples may be communications networks built out of no=
des contained in cars, trucks and aircraft of all sizes. I appreciate a com=
ment on the list a while back that the RF environment for smart metering is=
 actually more difficult than one would think, but I would suggest to the c=
hairs that unless LOADng has applications in this dynamically mobile enviro=
nment (and I have to admit I have not read the spec in enough detail to det=
ermine if this is the case), then we come to the conclusion that the DYMO/A=
ODVv2 path should be followed unless we collectively feel that such a direc=
tion is not worth pursuing (and note I am definitely not proposing that vie=
w).

In the two years or so that I have been working with MANETs, the only concl=
usion I have come to is that very many use cases exist, and that one size d=
oes not fit all.

Regards

John
________________________________
From: manet-bounces@ietf.org [mailto:manet-b=
ounces@ietf.org] On Behalf Of Thierry LYS
Sent: 31 October 2012 14:54
To: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation


Hi Joe,

I speak in the name of EDF group.

We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m=
eters for smart grid purposes in 2011. Taking advantage of this field test,=
 we have been actively participating to the working group to adopt enhancem=
ents in the LOADng specification.
We are now extremely pleased with what LOADng is capable of and are confide=
nt that future deployements will be equipped with it.

"We believe in rough consensus and running code"

rough consensus : Don't you think we have a rough consensus on LOADng compa=
red to DYMO ? 10 authors and major companies are supporters of LOADng.

running code : interoperability has been checked with 4 sources and other i=
mplementations are in progress.

We hope that IETF will realize how urgent and promising is the market for t=
he smart grid.
So to answer your question : We opt for answer 2 !

Best regards,

Thierry Lys (ERDF, EDF Group)
and Cedric Lavenu (EDF R&D, EDF Group)
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A7722044A6Dxmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Thierry,






I cannot agree more with you.







Thanks.







JP.







On Oct 31, 2012, at 4:56 PM, Dowdell, John wrote:











Thierry


 


While I am very pleased for you and =
your co-authors that the LOADng work has been so fruitful, I am not really =
sure that smart meters are really the kind
 of MANET devices that the working group was intended to address. I have be=
en party to the conversations for only a year or two, so I am very happy to=
 be corrected by those with longer histories, but MANET to me means dynamic=
ally moving nodes, with links being
 established and broken often and without prior warning. Examples may be co=
mmunications networks built out of nodes contained in cars, trucks and airc=
raft of all sizes. I appreciate a comment on the list a while back that the=
 RF environment for smart metering
 is actually more difficult than one would think, but I would suggest to th=
e chairs that unless LOADng has applications in this dynamically mobile env=
ironment (and I have to admit I have not read the spec in enough detail to =
determine if this is the case),
 then we come to the conclusion that the DYMO/AODVv2 path should be followe=
d unless we collectively feel that such a direction is not worth pursuing (=
and note I am definitely not proposing that view).=




 


In the two years or so that I have b=
een working with MANETs, the only conclusion I have come to is that very ma=
ny use cases exist, and that one size does
 not fit all.



 


Regards


 




John














From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On
 Behalf Of Thi=
erry LYS

Sent: 31 October 2012 14:54

To: manet@ietf.org

Subject: Re: [manet] Reactive Protocol Situation





 





Hi Joe, 



I speak in the name of EDF group. 



We started first to use LOAD as a routing algorithm an=
d deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantag=
e of this field test, we have been actively
 participating to the working group to adopt enhancements in the LOADng spe=
cification. 

We are now extremely pleased with what LOADng is capab=
le of and are confident that future deployements will be equipped with it.<=
/span> 



"We believe in rough consensus and running code&q=
uot; 



rough consensus : Don't you think we have a rough cons=
ensus on LOADng compared to DYMO ? 10 authors and major companies are suppo=
rters of LOADng. <=
/font>



running code : interoperability has been checked with =
4 sources and other implementations are in progress. 



We hope that IETF will realize how urgent and promisin=
g is the market for the smart grid. 

So to answer your question : We opt for answer 2 ! 



Best regards, 



Thierry Lys (ERDF, EDF Group) 

and Cedric Lavenu (EDF R&D, EDF Group)



_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/mane=
t














--_000_03B78081B371D44390ED6E7BADBB4A7722044A6Dxmbrcdx02ciscoc_--

From jvasseur@cisco.com  Wed Oct 31 10:07:08 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA06521F8510 for ; Wed, 31 Oct 2012 10:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.439
X-Spam-Level: 
X-Spam-Status: No, score=-10.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5lD26aVk5pr for ; Wed, 31 Oct 2012 10:07:08 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BD4D521F86C4 for ; Wed, 31 Oct 2012 10:07:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15137; q=dns/txt; s=iport; t=1351703228; x=1352912828; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5OniZN/UUiCoTHmUDcuThK89sDVgcbj/FY2g9GHaS8g=; b=CN1lp8g8AifW8KHPlXOS4JnU0sHQDEVKWDhlS+RYzjMKAunJlS2eYhnd 3j3aM+GAsNcbWuQPtf1oRbfg0tbcg1t/O7B8feu/oI692oSW0RdT9vAF3 2jPiaBiJWKr75DkkdzrHhOvs5qzUbHAc6iBbjqMs7GfFRZm67ycheIuMj U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAERZkVCtJXG8/2dsb2JhbABEgknBJ4EIgh4BAQEEAQEBDwFbCxACAQgRBAEBCx0HJwsUCQgCBA4FCBqHZAucQ6AWBIt4hVphA6RNgWuCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200";  d="scan'208,217";a="137449611"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 31 Oct 2012 17:07:05 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9VH759j022563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 17:07:05 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 12:07:05 -0500
From: "JP Vasseur (jvasseur)" 
To: "Dowdell, John" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt4omLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 17:07:04 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722044C9B@xmb-rcd-x02.cisco.com>
References:  <1B40484159234F4FB6FE11D4C2F408DE01FFC29A@SUKNPT8108.cogent-dsn.local> <8FEFE625-B6F8-4EBC-94CC-196BCB20834E@cisco.com>
In-Reply-To: <8FEFE625-B6F8-4EBC-94CC-196BCB20834E@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--46.702000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722044C9Bxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" , Thierry LYS 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:07:09 -0000

--_000_03B78081B371D44390ED6E7BADBB4A7722044C9Bxmbrcdx02ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Sorry =85 I meant:

John,

I cannot agree more with you.

JP.

On Oct 31, 2012, at 5:50 PM, JP Vasseur wrote:

Hi Thierry,

I cannot agree more with you.

Thanks.

JP.

On Oct 31, 2012, at 4:56 PM, Dowdell, John wrote:

Thierry

While I am very pleased for you and your co-authors that the LOADng work ha=
s been so fruitful, I am not really sure that smart meters are really the k=
ind of MANET devices that the working group was intended to address. I have=
 been party to the conversations for only a year or two, so I am very happy=
 to be corrected by those with longer histories, but MANET to me means dyna=
mically moving nodes, with links being established and broken often and wit=
hout prior warning. Examples may be communications networks built out of no=
des contained in cars, trucks and aircraft of all sizes. I appreciate a com=
ment on the list a while back that the RF environment for smart metering is=
 actually more difficult than one would think, but I would suggest to the c=
hairs that unless LOADng has applications in this dynamically mobile enviro=
nment (and I have to admit I have not read the spec in enough detail to det=
ermine if this is the case), then we come to the conclusion that the DYMO/A=
ODVv2 path should be followed unless we collectively feel that such a direc=
tion is not worth pursuing (and note I am definitely not proposing that vie=
w).

In the two years or so that I have been working with MANETs, the only concl=
usion I have come to is that very many use cases exist, and that one size d=
oes not fit all.

Regards

John
________________________________
From: manet-bounces@ietf.org [mailto:manet-b=
ounces@ietf.org] On Behalf Of Thierry LYS
Sent: 31 October 2012 14:54
To: manet@ietf.org
Subject: Re: [manet] Reactive Protocol Situation


Hi Joe,

I speak in the name of EDF group.

We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m=
eters for smart grid purposes in 2011. Taking advantage of this field test,=
 we have been actively participating to the working group to adopt enhancem=
ents in the LOADng specification.
We are now extremely pleased with what LOADng is capable of and are confide=
nt that future deployements will be equipped with it.

"We believe in rough consensus and running code"

rough consensus : Don't you think we have a rough consensus on LOADng compa=
red to DYMO ? 10 authors and major companies are supporters of LOADng.

running code : interoperability has been checked with 4 sources and other i=
mplementations are in progress.

We hope that IETF will realize how urgent and promising is the market for t=
he smart grid.
So to answer your question : We opt for answer 2 !

Best regards,

Thierry Lys (ERDF, EDF Group)
and Cedric Lavenu (EDF R&D, EDF Group)
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A7722044C9Bxmbrcdx02ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Sorry =85 I meant:






John, 







I cannot agree more with you.







JP.









On Oct 31, 2012, at 5:50 PM, JP Vasseur wrote:







Hi Thierry,






I cannot agree more with you.







Thanks.







JP.







On Oct 31, 2012, at 4:56 PM, Dowdell, John wrote:











Thierry


 


While I am very pleased for you and =
your co-authors that the LOADng work has been so fruitful, I am not really =
sure that smart meters are really the kind
 of MANET devices that the working group was intended to address. I have be=
en party to the conversations for only a year or two, so I am very happy to=
 be corrected by those with longer histories, but MANET to me means dynamic=
ally moving nodes, with links being
 established and broken often and without prior warning. Examples may be co=
mmunications networks built out of nodes contained in cars, trucks and airc=
raft of all sizes. I appreciate a comment on the list a while back that the=
 RF environment for smart metering
 is actually more difficult than one would think, but I would suggest to th=
e chairs that unless LOADng has applications in this dynamically mobile env=
ironment (and I have to admit I have not read the spec in enough detail to =
determine if this is the case),
 then we come to the conclusion that the DYMO/AODVv2 path should be followe=
d unless we collectively feel that such a direction is not worth pursuing (=
and note I am definitely not proposing that view).=




 


In the two years or so that I have b=
een working with MANETs, the only conclusion I have come to is that very ma=
ny use cases exist, and that one size does
 not fit all.



 


Regards


 




John














From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On
 Behalf Of Thi=
erry LYS

Sent: 31 October 2012 14:54

To: manet@ietf.org

Subject: Re: [manet] Reactive Protocol Situation





 





Hi Joe, 



I speak in the name of EDF group. 



We started first to use LOAD as a routing algorithm an=
d deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantag=
e of this field test, we have been actively
 participating to the working group to adopt enhancements in the LOADng spe=
cification. 

We are now extremely pleased with what LOADng is capab=
le of and are confident that future deployements will be equipped with it.<=
/span> 



"We believe in rough consensus and running code&q=
uot; 



rough consensus : Don't you think we have a rough cons=
ensus on LOADng compared to DYMO ? 10 authors and major companies are suppo=
rters of LOADng. <=
/font>



running code : interoperability has been checked with =
4 sources and other implementations are in progress. 



We hope that IETF will realize how urgent and promisin=
g is the market for the smart grid. 

So to answer your question : We opt for answer 2 ! 



Best regards, 



Thierry Lys (ERDF, EDF Group) 

and Cedric Lavenu (EDF R&D, EDF Group)



_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/mane=
t


























--_000_03B78081B371D44390ED6E7BADBB4A7722044C9Bxmbrcdx02ciscoc_--

From ulrich@herberg.name  Wed Oct 31 10:11:57 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6C21F878C for ; Wed, 31 Oct 2012 10:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=1.277,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw+PunCx3QnM for ; Wed, 31 Oct 2012 10:11:56 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64221F8774 for ; Wed, 31 Oct 2012 10:11:56 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id fl11so1972053vcb.31 for ; Wed, 31 Oct 2012 10:11:55 -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=mQSos8weWsUzZfwJMbRxbbol4iuZjD//danhx89LHpw=; b=GKjttGvyHTfvsZR9/20kLtYOlCQn6nRS8fY7H6TuIxnGEKf48PhSXlshBbo1VyX2qN 0jJEb9JhTyqKOE7L29MsQ9psEWOJrj7ehTwY8285RJgdHas4Eqtq+8vZrFIRnjnMxotr 5Pn7rxrPZP4fiBX+Q3mtKcosmZUSvjRNa0IPc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=mQSos8weWsUzZfwJMbRxbbol4iuZjD//danhx89LHpw=; b=hjAwhw31JXeSsdA0xYOI5zb5iTlyGmspRRF0Veg5S+MMTyfFTvqQ2f+4frGIBEA7EL B7Y4j7OcUDCPNOfRYvv7btqkirsOL9loGo44NvoGLY5IQq4EplACuucP9YpdwMSC8eFA 7Cbn90Gg0lL9VXUHkL1TFBsJzUjoxd5o2E4aakmQRXUXozlDP3p7JhuaTR2mnhm6BZZg UbCKhYyO/mjfyPCFFEi20VHRPm5UOhxqCF4jk4nPSKd3+j0YdZX8yvL2iADIF5ykbmhr /YjDIG54CeCFO8etxEtuOo4iKuneloytJPGR4npzgK5HbmpoP5xPbvVLTQYeYnCWQyRL 6NNQ==
MIME-Version: 1.0
Received: by 10.52.95.201 with SMTP id dm9mr48162790vdb.95.1351703515812; Wed, 31 Oct 2012 10:11:55 -0700 (PDT)
Received: by 10.58.94.103 with HTTP; Wed, 31 Oct 2012 10:11:55 -0700 (PDT)
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com>
References:  <50906802.9070904@saloits.com>  <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com>
Date: Wed, 31 Oct 2012 10:11:55 -0700
Message-ID: 
From: Ulrich Herberg 
To: "JP Vasseur (jvasseur)" 
Content-Type: multipart/alternative; boundary=20cf3071c69ce6d2fa04cd5dffbb
X-Gm-Message-State: ALoCoQlci4cQJR+hMWQjP5cRYFfvvRpU5+oWLG6qkCX238rakXjQDAiZ3EX3ANnEY18OwYgISWE0
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:11:57 -0000

--20cf3071c69ce6d2fa04cd5dffbb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi JP,

On Wed, Oct 31, 2012 at 9:49 AM, JP Vasseur (jvasseur)
wrote:

>
> On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:
>
> > Hi JP,
> >>
> >> Note that IETF cannot be driven by company roadmap.
> >
> > Then please let me hear your technical arguments. So far, you have been
> only saying that one protocol is in a "GREAT" shape, the other is not, an=
d
> I believe it is no secret that Cisco also has a company roadmap in this
> space.
>
> Let's not go that route =85 this won't be productive.



And this is what I asked you to be: productive, by providing technical
arguments



> I am speaking as an individual having spent years working on such issues
> as many did too. What would you like ? Lots of experimental and simulatio=
n
> results showing why Load-NG will not work at
> scale in LLN ?
>


This is not the point. It is a MANET protocol, otherwise we would present
it to the ROLL WG. As said before, LLNs are a special use case of MANETs in
my opinion, and LOADng is as a matter of fact used in such deployments, and
these deployments are large-scale. You mentioned lots of results and
simulations showing that it will not work, but I have never seen these
results. And as I said before, you can construct scenarios where a reactive
protocol will not work, and others where it will work. MANET has long
understood that and is therefore chartered to come up with a reactive and a
proactive protocol.

Regards
Ulrich

--20cf3071c69ce6d2fa04cd5dffbb
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi JP,

On Wed, Oct 31, 2012 at 9:49 AM, J=
P Vasseur (jvasseur) <jvasseur@cisco.com> wrote:




On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:



> Hi JP,

>>

>> Note that IETF cannot be driven by company roadmap.

>

> Then please let me hear your technical arguments. So far, you have bee=
n only saying that one protocol is in a "GREAT" shape, the other =
is not, and I believe it is no secret that Cisco also has a company roadmap=
 in this space.





Let's not go that route =85 this won't be productive.


And this is what I asked you =
to be: productive, by providing technical arguments



=A0
 I am speaking as an individua=
l having spent years working on such issues

as many did too. What would you like ? Lots of experimental and simulation =
results showing why Load-NG will not work at

scale in LLN ?
=A0

This is no=
t the point. It is a MANET protocol, otherwise we would present it to the R=
OLL WG. As said before, LLNs are a special use case of MANETs in my opinion=
, and LOADng is as a matter of fact used in such deployments, and these dep=
loyments are large-scale. You mentioned lots of results and simulations sho=
wing that it will not work, but I have never seen these results. And as I s=
aid before, you can construct scenarios where a reactive protocol will not =
work, and others where it will work. MANET has long understood that and is =
therefore chartered to come up with a reactive and a proactive protocol.


Regards
Ulrich


--20cf3071c69ce6d2fa04cd5dffbb--

From jblack.ietf@yahoo.com  Wed Oct 31 10:13:52 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF47921F87C6 for ; Wed, 31 Oct 2012 10:13:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhaC4QP35oom for ; Wed, 31 Oct 2012 10:13:52 -0700 (PDT)
Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0A21F877F for ; Wed, 31 Oct 2012 10:13:50 -0700 (PDT)
Received: from [98.139.215.143] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:13:48 -0000
Received: from [98.139.212.203] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:13:48 -0000
Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:13:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 795266.44448.bm@omp1012.mail.bf1.yahoo.com
Received: (qmail 62424 invoked by uid 60001); 31 Oct 2012 17:13:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351703628; bh=go6o4C1iy6JBXGs8GcSqAECdE3UGtU8AeLWqpqtnufU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=jEisA3wHYDBmchBPqpi0ORAFIy4+55UvGwbvaBi2gd1KChEzxUiA8VDKPikJgwtWQN/f/oujmb9AmW/HOI8nGrPjUP/qALSeZ3IQ811lfKMRogiEoGJV6DvQX7FyJP+V8Q3rU9DihxBFVXg2UUrQIuEZwH6fUAxn+GoKFb0/0mE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=C3fYmXXJEUKdgPBrF7+dqZHwZf4Iribl1NIh0a+H2O2B5qa2oOMRDV85X7wQf6mXZ4B5ZcZifbJBHCIZQCv+ZMQl/JlChYwssXcSQkR4bWUI4kUd6ltnwcsfCxl0mFyXOTueK7+KS7zG8mdSFKj9NJcuDKEAxwmuydBQ5ImkUvQ=;
X-YMail-OSG: KCiZBBsVM1mHjS7.85iQpG6jxSRkbvvWl5YK3Zj6BqwgvZM JdfxQje8NfJMFxbM1Q1Ejytf3Cq0YlLuBZnszZcHyPOipXbXMv3Wl5RE4iGu uJSgQpetL5__RYlU1YrII1EGTbY1um0HPSxa0z.49jAHIoWz3CbyLZbYoUml 8rU9Eb1qxgL4hAeacs3ybK6KaWQIvXC_r3h1MLQ733FBATpDf8M5LMvKheJc cownrmY1z4KJ.FNhweNvWlDkCcTf4RYQM02H7XNIsnRQFC_gmm5NgK2LuKix tJaSRrdRF_hyI2jpS74.aIR.thPzYD81ltDwpd3KRuNY82.S5iedoztJLkgo YGSGy4O5MWbxCT0N5NRiBldfnJW61OAGL7jC30wBPGyBryUeLC9s18YRVo.G M324HZGS_lzZzSsGvRAzfQE.AyQ5STHFy1DtcK7ZJL0VW4pE-
Received: from [173.193.202.116] by web160602.mail.bf1.yahoo.com via HTTP; Wed, 31 Oct 2012 10:13:48 PDT
X-Rocket-MIMEInfo: 001.001, T24gT2N0b2JlciAzMSwgMjAxMiBhdCAxMjo0OSBQTSwgSlZhc3NldXIgd3JvdGU6CgpPbiBPY3QgMzEsIDIwMTIsIGF0IDQ6MjUgUE0sIFVscmljaCBIZXJiZXJnIHdyb3RlOiAKSGkgSlAsIAo.Tm90ZSB0aGF0IElFVEYgY2Fubm90IGJlIGRyaXZlbiBieSBjb21wYW55IHJvYWRtYXAuIAo.VGhlbiBwbGVhc2UgbGV0IG1lIGhlYXIgeW91ciB0ZWNobmljYWwgYXJndW1lbnRzLiBTbyBmYXIsIHlvdSBoYXZlIGJlZW4gb25seSBzYXlpbmcgdGhhdCBvbmUgcHJvdG9jb2wgaXMgaW4gYSAiR1JFQVQiIHNoYXBlLCABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.123.460
Message-ID: <1351703628.44951.YahooMailNeo@web160602.mail.bf1.yahoo.com>
Date: Wed, 31 Oct 2012 10:13:48 -0700 (PDT)
From: Jon Black 
To: "manet@ietf.org" , "jvasseur@cisco.com" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1725615817-676534129-1351703628=:44951"
Cc: "salo@saloits.com" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Jon Black 
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:13:53 -0000

---1725615817-676534129-1351703628=:44951
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On October 31, 2012 at 12:49 PM, JVasseur wrote:=0A=0AOn Oct 31, 2012, at 4=
:25 PM, Ulrich Herberg wrote: =0AHi JP, =0A>Note that IETF cannot be driven=
 by company roadmap. =0A>Then please let me hear your technical arguments. =
So far, you have been only saying that one protocol is in a "GREAT" shape, =
the other is not, and I believe it is no secret that Cisco also has a compa=
ny roadmap in this space. =0ALet's not go that route =E2=80=A6 this won't b=
e productive. I am speaking as an individual having spent years working on =
such issues=0Aas many did too. What would you like ? Lots of experimental a=
nd simulation results showing why Load-NG will not work at=0Ascale in LLN ?=
 =0A=0A[Jon] Yes, please share something technical.  Just you saying it doe=
sn't work is not productive.=0ABest=0AUlrich=0A____________________________=
___________________=0Amanet mailing list manet@ietf.org https://www.ietf.or=
g/mailman/listinfo/manet =0A_______________________________________________=
=0Amanet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/=
manet 
---1725615817-676534129-1351703628=:44951
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On October 31, 2012 at 12:49 PM, JVasseur=
 wrote:

On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:=0A=0A
Hi JP,=
=0A
Note that IETF cannot be driven by company roadmap.=0A
<=
pre wrap=3D"">Then please let me hear your technical arguments. So far, you=
 have been only saying that one protocol is in a "GREAT" shape, the other i=
s not, and I believe it is no secret that Cisco also has a company roadmap =
in this space.=0A
Let's not go that route =
=E2=80=A6 this won't be productive. I am speaking as an individual having s=
pent years working on such issues=0Aas many did too. What would you like ? =
Lots of experimental and simulation results showing why Load-NG will not wo=
rk at=0Ascale in LLN ? 

[Jon] Yes, please share something technical.=
  Just you saying it doesn't work is not productive.=0A=0A
Best=0AUlrich=0A___=
____________________________________________=0Amanet mailing list=0Amanet@ietf.or=
g=0Ahttps://www.ietf.org/mailman/listinfo/manet=0A
_____________________________________________=
__=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.org/=
mailman/listinfo/manet=0A

---1725615817-676534129-1351703628=:44951--

From jvasseur@cisco.com  Wed Oct 31 10:21:21 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BED21F878E for ; Wed, 31 Oct 2012 10:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.455
X-Spam-Level: 
X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HN7HIqS2+wSa for ; Wed, 31 Oct 2012 10:21:18 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8740221F878A for ; Wed, 31 Oct 2012 10:21:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6276; q=dns/txt; s=iport; t=1351704078; x=1352913678; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GaRNuowOFP7P17PM5SgINz9Bule4J8VW96AUPS1AtX4=; b=mgJBkZQ9BXXXO2B7+oP70rK/4T1pMxFuxuCbTRo/04L4hZ84LaMFoXSL 2KZPTtlBeTuYU0/Z5D3n/FCpjkeJ6PibHMxOfH2OZ/S+w3YAxcLSI7HO1 GAIKsM2dUQVocVg+nOo99rbv9S41MHdPXrY8+CvTWF/iA61Oe+DwcICDB s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EADJdkVCtJXG9/2dsb2JhbABEw3CBCIIeAQEBAwESAWYFCwIBCCIdBzIUEQIEDgUIEweHXgacM6Adi3iFWmEDpE2Ba4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200";  d="scan'208,217";a="137454802"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 31 Oct 2012 17:21:18 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9VHLIxm027838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 17:21:18 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 12:21:17 -0500
From: "JP Vasseur (jvasseur)" 
To: Ulrich Herberg 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt0IiLPVi/cSo/ES1hdb7zda62w==
Date: Wed, 31 Oct 2012 17:21:17 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722044E26@xmb-rcd-x02.cisco.com>
References:  <50906802.9070904@saloits.com>  <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.20.89]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--47.993100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722044E26xmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:21:22 -0000

--_000_03B78081B371D44390ED6E7BADBB4A7722044E26xmbrcdx02ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Ulrich,

Here is what I would propose =85 The chairs asked us a question, let's stic=
k to it and wait for their guidance.
If the choice is to go with 1) then there is no point in having me sharing =
all results about why Load is ill suited
to LLN, or for you to explain why it is well suited (which by the way you n=
ever did either =85 you also keep saying
that it worked but we never got any technical results). If 2) is chosen I w=
ill certainly clearly document with lots
of information why I think there is a major issue with Load-ng in LLN.

That being said, I am still hopeful that we will find a solution; options 1=
) knowing that Charlie made it compatible
seems to be by far the best option.

Thanks.

JP.

On Oct 31, 2012, at 6:11 PM, Ulrich Herberg wrote:

Hi JP,

On Wed, Oct 31, 2012 at 9:49 AM, JP Vasseur (jvasseur) > wrote:

On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:

> Hi JP,
>>
>> Note that IETF cannot be driven by company roadmap.
>
> Then please let me hear your technical arguments. So far, you have been o=
nly saying that one protocol is in a "GREAT" shape, the other is not, and I=
 believe it is no secret that Cisco also has a company roadmap in this spac=
e.

Let's not go that route =85 this won't be productive.


And this is what I asked you to be: productive, by providing technical argu=
ments


I am speaking as an individual having spent years working on such issues
as many did too. What would you like ? Lots of experimental and simulation =
results showing why Load-NG will not work at
scale in LLN ?


This is not the point. It is a MANET protocol, otherwise we would present i=
t to the ROLL WG. As said before, LLNs are a special use case of MANETs in =
my opinion, and LOADng is as a matter of fact used in such deployments, and=
 these deployments are large-scale. You mentioned lots of results and simul=
ations showing that it will not work, but I have never seen these results. =
And as I said before, you can construct scenarios where a reactive protocol=
 will not work, and others where it will work. MANET has long understood th=
at and is therefore chartered to come up with a reactive and a proactive pr=
otocol.

Regards
Ulrich


--_000_03B78081B371D44390ED6E7BADBB4A7722044E26xmbrcdx02ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Hi Ulrich,






Here is what I would propose =85 The chairs asked us a question, let's=
 stick to it and wait for their guidance.


If the choice is to go with 1) then there is no point in having me sha=
ring all results about why Load is ill suited


to LLN, or for you to explain why it is well suited (which by the way =
you never did either =85 you also keep saying


that it worked but we never got any technical results). If 2) is chose=
n I will certainly clearly document with lots


of information why I think there is a major issue with Load-ng in LLN.=








That being said, I am still hopeful that we will find a solution; opti=
ons 1) knowing that Charlie made it compatible


seems to be by far the best option.







Thanks.







JP.







On Oct 31, 2012, at 6:11 PM, Ulrich Herberg wrote:




Hi JP,




On Wed, Oct 31, 2012 at 9:49 AM, JP Vasseur (jva=
sseur) 
<jvasseur@cisco.=
com> wrote:








On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:



> Hi JP,

>>

>> Note that IETF cannot be driven by company roadmap.

>

> Then please let me hear your technical arguments. So far, you have bee=
n only saying that one protocol is in a "GREAT" shape, the other =
is not, and I believe it is no secret that Cisco also has a company roadmap=
 in this space.







Let's not go that route =85 this won't be productive.












And this is what I asked you to be: productive, by providing technical=
 arguments







 



I am speaking as an individual having spent years working on such issues
as many did too. What would you like ? Lots of experimental and simulation =
results showing why Load-NG will not work at

scale in LLN ?




 







This is not the point. It is a MANET protocol, otherwise we would pres=
ent it to the ROLL WG. As said before, LLNs are a special use case of MANET=
s in my opinion, and LOADng is as a matter of fact used in such deployments=
, and these deployments are large-scale.
 You mentioned lots of results and simulations showing that it will not wor=
k, but I have never seen these results. And as I said before, you can const=
ruct scenarios where a reactive protocol will not work, and others where it=
 will work. MANET has long understood
 that and is therefore chartered to come up with a reactive and a proactive=
 protocol.







Regards


Ulrich














--_000_03B78081B371D44390ED6E7BADBB4A7722044E26xmbrcdx02ciscoc_--

From jblack.ietf@yahoo.com  Wed Oct 31 10:23:18 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6919F21F8884 for ; Wed, 31 Oct 2012 10:23:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-KqG8GMsjeC for ; Wed, 31 Oct 2012 10:23:17 -0700 (PDT)
Received: from nm3.bullet.mail.bf1.yahoo.com (nm3.bullet.mail.bf1.yahoo.com [98.139.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8F45121F8732 for ; Wed, 31 Oct 2012 10:23:17 -0700 (PDT)
Received: from [98.139.212.146] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:23:16 -0000
Received: from [98.139.212.198] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:23:16 -0000
Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:23:16 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 609337.20630.bm@omp1007.mail.bf1.yahoo.com
Received: (qmail 36494 invoked by uid 60001); 31 Oct 2012 17:23:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351704196; bh=FLGyNZUZfU06HFkZOfyPKnbufGbHVfQulXznzrEjtyc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=X6NdFwX6Nu1TKHFvOfCHwEYcme+auacmaIdc72rQ8cF7MDxnFLisvPZHkr5KmvzDA7FY4BweNDoQWlh8TcJ4H+yzpeF/9bJm5hUcH3Zc6mRVLOptCX8l7+f7LjRy6muXyW7qKGLAOOJ9TBS7/v7XUG5IkxRDv+Fyd8gWDkSzVOo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=MyCtuYqOROs4wEoi8VC5ypQzbJEthIzz5p2XU1qDTyC8cokEYib+l40EU8vi22/2vrtmw1qtRodMRqt9BB+vmFtzz41g/zUnSnNrnPt+ga4kHlK3/Y9kIWahfMaAo0GDtaVDg/xstjzOs429yfY6QqggYjRolbpw6Pf3BJbVcyw=;
X-YMail-OSG: EFl75lAVM1k4Lo_kqsw2emXafyd2DTIqVBtr05j7ohUUQvu tPdW5H.H1kDNsE2VXWwv2nPdYsSIhF3_hsBQjq0LOMQh8iXMpZlM1bx1V_dG okL5r2UsEDxmwIpxopGB6Hr.uhoNtR10DQfu5LFDJtnwXSG9MdmwrfdlBn8V nWXTjAob3tlvqQSfT6Q6QgeVhzgZSreKIlmAiiEF9hYarM3we7Y_Z40B8B2N PXUxfDdyeACytXWtvLfhrfFZMg9bJ5cA64VCPdwAuz6G1n_lkMXCqtcHRJ7r I1FMRirL7brmA5JL3E.jKEnTdYVL9H0IJX0YqQS_PCm..JLHCIcE0RuFRjR3 Q2qL6D.PkKEMjI1NBJNGx1w4zhiGoAg3jCb_e83AUDw_QG9h16w1Iov93hn3 fxa2fLfqOB4dTYZjl21G2_vqxCzlOSb_71ruzll8HpLY9Y1HgzDNnR3tUOqX kJ3Jl69RlAbHT5JWsZA8nbsX5ttmYLhLy.azHYXTzy1HP6oQkdIoBX8dZUlq NH6XA_JXOqw--
Received: from [173.193.202.116] by web160603.mail.bf1.yahoo.com via HTTP; Wed, 31 Oct 2012 10:23:16 PDT
X-Rocket-MIMEInfo: 001.001, T24gT2N0b2JlciAzMSwgMjAxMiBhdCAxMjo0NSBQTSwgSlBWYXNzZXVyIHdyb3RlOgoKPkpQPiBXZWxsIGxldCdzIHNlZSB3aGF0IHRoZSBjaGFpcnMgdGhpbmsgb2YgY291cnNlLiBIYXZpbmcgYWxsIGF1dGhvcnMgb2YgTG9hZC1ORyBzdXBwb3J0aW5nIGl0IHdhcyBleHBlY3RlZCB0aG91Z2guCgoKQW5kIGhlYXJpbmcgZnJvbSB0aGUgUlBMIGF1dGhvcnMgbm90IHN1cHBvcnRpbmcgaXQgaXMgZXhwZWN0ZWQuATABAQEB
X-Mailer: YahooMailWebService/0.8.123.460
Message-ID: <1351704196.28009.YahooMailNeo@web160603.mail.bf1.yahoo.com>
Date: Wed, 31 Oct 2012 10:23:16 -0700 (PDT)
From: Jon Black 
To: "manet@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1886287700-586928187-1351704196=:28009"
Cc: "thierry.lys@erdfdistribution.fr" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Jon Black 
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:23:18 -0000

--1886287700-586928187-1351704196=:28009
Content-Type: text/plain; charset=us-ascii

On October 31, 2012 at 12:45 PM, JPVasseur wrote:

>JP> Well let's see what the chairs think of course. Having all authors of Load-NG supporting it was expected though.


And hearing from the RPL authors not supporting it is expected.
--1886287700-586928187-1351704196=:28009
Content-Type: text/html; charset=us-ascii


On October 31, 2012 at 12:45 PM, JPVasseur wrote:

>JP> Well let's see what the chairs think of course. Having all authors of Load-NG supporting it was expected though.

And hearing from the RPL authors not supporting it is expected.



--1886287700-586928187-1351704196=:28009--

From yi.jiazi@gmail.com  Wed Oct 31 10:31:15 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6245621F861B for ; Wed, 31 Oct 2012 10:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGq-rCi8fV0E for ; Wed, 31 Oct 2012 10:31:14 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B94CE21F873A for ; Wed, 31 Oct 2012 10:31:13 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so850167wey.31 for ; Wed, 31 Oct 2012 10:31:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=fu0paFJCqytxKAH15YciXbMc6H5njF/iR7Llv0A9Yec=; b=Mxflsjm61SIJ6P3quX/HIq3wmhbeiUZfAFZ0HEVgfaBC+d5BmIECnZVYCU1D4N7fo0 2oarFXJQ2b9c1HyD4Q+WAAPnYItmM0b/bF9htIpnxOVdvhS/vp+zEp8FYNGy2lcImdgO UTQAq88e5X38Uiez8IJ8g+RHdD2Z/BhrQtulpqZYtVlfHlcntDApBShDourduo83VGjX lGeoz/ODHMCmA5uW2h4iagM9Lq47Lz/iIEY+1BAF+w9nwhkng7Sg6jHizC0Ni0qEewa3 cfJKjNJwDTHDT8JK22c2pLAPVGBJbm7ZtoE4chwYXVDblX7UekM5O6WahLriHwebdMnm AA9Q==
Received: by 10.180.84.138 with SMTP id z10mr258232wiy.6.1351704670857; Wed, 31 Oct 2012 10:31:10 -0700 (PDT)
Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id fg6sm11152881wib.3.2012.10.31.10.31.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 10:31:09 -0700 (PDT)
Sender: Jiazi YI 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C7AA7AE-642B-43F8-BFC7-E8A68F393D83"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Jiazi YI 
In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01FFC29A@SUKNPT8108.cogent-dsn.local>
Date: Wed, 31 Oct 2012 18:31:07 +0100
Message-Id: 
References:  <1B40484159234F4FB6FE11D4C2F408DE01FFC29A@SUKNPT8108.cogent-dsn.local>
To: "Dowdell, John" 
X-Mailer: Apple Mail (2.1499)
Cc: manet@ietf.org, Thierry LYS 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:31:15 -0000

--Apple-Mail=_3C7AA7AE-642B-43F8-BFC7-E8A68F393D83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear John, dear all,

There have been a lot of discussions on LLNs and MANET in other =
sessions, and I don't think it's necessary to repeat the whole =
discussion here.=20
My opinion is:
1) LLN is a subset of MANET, and=20
2) As a derivative of AODV, LOADng can be also adapted to some mobile =
scenarios (as you said, one size does not fit all), and the LOADng =
authors are willing to work to meet the requirement of the WG. =20

On reactive issue, I fully agree with what Chris said before. The more =
important is the technical questions.=20

1) Are those two approaches (LOADng and DYMO) at the same point after =
two years?

My personal answer is no. LOADng has already concrete results, =
implementations, interop test, running code.=20
I have read the latest DYMO revision in detail, which still have a lot =
of major flaws. If I'm going to implement DYMO based on the =
specification, I can't imagine how I can finish the work without my =
personal guess, which surely makes the protocol impossible to =
interoperate. In fact, after the effort of trying to be "compatible" =
with LOADng, the current DYMO-23 has much more inconsistencies and worse =
shape than DYMO-21 two years ago.=20
Of course, I would like to hear your opinion after you reading the DYMO =
draft.=20

In fact, I don't get the point when the DYMO editor said "make DYMO =
compatible with LOADng". LOADng is a protocol that still evolving, in =
the aspect of packet format, mechanisms, etc. to make the protocol more =
efficient. I can't understand how DYMO can be compatible with LOADng =
without keeping taking ideas/text from LOADng (as DYMO already did, in =
absence of the agreement of other LOADng authors). I don't think this is =
appropriate behavior in the WG.

2) How much effort / time do we still need from where we are?

LOADng is already relatively mature with running code, interop test, =
etc. I know that there are several technical issues to address which are =
required by the WG chairs, and believe it can be resolved in very short =
time. All the related documents: interop report, mib would be updated =
timely. Last but not least, all the LOADng authors are eager to see it =
happen as soon as possible and willing to put all efforts necessary in =
it.=20

In the meantime, DYMO is now addressing the comments from two years ago, =
in a worse shape compared to dymo-21 when trying to be "compatible" with =
LOADng, and has intention to *follow* LOADng specification. Giving all =
those, I really don't have any idea how much effort/time is needed. I =
have no doubt that the editor of DYMO has technical excellence to finish =
the job if he had enough time. I would strongly support him doing so if =
I was in 2010.  But now we are in 2012, and rolling back to 2010 is =
unacceptable.=20

best

Jiazi



On Oct 31, 2012, at 4:56 PM, "Dowdell, John" =
 wrote:

> Thierry
> =20
> While I am very pleased for you and your co-authors that the LOADng =
work has been so fruitful, I am not really sure that smart meters are =
really the kind of MANET devices that the working group was intended to =
address. I have been party to the conversations for only a year or two, =
so I am very happy to be corrected by those with longer histories, but =
MANET to me means dynamically moving nodes, with links being established =
and broken often and without prior warning. Examples may be =
communications networks built out of nodes contained in cars, trucks and =
aircraft of all sizes. I appreciate a comment on the list a while back =
that the RF environment for smart metering is actually more difficult =
than one would think, but I would suggest to the chairs that unless =
LOADng has applications in this dynamically mobile environment (and I =
have to admit I have not read the spec in enough detail to determine if =
this is the case), then we come to the conclusion that the DYMO/AODVv2 =
path should be followed unless we collectively feel that such a =
direction is not worth pursuing (and note I am definitely not proposing =
that view).
> =20
> In the two years or so that I have been working with MANETs, the only =
conclusion I have come to is that very many use cases exist, and that =
one size does not fit all.
> =20
> Regards
> =20
> John
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf =
OfThierry LYS
> Sent: 31 October 2012 14:54
> To: manet@ietf.org
> Subject: Re: [manet] Reactive Protocol Situation
> =20
>=20
> Hi Joe,=20
>=20
> I speak in the name of EDF group.=20
>=20
> We started first to use LOAD as a routing algorithm and deployed 2000 =
PLC-meters for smart grid purposes in 2011. Taking advantage of this =
field test, we have been actively participating to the working group to =
adopt enhancements in the LOADng specification.=20
> We are now extremely pleased with what LOADng is capable of and are =
confident that future deployements will be equipped with it.=20
>=20
> "We believe in rough consensus and running code"=20
>=20
> rough consensus : Don't you think we have a rough consensus on LOADng =
compared to DYMO ? 10 authors and major companies are supporters of =
LOADng.=20
>=20
> running code : interoperability has been checked with 4 sources and =
other implementations are in progress.=20
>=20
> We hope that IETF will realize how urgent and promising is the market =
for the smart grid.=20
> So to answer your question : We opt for answer 2 !=20
>=20
> Best regards,=20
>=20
> Thierry Lys (ERDF, EDF Group)=20
> and Cedric Lavenu (EDF R&D, EDF Group)
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_3C7AA7AE-642B-43F8-BFC7-E8A68F393D83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Dear John, =
dear all,
There have =
been a lot of discussions on LLNs and MANET in other sessions, and I =
don't think it's necessary to repeat the whole discussion =
here. 
My opinion is:
1) LLN is a subset =
of MANET, and 
2) As a derivative of AODV, LOADng can be =
also adapted to some mobile scenarios (as you said, one size does not =
fit all), and the LOADng authors are willing to work to meet the =
requirement of the WG.  

On reactive =
issue, I fully agree with what Chris said before. The more important is =
the technical questions. 

1) Are those two =
approaches (LOADng and DYMO) at the same point after two =
years?

My personal answer is no. LOADng has =
already concrete results, implementations, interop test, running =
code. 
I have read the latest DYMO revision in detail, =
which still have a lot of major flaws. If I'm going to implement DYMO =
based on the specification, I can't imagine how I can finish the work =
without my personal guess, which surely makes the protocol impossible to =
interoperate. In fact, after the effort of trying to be "compatible" =
with LOADng, the current DYMO-23 has much more inconsistencies and worse =
shape than DYMO-21 two years ago. 
Of course, I would =
like to hear your opinion after you reading the DYMO =
draft. 

In fact, I don't get the point =
when the DYMO editor said "make DYMO compatible with LOADng". LOADng is =
a protocol that still evolving, in the aspect of packet format, =
mechanisms, etc. to make the protocol more efficient. I can't understand =
how DYMO can be compatible with LOADng without keeping taking ideas/text =
from LOADng (as DYMO already did, in absence of the agreement of other =
LOADng authors). I don't think this is appropriate behavior in the =
WG.

2) How much effort / time do we still need =
from where we are?

LOADng is already relatively =
mature with running code, interop test, etc. I know that there are =
several technical issues to address which are required by the WG chairs, =
and believe it can be resolved in very short time. All the related =
documents: interop report, mib would be updated timely. Last but not =
least, all the LOADng authors are eager to see it happen as soon as =
possible and willing to put all efforts necessary in =
it. 

In the meantime, DYMO is now =
addressing the comments from two years ago, in a worse shape compared to =
dymo-21 when trying to be "compatible" with LOADng, and has intention to =
*follow* LOADng specification. Giving all those, I really don't have any =
idea how much effort/time is needed. I have no doubt that the editor of =
DYMO has technical excellence to finish the job if he had enough time. I =
would strongly support him doing so if I was in 2010.  But now we =
are in 2012, and rolling back to 2010 is =
unacceptable. 

best

Jiazi






On Oct 31, 2012, at 4:56 PM, "Dowdell, John" <John.Dowdell@Cassidian.com&=
gt; wrote:

 
While I am =
very pleased for you and your co-authors that the LOADng work has been =
so fruitful, I am not really sure that smart meters are really the kind =
of MANET devices that the working group was intended to address. I have =
been party to the conversations for only a year or two, so I am very =
happy to be corrected by those with longer histories, but MANET to me =
means dynamically moving nodes, with links being established and broken =
often and without prior warning. Examples may be communications networks =
built out of nodes contained in cars, trucks and aircraft of all sizes. =
I appreciate a comment on the list a while back that the RF environment =
for smart metering is actually more difficult than one would think, but =
I would suggest to the chairs that unless LOADng has applications in =
this dynamically mobile environment (and I have to admit I have not read =
the spec in enough detail to determine if this is the case), then we =
come to the conclusion that the DYMO/AODVv2 path should be followed =
unless we collectively feel that such a direction is not worth pursuing =
(and note I am definitely not proposing that =
view).
 
In the two =
years or so that I have been working with MANETs, the only conclusion I =
have come to is that very many use cases exist, and that one size does =
not fit all.
 
 
 manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf OfThierry =
LYS
Sent: 31 October 2012 =
14:54
To: manet@ietf.org
 Re: [manet] Reactive =
Protocol Situation
Hi =
Joe, 

I speak in the name of EDF group. 

We started first to use LOAD as a routing =
algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011. =
Taking advantage of this field test, we have been actively participating =
to the working group to adopt enhancements in the LOADng =
specification. 
We are now extremely pleased with what LOADng is capable =
of and are confident that future deployements will be equipped with =
it. 

"We believe in rough consensus and running =
code" 

rough consensus : Don't you think we have a rough =
consensus on LOADng compared to DYMO ? 10 authors and major companies =
are supporters of LOADng. 

running code : interoperability has been =
checked with 4 sources and other implementations are in =
progress. 

We hope that IETF will realize how urgent and promising is =
the market for the smart grid. 
So to answer your question : We opt for answer 2 =
! 

Best regards, 

Thierry Lys (ERDF, EDF Group) 
and Cedric Lavenu (EDF R&D, EDF =
Group)
_______________________________=
________________
manet mailing list
manet@ietf.org

To: "JP Vasseur (jvasseur)" 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfTFaOAgAAYXXCAAETwgIAAEoRAgAAbd4CAAAxEcA==
Date: Wed, 31 Oct 2012 17:34:56 +0000
Message-ID: 
References:  <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB43F9GLKXM0002VGREEN_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:35:03 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB43F9GLKXM0002VGREEN_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That I think has moved the goalposts. The issue is not whether LOADng is su=
itable in an LLN, because we are designing here a more general purpose MANE=
T routing protocol. So in the MANET WG, the issue of whether suitable for L=
LNs in particular principally affects any claimed use cases, rather than be=
ing a key differentiator.

That said, technical arguments are always of interest, and may shed interes=
ting light, particularly if you are suggesting there is a major difference =
in some regard between the two candidates.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
Sent: 31 October 2012 16:47
To: Dearlove, Christopher (UK)
Cc: Joseph Macker; 
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.

On Oct 31, 2012, at 4:11 PM, Dearlove, Christopher (UK) wrote:


I take it those are two separate sentences. You can agree with me, and you =
can support 1. But you can't agree with me supporting 1, as I haven't (nor =
have I supported 2).


I was agreeing on the fact that there was work to be done. Still strongly a=
dvocating for the option1, especially since Charlie is
working to make compatibility.


As indicated, I would like to hear the technical arguments you have against=
 LOADng. Here on list would seem the best place.


I am more than happy to share lots of results showing why LOAD-ng may be a =
severe issue for LLNs, since this was mentioned
as a clear use cases in the LOAD-ng document.


--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
Sent: 31 October 2012 14:03
To: Dearlove, Christopher (UK)
Cc: Joseph Macker; >
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Completely agreeing with you. 1) with some work needed, as agreed by Charli=
e.

JP.

On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher (UK) wrote:



As someone who has not (yet) stated an opinion on the matter, except I also=
 think option 3 is not good, I would very much like to hear technical argum=
ents, so if you have technical arguments against LOADng, I think we need to=
 hear them rather than just suggesting they exist. I haven't yet read LOADn=
g carefully to form a view there. I have just recently read the AODVv2 draf=
t carefully, and have some technical issues there (which overlap) regarding=
 asymmetric links, possible dependency on NHDP, and the compatibility of op=
tions. If option 1 is followed, the draft needs work (which Charlie has ack=
nowledged).

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-b=
ounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: >
Subject: Re: [manet] Reactive Protocol Situation


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
Dear chairs,

Remembering that I am not a co-authors of either of these drafts.

Not commenting on recent discussions but rather focussing on what I hope wi=
ll be a good solution for the WG and the Internet at large.

Option 3) is my opinion not desirable; I wish we could have a reactive rout=
ing protocol for MANET

Option 2) is an option I would be strongly opposed to for a number of techn=
ical reasons that I would be happy to elaborate on the
mailing list and/or in a new I-D (which I would, should option 2 be chosen)=
.

That being said, I am extremely supportive of option 1), especially in ligh=
t of what Charlie said. First of all DYMO is the working group
document and excellent progress has been made with recent revisions. But ev=
en more importantly, Charlie managed to make it compatible
with options, which is in my opinion the best of both worlds; calling it AO=
DVv2 is only not very sensible but avoids useful sensitivity around
names.

Thus I would strongly support Option 1), continue the work that Charlie has=
 started, which by the way is not far from completion. And
as WG,we need to remember that this had been the WG document, the result of=
 years of work. Still by making it compatible with other options,
this is technically flexible and sound.

Thanks.

JP.

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:




Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship led movement towards a common documen=
t effort and given positive feedback at the time we the chairs thought this=
 was the best approach given the authors potential to come together and gai=
n the best of both efforts.  Since that period, there has been some fairly =
strident and rancorous "at times" debate between the authors of the two doc=
uments.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they both derive roughly from AODV concepts =
and LOADng had fairly active authorship and implementation efforts. We prov=
ided a co-editing proposal to the authors and gave them the timeframe of th=
e Atlanta to come up with an answer back to us regarding this.  As of this =
writing, those discussions of a potential commonn document and authorship m=
erger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss=
ue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.
2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been =
some silent collecting initial feedback and waiting for author feedback at =
this point.  Stan and I are both on travel prior to Atlanta so our response=
s may be sparse and we will also likely be in a "receive mode" for a few da=
ys.  So send your opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


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



--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB43F9GLKXM0002VGREEN_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











That I think has moved th=
e goalposts. The issue is not whether LOADng is suitable in an LLN, because=
 we are designing here a more general purpose MANET routing
 protocol. So in the MANET WG, the issue of whether suitable for LLNs in pa=
rticular principally affects any claimed use cases, rather than being a key=
 differentiator.


 <=
/p>

That said, technical argu=
ments are always of interest, and may shed interesting light, particularly =
if you are suggesting there is a major difference in some
 regard between the two candidates.


 <=
/p>



chris.dearlove@baesystems.com
 | http://www.baesystems.com



BAE Systems (O=
perations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687




 <=
/p>





From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]


Sent: 31 October 2012 16:47

To: Dearlove, Christopher (UK)

Cc: Joseph Macker; <manet@ietf.org>

Subject: Re: [manet] Reactive Protocol Situation





 




 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see 
this process on how to deal with suspicious emails.<=
/i>






 






On Oct 31, 2012, at 4:11 PM, Dearlove, Christopher (=
UK) wrote:















I take it those are two s=
eparate sentences. You can agree with me, and you can support 1. But you ca=
n't agree with me supporting 1, as I haven't (nor have I
 supported 2).






 <=
/p>







 






I was agreeing on the fact that there was work to be=
 done. Still strongly advocating for the option1, especially since Charlie =
is






working to make compatibility.















As indicated, I would lik=
e to hear the technical arguments you have against LOADng. Here on list wou=
ld seem the best place.






 <=
/p>







 






I am more than happy to share lots of results showin=
g why LOAD-ng may be a severe issue for LLNs, since this was mentioned=







as a clear use cases in the LOAD-ng document.

















--






Christopher Dearlove






Senior Principal Engineer=
, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124<=
/o:p>






=
chris.dearlove@baesystems.com | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687








 <=
/p>









From: JP
 Vasseur (jvasseur) [mailto:jvasseur@cisco.com] 

Sent: 31 October 2=
012 14:03

To: Dearlove, Chri=
stopher (UK)

Cc: Joseph Macker;=
 <manet@ietf.org>

Subject: Re: [mane=
t] Reactive Protocol Situation










 






 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see =
this
 process =
on=
 how to deal with suspicious emails.








Completely agreeing with you. 1) with some work need=
ed, as agreed by Charlie.








 










JP.










 










On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher =
(UK) wrote:

























As someone who has not (y=
et) stated an opinion on the matter, except I also think option 3 is not go=
od, I would very much like to hear technical arguments,
 so if you have technical arguments against LOADng, I think we need to hear=
 them rather than just suggesting they exist. I haven't yet read LOADng car=
efully to form a view there. I have just recently read the AODVv2 draft car=
efully, and have some technical
 issues there (which overlap) regarding asymmetric links, possible dependen=
cy on NHDP, and the compatibility of options. If option 1 is followed, the =
draft needs work (which Charlie has acknowledged).










 <=
/p>











--










Christopher Dearlove










Senior Principal Engineer=
, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194 |  Fax: +44 1245 242124<=
/o:p>










=
chris.dearlove@baesystems.com | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687












 <=
/p>













From: ma=
net-bounces@ietf.org =
[mailto:manet-bounces@ietf.org] =
On
 Behalf Of JP Vasseur=
 (jvasseur)

Sent: 31 October 2=
012 08:29

To: Joseph Macker<=
br>
Cc: <manet@ietf.org>

Subject: Re: [mane=
t] Reactive Protocol Situation














 








 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see =
this
 process =
on=
 how to deal with suspicious emails.










Dear chairs,












 














Remembering that I am not a co-authors of either of =
these drafts.












 














Not commenting on recent discussions but rather f=
ocussing on what I hope will be a good solution for the WG and the Internet=
 at large.














 














Option 3) is my opinion not desirable; I wish we could have a reactive routing protocol =
for MANET














 














Option 2) is an option I would be strongly opposed to for a number of technical reasons =
that I would be happy to elaborate on the














mailing list and/or in a new I-D (which I would, sho=
uld option 2 be chosen).














 














That being said, I am extremely supportive of option 1), especially in light of what Charlie=
 said. First of all DYMO is the working group














document and excellent progress has been made with r=
ecent revisions. But even more importantly, Charlie managed to make it comp=
atible 














with options, which is in my opinion the best of both worlds; cal=
ling it AODVv2 is only not very sensible but avoids useful sensitivity arou=
nd 














names.














 














Thus I would strongly support Option 1), continue=
 the work that Charlie has started, which by the way is not far from co=
mpletion. And 














as WG,we need to remember that this had been the WG =
document, the result of years of work. Still by making it compatible with o=
ther options, 














this is technically flexible and sound.













 














Thanks.














 














JP.














 














On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:































Hello MANET working group (form Stan and Joe),



As you are all probably aware, there has been WG activity lately on competi=
ng drafts for a MANET reactive protocol - DYMO (reviving the current workin=
g group document that was parked due to inactivity), and LOADng. Many month=
s ago there was a somewhat authorship
 led movement towards a common document effort and given positive feedback =
at the time we the chairs thought this was the best approach given the auth=
ors potential to come together and gain the best of both efforts.  Sin=
ce that period, there has been some fairly
 strident and rancorous "at times" debate between the authors of =
the two documents.



During IETF 84 in Vancouver, the co-chairs held a discussion with some of t=
he co-authors of the two documents. Our guidance to the co-authors was to f=
ind a way to merge the two documents into one, as it was perceived that are=
 not technically far apart and they
 both derive roughly from AODV concepts and LOADng had fairly active author=
ship and implementation efforts. We provided a co-editing proposal to the a=
uthors and gave them the timeframe of the Atlanta to come up with an answer=
 back to us regarding this.  As
 of this writing, those discussions of a potential commonn document and aut=
horship merger have failed.



Therefore, we find ourselves at a crossroads. The authors of the two docume=
nts are divided, and it is unlikely that progress on a merged document can =
be reached based upon recent author feedback. I have also polled the earlie=
r WG editor of DYMO, Ian Chakeres,
 and he is somewhat disengaged on the issue at the present time.  We s=
ee only 3 possible paths forward:



1. Continue the work on the DYMO document, starting with whether there is c=
onsensus on its continued approach and also the desire to rename it to AODV=
v2.

2. Replace the existing DYMO document effort with the LOADng related docume=
nt effort, defusing ealier references to LLNs as recommended in the last me=
eting minutes, and to focus more motivationally on general MANET problem sp=
aces (the authors seem to have agreed
 to this issue if its a WG document).

3. Remove the working group charter for a reactive protocol, effectively ki=
lling both documents, at least from a working group (WG) standpoint. This w=
ould not be a reflection on the technology in either case, just an admissio=
n that we are not working together
 and reaching consensus.



The co-chairs request and need your opinions on the options.  We have =
been some silent collecting initial feedback and waiting for author feedbac=
k at this point.  Stan and I are both on travel prior to Atlanta so ou=
r responses may be sparse and we will also
 likely be in a "receive mode" for a few days.  So send your=
 opinions.



-Joe

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.or=
g/mailman/listinfo/manet












 












********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************=









 










 






--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB43F9GLKXM0002VGREEN_--

From Chris.Dearlove@baesystems.com  Wed Oct 31 10:36:09 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8580F21F8839 for ; Wed, 31 Oct 2012 10:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPtkAcUvtaly for ; Wed, 31 Oct 2012 10:36:08 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0EC21F8818 for ; Wed, 31 Oct 2012 10:36:08 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,687,1344207600"; d="scan'208";a="240073135"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 31 Oct 2012 17:36:06 +0000
Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VHa6Se004951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 17:36:06 GMT
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 17:36:06 +0000
From: "Dearlove, Christopher (UK)" 
To: "JP Vasseur (jvasseur)" , Ulrich Herberg 
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfShQ4AgAAEzgCAAIyAAIAAc4YAgAAXoACAAAzLIA==
Date: Wed, 31 Oct 2012 17:36:06 +0000
Message-ID: 
References:  <50906802.9070904@saloits.com>  <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:36:09 -0000

Do those have parallel AODV (v1 or v2) results as well?

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of J=
P Vasseur (jvasseur)
Sent: 31 October 2012 16:50
To: Ulrich Herberg
Cc: Timothy J. Salo; 
Subject: Re: [manet] Reactive Protocol Situation

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:

> Hi JP,
>>=20
>> Note that IETF cannot be driven by company roadmap.
>=20
> Then please let me hear your technical arguments. So far, you have been o=
nly saying that one protocol is in a "GREAT" shape, the other is not, and I=
 believe it is no secret that Cisco also has a company roadmap in this spac=
e.

Let's not go that route . this won't be productive. I am speaking as an ind=
ividual having spent years working on such issues
as many did too. What would you like ? Lots of experimental and simulation =
results showing why Load-NG will not work at
scale in LLN ?=20

>=20
> Best
> Ulrich
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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


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


From jblack.ietf@yahoo.com  Wed Oct 31 10:37:30 2012
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236B121F8805 for ; Wed, 31 Oct 2012 10:37:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXmjOTHlgViz for ; Wed, 31 Oct 2012 10:37:29 -0700 (PDT)
Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with ESMTP id E4AEA21F8661 for ; Wed, 31 Oct 2012 10:37:28 -0700 (PDT)
Received: from [98.139.212.145] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:37:28 -0000
Received: from [98.139.212.228] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:37:28 -0000
Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:37:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 232151.90015.bm@omp1037.mail.bf1.yahoo.com
Received: (qmail 46077 invoked by uid 60001); 31 Oct 2012 17:37:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351705048; bh=xZWQSf4q3Fot10xt2fs6X8M16Aw9DBFpX0fuLnWlN0M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=H26zyBk1KFddV0OLujAXqbQo7FS4+yoXTHnPoFv4Og3Uxtf1PntlypfT953I28F7a/iozCXlflGa3tg6aVxdBs7a0ufGHX4pYkIiRnumDq8xWSEfGe4jTWal+3RVEBClYLH+aQPqilX+Fk7YN+13UH+C8MvRoiIs6Q1iXtaXQtU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5DIS5+CzamW0BbxgawZY7+VeIzcsM3PGJbH4utVlLzxHSks7u8jGk+2TQ8QgRZiO5r59IFtxiCpv0H49ksX7K3R/2k1dHlEguS4PUl2EnvGaV5x4k7r/B5QfUbeMoxMsUQqM5VJc89k/c9silTcBOgYvYzgC4sZPF9c5OGmDGFk=;
X-YMail-OSG: PsPadTMVM1ljkcDFqM_kLOkK2wVfNemtTVpma.dt64hZgwl cQ1Th0GmC_T._N1nVTPicrNZLyYXVqCTfh5KsimJ_OiMxS_Dbk8DOXaURa.D zMFSM05xBWWqXHeEkZwImqKwjc4a2SOXelDgNcYCCjXWw5ZnWh6KbXWl9Ctf L3r9ALBLkITNhZQp_ZeyPDCW78ENYifJlyW_w_GYcIBczqBMxF7H4BaThegm QlPLtgd1wj7fti1HGOkThS8vVkVN_wSXj_qjbEoLU4t7NPti4gBF14Zo_Kwu 5_ZsAlieg6sKpiJG4CAF066dwIfHOy2X4SJddBaunG6BzRdjAL9A6ELDQJEl yePNNjhyDVRPcw6GG_dCfLtiEtFYZ4imugApdHmq0KpnM3.5qd5F7RwAPjiD TIbFelmqUuBV7Gm55R6Xhejc.fyJ349NVwgnAHwfDYAKxwTmuxpBNLjgnN_b Avz.bono3
Received: from [173.193.202.116] by web160604.mail.bf1.yahoo.com via HTTP; Wed, 31 Oct 2012 10:37:28 PDT
X-Rocket-MIMEInfo: 001.001, SXQgaXMgbm90IGNsZWFyIHRoYXQgb3B0aW9uIDEgaXMgYXQgYWxsIHRoZSBiZXN0IG9wdGlvbi7CoCBUaGlzIG5lZWRzIHRvIApiZSBkZWNpZGVkIGJhc2VkIG9uIHRlY2huaWNhbCBpbmZvcm1hdGlvbiwgcnVubmluZyBjb2RlLCBpbXBsZW1lbnRhdGlvbnMgYXZhaWxhYmxlLCAuLi4KCsKgwqDCoCBKb24KCgoKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKUCBWYXNzZXVyIChqdmFzc2V1cikgPGp2YXNzZXVyQGNpc2NvLmNvbT4KVG86IFVscmljaCBIZXJiZXJnIDx1bHJpY2gBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.123.460
References:  <50906802.9070904@saloits.com>  <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com>  <03B78081B371D44390ED6E7BADBB4A7722044E26@xmb-rcd-x02.cisco.com>
Message-ID: <1351705048.5596.YahooMailNeo@web160604.mail.bf1.yahoo.com>
Date: Wed, 31 Oct 2012 10:37:28 -0700 (PDT)
From: Jon Black 
To: "JP Vasseur \(jvasseur\)" , Ulrich Herberg 
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722044E26@xmb-rcd-x02.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-318397788-846459780-1351705048=:5596"
Cc: "Timothy J. Salo" , "" 
Subject: Re: [manet] Reactive Protocol Situation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Jon Black 
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2012 17:37:30 -0000

---318397788-846459780-1351705048=:5596
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

It is not clear that option 1 is at all the best option.=C2=A0 This needs t=
o =0Abe decided based on technical information, running code, implementatio=
ns available, ...=0A=0A=C2=A0=C2=A0=C2=A0 Jon=0A=0A=0A=0A=0A=0A=0A=0A______=
__________________________=0A From: JP Vasseur (jvasseur) =0ATo: Ulrich Herberg  =0ACc: Timothy J. Salo ; ""  =0ASent: Wednesday, Octo=
ber 31, 2012 11:21 AM=0ASubject: Re: [manet] Reactive Protocol Situation=0A=
 =0A=0AHi Ulrich, =0A=0AHere is what I would propose =E2=80=A6 The chairs a=
sked us a question, let's stick to it and wait for their guidance.=0AIf the=
 choice is to go with 1) then there is no point in having me sharing all re=
sults about why Load is ill suited=0Ato LLN, or for you to explain why it i=
s well suited (which by the way you never did either =E2=80=A6 you also kee=
p saying=0Athat it worked but we never got any technical results). If 2) is=
 chosen I will certainly clearly document with lots=0Aof information why I =
think there is a major issue with Load-ng in LLN.=0A=0AThat being said, I a=
m still hopeful that we will find a solution; options 1) knowing that Charl=
ie made it compatible=0Aseems to be by far the best option.=0A=0AThanks.=0A=
=0AJP.=0A=0A=0AOn Oct 31, 2012, at 6:11 PM, Ulrich Herberg wrote:=0A=0AHi J=
P,=0A>=0A>=0A>On Wed, Oct 31, 2012 at 9:49 AM, JP Vasseur (jvasseur)  wrote:=0A>=0A>=0A>>On Oct 31, 2012, at 4:25 PM, Ulrich Herbe=
rg wrote:=0A>>=0A>>> Hi JP,=0A>>>>=0A>>>> Note that IETF cannot be driven b=
y company roadmap.=0A>>>=0A>>> Then please let me hear your technical argum=
ents. So far, you have been only saying that one protocol is in a "GREAT" s=
hape, the other is not, and I believe it is no secret that Cisco also has a=
 company roadmap in this space.=0A>>=0A>>=0ALet's not go that route =E2=80=
=A6 this won't be productive.=0A>=0A>=0A>=0A>=0A>And this is what I asked y=
ou to be: productive, by providing technical arguments=0A>=0A>=0A>=C2=A0=0A=
>I am speaking as an individual having spent years working on such issues=
=0A>>as many did too. What would you like ? Lots of experimental and simula=
tion results showing why Load-NG will not work at=0A>>scale in LLN ?=0A>>=
=0A>=C2=A0=0A>=0A>=0A>This is not the point. It is a MANET protocol, otherw=
ise we would present it to the ROLL WG. As said before, LLNs are a special =
use case of MANETs in my opinion, and LOADng is as a matter of fact used in=
 such deployments, and these deployments are large-scale. You mentioned lot=
s of results and simulations showing that it will not work, but I have neve=
r seen these results. And as I said before, you can construct scenarios whe=
re a reactive protocol will not work, and others where it will work. MANET =
has long understood that and is therefore chartered to come up with a react=
ive and a proactive protocol.=0A>=0A>=0A>Regards=0A>Ulrich=0A=0A___________=
____________________________________=0Amanet mailing list=0Amanet@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/manet
---318397788-846459780-1351705048=:5596
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


It is not clear that =
option 1 is at all the best option.  This needs to =0Abe decided based=
 on technical information, running code, implementations=0A available, ...<=
br>
    Jon


=


  
 
 
  
  From: JP Vasseur (jvasseur) <jvasseur@cisco.com><=
br> To: Ulrich Herberg <=
;ulrich@herberg.name> 
Cc: Timothy J. Salo <salo@saloits.com>; "<manet@ietf.org>" &=
lt;manet@ietf.org> 
 Sent: Wednesday, October 31, 2012 11:21 AM
 Subject: Re: [manet] Reactive Protocol Situation

  
 
=0A
=0A=0A =0A=0A
=0AHi Ulrich,=0A
=0A
=0A
Here is what I would propose =E2=80=A6 The chairs asked u=
s a question, let's stick to it and wait for their guidance.
=0A
I=
f the choice is to go with 1) then there is no point in having me sharing a=
ll results about why Load is ill suited
=0A
to LLN, or for you to =
explain why it is well suited (which by the way you never did either =E2=80=
=A6 you also keep saying
=0A
that it worked but we never got any t=
echnical results). If 2) is chosen I will certainly clearly document with l=
ots
=0A
of information why I think there is a major issue with Loa=
d-ng in LLN.
=0A

=0A
=0A
That being said, I am still =
hopeful that we will find a solution; options 1) knowing that Charlie made =
it compatible
=0A
seems to be by far the best option.
=0A
=0A
=0A
Thanks.
=0A

=0A
=0A
JP.
=
=0A

=0A
=0A
On Oct 31, 2012, at 6:11 PM, Ulrich Herberg wro=
te:
=0A
=0AHi JP,
=0A
=0A
=
On Wed, Oct 31, 2012 at 9:49 AM, JP Vasseur (jvasseur) =
=0A<jvasseur@cisco.com> wrote:
=0A
=0A
=0A

=0AOn Oct 31, 2012, =
at 4:25 PM, Ulrich Herberg wrote:
=0A
=0A> Hi JP,
=0A>>=0A>> Note that IETF cannot be driven by company roadmap.
=0A>=
;
=0A> Then please let me hear your technical arguments. So far, you =
have been only saying that one protocol is in a "GREAT" shape, the other is=
 not, and I believe it is no secret that Cisco also has a company roadmap i=
n this space.
=0A
=0A
=0A
=0ALet's not go that route =E2=80=
=A6 this won't be productive.
=0A

=0A
=0A

=
=0A
=0A
And this is what I asked you to be: productive, by providi=
ng technical arguments
=0A

=0A
=0A
 
=0A=0AI am speaking as an individual h=
aving spent years working on such issues
=0Aas many did too. What would =
you like ? Lots of experimental and simulation results showing why Load-NG =
will not work at
=0Ascale in LLN ?
=0A
=0A
 =0A

=0A
=0A
This is not the point. It is a MANET protoco=
l, otherwise we would present it to the ROLL WG. As said before, LLNs are a=
 special use case of MANETs in my opinion, and LOADng is as a matter of fac=
t used in such deployments, and these deployments are large-scale.=0A You m=
entioned lots of results and simulations showing that it will not work, but=
 I have never seen these results. And as I said before, you can construct s=
cenarios where a reactive protocol will not work, and others where it will =
work. MANET has long understood=0A that and is therefore chartered to come =
up with a reactive and a proactive protocol.
=0A

=0A
=0A<=
div>Regards
=0A
Ulrich
=0A
=0A=0A
=0A<=
br>=0A
=0A
=0A=0A

_______________________________________________
man= et mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/mane= t


---318397788-846459780-1351705048=:5596-- From Chris.Dearlove@baesystems.com Wed Oct 31 10:39:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F027E21F87E7 for ; Wed, 31 Oct 2012 10:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p12Nd0CMPXi for ; Wed, 31 Oct 2012 10:39:02 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A32D421F87E1 for ; Wed, 31 Oct 2012 10:39:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,687,1344207600"; d="scan'208,217";a="282660709" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Oct 2012 17:39:01 +0000 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q9VHd03H021838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 17:39:00 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Wed, 31 Oct 2012 17:39:00 +0000 From: "Dearlove, Christopher (UK)" To: "JP Vasseur (jvasseur)" , Ulrich Herberg Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfShQ4AgAAEzgCAAIyAAIAAc4YAgAAXoACAAAY9gIAAAp6AgAAEYqA= Date: Wed, 31 Oct 2012 17:38:59 +0000 Message-ID: References: <50906802.9070904@saloits.com> <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722044A2A@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722044E26@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722044E26@xmb-rcd-x02.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4425GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "Timothy J. Salo" , "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:39:05 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4425GLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit That has the cart and the horse backwards. We don't make a decision, then see what results we have, we use results in trying to make good decisions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: 31 October 2012 17:21 To: Ulrich Herberg Cc: Timothy J. Salo; Subject: Re: [manet] Reactive Protocol Situation *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. Hi Ulrich, Here is what I would propose ... The chairs asked us a question, let's stick to it and wait for their guidance. If the choice is to go with 1) then there is no point in having me sharing all results about why Load is ill suited to LLN, or for you to explain why it is well suited (which by the way you never did either ... you also keep saying that it worked but we never got any technical results). If 2) is chosen I will certainly clearly document with lots of information why I think there is a major issue with Load-ng in LLN. That being said, I am still hopeful that we will find a solution; options 1) knowing that Charlie made it compatible seems to be by far the best option. Thanks. JP. On Oct 31, 2012, at 6:11 PM, Ulrich Herberg wrote: Hi JP, On Wed, Oct 31, 2012 at 9:49 AM, JP Vasseur (jvasseur) > wrote: On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote: > Hi JP, >> >> Note that IETF cannot be driven by company roadmap. > > Then please let me hear your technical arguments. So far, you have been only saying that one protocol is in a "GREAT" shape, the other is not, and I believe it is no secret that Cisco also has a company roadmap in this space. Let's not go that route ... this won't be productive. And this is what I asked you to be: productive, by providing technical arguments I am speaking as an individual having spent years working on such issues as many did too. What would you like ? Lots of experimental and simulation results showing why Load-NG will not work at scale in LLN ? This is not the point. It is a MANET protocol, otherwise we would present it to the ROLL WG. As said before, LLNs are a special use case of MANETs in my opinion, and LOADng is as a matter of fact used in such deployments, and these deployments are large-scale. You mentioned lots of results and simulations showing that it will not work, but I have never seen these results. And as I said before, you can construct scenarios where a reactive protocol will not work, and others where it will work. MANET has long understood that and is therefore chartered to come up with a reactive and a proactive protocol. Regards Ulrich ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4425GLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

That has the cart and the horse backwards. We don't make a decision, then see what results we have, we use results in trying to make good decisions.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 17:21
To: Ulrich Herberg
Cc: Timothy J. Salo; <manet@ietf.org>
Subject: Re: [manet] Reactive Protocol Situation

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Hi Ulrich,

 

Here is what I would propose … The chairs asked us a question, let's stick to it and wait for their guidance.

If the choice is to go with 1) then there is no point in having me sharing all results about why Load is ill suited

to LLN, or for you to explain why it is well suited (which by the way you never did either … you also keep saying

that it worked but we never got any technical results). If 2) is chosen I will certainly clearly document with lots

of information why I think there is a major issue with Load-ng in LLN.

 

That being said, I am still hopeful that we will find a solution; options 1) knowing that Charlie made it compatible

seems to be by far the best option.

 

Thanks.

 

JP.

 

On Oct 31, 2012, at 6:11 PM, Ulrich Herberg wrote:



Hi JP,

On Wed, Oct 31, 2012 at 9:49 AM, JP Vasseur (jvasseur) <jvasseur@cisco.com> wrote:


On Oct 31, 2012, at 4:25 PM, Ulrich Herberg wrote:

> Hi JP,
>>
>> Note that IETF cannot be driven by company roadmap.
>
> Then please let me hear your technical arguments. So far, you have been only saying that one protocol is in a "GREAT" shape, the other is not, and I believe it is no secret that Cisco also has a company roadmap in this space.

Let's not go that route … this won't be productive.

 

 

And this is what I asked you to be: productive, by providing technical arguments

 

 

I am speaking as an individual having spent years working on such issues
as many did too. What would you like ? Lots of experimental and simulation results showing why Load-NG will not work at
scale in LLN ?

 

 

This is not the point. It is a MANET protocol, otherwise we would present it to the ROLL WG. As said before, LLNs are a special use case of MANETs in my opinion, and LOADng is as a matter of fact used in such deployments, and these deployments are large-scale. You mentioned lots of results and simulations showing that it will not work, but I have never seen these results. And as I said before, you can construct scenarios where a reactive protocol will not work, and others where it will work. MANET has long understood that and is therefore chartered to come up with a reactive and a proactive protocol.

 

Regards

Ulrich

 


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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB4425GLKXM0002VGREEN_-- From jblack.ietf@yahoo.com Wed Oct 31 10:48:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349221F87F1 for ; Wed, 31 Oct 2012 10:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8P4u7DZl42x for ; Wed, 31 Oct 2012 10:48:53 -0700 (PDT) Received: from nm32-vm2.bullet.mail.bf1.yahoo.com (nm32-vm2.bullet.mail.bf1.yahoo.com [72.30.239.138]) by ietfa.amsl.com (Postfix) with ESMTP id 463CC21F87DF for ; Wed, 31 Oct 2012 10:48:53 -0700 (PDT) Received: from [98.139.212.150] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:48:49 -0000 Received: from [98.139.212.224] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:48:49 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:48:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 528193.57022.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 66162 invoked by uid 60001); 31 Oct 2012 17:48:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351705729; bh=AdLa9Ihhln473KFOx5z1WDvX2/navrLY+cwW/Pz8beU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=D99fLP/r6WffDtnDePOnr8GDBOLmLbJXqCAB1ETRKpJ1nCK/61aaeRM253VIu9dAHCc1pQ0KoaccQxuL/I14WspnM87ROES2tBws7YP964BOkz9cDKR04fm1LRLRyMS5C9yiv6AzLwfk772I1T4SK8bjbegHxgdQdruvD7Hb7lg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=U/EDivOMA88E8GWu7xAcVruBB/pODqeHWQd+wAsz5ieqTyIPFfgvhSESH9/Icb0HQwsye+Yq/h4vBjm6ZE5gsyofBpf6/qTsDO0YC2Z/86o7JpH7/813mZCnPfu1nj1H+Ci0jMmH2LT9g/pWAFemhKWhbna1mpu47Bh7CxiixHc=; X-YMail-OSG: jFn3bxkVM1mlMweVcuyuwi9YRp42XIAjhshLG6PeEasVAF. VDLUQdUhLHkySaRd7sMlWYpaOrQMRxCIfkM_Guke6owgzB1gZ6ECsVAKxVz7 gmF3WBpau7PQ74m7ILCvBS.4nkbTi0uDT.RsxP0qWT3WJcMcRvzvVvhJl0fx XZ96kDJvcJ1EoGDAj9PiL3kbeAG1f19rCAy_w8dSipr3hQ.jibvQGOjt3wBX sLua4NZzMhbE6iLiVOw7xcHwlzoXQlH8w_TwjiD0fwkEEN7tNjneTa56nxuZ 0cKOz5PjszYPnCmiRslq0JdzkJ70zFz4j.sNGCMZ0aHouEfWsN_DPI6bSCCc oyImFxQPzft7eONPsYMHbyt5dVfTKQKmC2oDobTE5Bvgykuq00_Hoxfw.tYC WQc1apty9VBYWIVofApSvRDFZsiD963V3S2WfAj21w.mS9w-- Received: from [173.193.202.116] by web160603.mail.bf1.yahoo.com via HTTP; Wed, 31 Oct 2012 10:48:49 PDT X-Rocket-MIMEInfo: 001.001, Q2VydGFpbmx5c21hcnQgbWV0ZXJzIGFyZSBvbmUgb2YgdGhlIHR5cGVzIG9mIG5ldHdvcmtzIHRoYXQgYXJlIE1BTkVUcy7CoCBKdXN0IGJlY2F1c2UgaG91c2VzIGRvIG5vdCBtb3ZlIGl0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGUgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhvc2UgbWV0ZXJzIGlzbid0IGNoYW5naW5nLsKgIEEgc21hcnQgbWV0ZXIgbmV0d29yayBpcyBtb3N0IGNlcnRhaW5seSBhIE1BTkVULsKgIFtPbmUgY291bGQgYXJndWUgdGhhdCBpdCBpcyBub3QgYW4gTExOIHNpbmNlIGF0IGxlYXN0IGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 Message-ID: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Wed, 31 Oct 2012 10:48:49 -0700 (PDT) From: Jon Black To: "manet@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-584761625-1351705729=:64800" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:48:54 -0000 --1886287700-584761625-1351705729=:64800 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Certainlysmart meters are one of the types of networks that are MANETs.=A0 = Just because houses do not move it does not mean that the connectivity betw= een those meters isn't changing.=A0 A smart meter network is most certainly= a MANET.=A0 [One could argue that it is not an LLN since at least from the= electrical power there is no lack of power.]=0A=0ATotally agree that one s= ize does not fit all.=0A=0A=A0 Jon=0A=0A=0AOn October 31, 2012 John.Dowdell= wrote:=0A=0AWhile I am very pleased for you and your=0Aco-authors that the= LOADng work has been so fruitful, I am not really sure that=0Asmart meters= are really the kind of MANET devices that the working group was=0Aintended= to address. I have been party to the conversations for only a year or two,= =0Aso I am very happy to be corrected by those with longer histories, but M= ANET to=0Ame means dynamically moving nodes, with links being established a= nd broken often=0Aand without prior warning. Examples may be communications= networks built out of=0Anodes contained in cars, trucks and aircraft of al= l sizes. I appreciate a=0Acomment on the list a while back that the RF envi= ronment for smart metering is=0Aactually more difficult than one would thin= k, but I would suggest to the chairs=0Athat unless LOADng has applications = in this dynamically mobile environment (and=0AI have to admit I have not re= ad the spec in enough detail to determine if this=0Ais the case), then we c= ome to the conclusion that the DYMO/AODVv2 path should=0Abe followed unless= we collectively feel that such a direction is not worth=0Apursuing (and no= te I am definitely not proposing that view).=0A=A0=0AIn the two years or so= that I have been=0Aworking with MANETs, the only conclusion I have come to= is that very many use=0Acases exist, and that one size does not fit all.= =0A=A0=0ARegards=0A=A0=0AJohn --1886287700-584761625-1351705729=:64800 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
C= ertainly smart meters are one of the types= of networks that are MANETs.  Just because houses do not move it does not mean= that the connectivity between those meters isn't changing.  A smart m= eter network is most certainly a MANET.&nb= sp; [One could argue that it is not an LLN sof power.]

Totally agr= ee that one size does not fit all.<= /span>

 = Jon

<= font color=3D"blue" face=3D"Arial" size=3D"3">On October 31, 2012 John.Dowdell wrote:=

While I am v= ery pleased for you and your=0Aco-authors that the LOADng work has been so = fruitful, I am not really sure that=0Asmart meters are really the kind of M= ANET devices that the working group was=0Aintended to address. I have been = party to the conversations for only a year or two,=0Aso I am very happy to = be corrected by those with longer histories, but MANET to=0Ame means dynami= cally moving nodes, with links being established and broken often=0Aand wit= hout prior warning. Examples may be communications networks built out of=0A= nodes contained in cars, trucks and aircraft of all sizes. I appreciate a= =0Acomment on the list a while back that the RF environment for smart meter= ing is=0Aactually more difficult than one would think, but I would suggest = to the chairs=0Athat unless LOADng has applications in this dynamically mob= ile environment (and=0AI have to admit I have not read the spec in enough d= etail to determine if this=0Ais the case), then we come to the conclusion t= hat the DYMO/AODVv2 path should=0Abe followed unless we collectively feel t= hat such a direction is not worth=0Apursuing (and note I am definitely not = proposing that view).
=0A=0A
 
=0A=0A
<= font color=3D"blue" face=3D"Arial" size=3D"3">In the two years or so that I have been= =0Aworking with MANETs, the only conclusion I have come to is that very man= y use=0Acases exist, and that one size does not fit all.=0A=0A
 
=0A=0A
Reg= ards
=0A=0A
 
=0A= =0A=0A=0A
John


--1886287700-584761625-1351705729=:64800-- From jblack.ietf@yahoo.com Wed Oct 31 10:57:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D91C21F87FC for ; Wed, 31 Oct 2012 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvFABvLMQBLy for ; Wed, 31 Oct 2012 10:57:45 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 28BE221F8834 for ; Wed, 31 Oct 2012 10:57:44 -0700 (PDT) Received: from [98.139.214.32] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:57:43 -0000 Received: from [98.139.212.226] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:57:43 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 17:57:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 304525.380.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 12368 invoked by uid 60001); 31 Oct 2012 17:57:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351706263; bh=ypzo60AW944YpBsMJ0LPJb5M16SgyD79cMXZ7I3Xwn8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:Cc:MIME-Version:Content-Type; b=BArZzN0AABN9it/GkPmtt+aQwDbgCw1i474NuVjHNTyuufZT2ZV3rA7F4e6XDvFpEH+/uu/iXg+x+Kipu5/5TJjm+K26foeHyrin++6uI3uGStNPpMLapgRbCSzLibeKs66H4yrmUTMULUcV+hKwVvcyd88tWEdOgd4CA5CE9Ls= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:Cc:MIME-Version:Content-Type; b=LzsTMpU/BRaHtNa2LQJTSeHNc7Yq8g5SMQAw2puH1n66/mtIJFNhqpJukTx3luUL24BT2LioGNkJmVW77hPkjkyPvFPy44GKVOkrvK768hb5Q/RjwogmKnaSgOnOpjw7DKHy1Q2fp8sbLMdcb+yCrRxzdKlJSqpmvgWDkx4nQj4=; X-YMail-OSG: kXLktaQVM1mnc4IP3Ka57_tw.pPV1vKbK5OlqkreRw4fJSC 2NcZbyx54IJUNxMqb5SihOu1Mz8iVLEjP7QlZFE8XC_XlUZyewQuvoWzLBmH AvyIcHaJ287eXxHRL8jhG48KZ8QQ9O1cJLBQsHtVnBuK95op9TH5w1.Ie3BK Q4zwlvTWX25.yRymhcnxnYB3tW2d1AqH5qhp98Hc_a92ypvDR_GmvVh7Hzvd 5oFhO_vnIpQhG1ou.8YS1pNOF7XiJ86FjDW5dgdYtdMJeUpY42mTFpUmLyve buwHLtrvFhY1lvMB.rB8YNnXwa_a7sEKa2jvbNvy.HdUnMr5tDtU83Gjq2uk KUHt5zockqxDlewHNv02zMaa_umPXNduljZ59STGbSLK1.llxtdU3.3Fxuw5 i5EB3K1sCdiRPfFleEKWYejh3h9UKHuhHhx5406hsjI.RKAU- Received: from [173.193.202.116] by web160601.mail.bf1.yahoo.com via HTTP; Wed, 31 Oct 2012 10:57:43 PDT X-Rocket-MIMEInfo: 001.001, T24gT2N0b2JlciAzMSwgMjAxMiBUaGllcnJ5Lkx5cyB3cm90ZToKCkkgc3BlYWsgaW4gdGhlIG5hbWUgb2YgRURGIGdyb3VwLiAgCgpXZSBzdGFydGVkIGZpcnN0IHRvIHVzZSBMT0FEIGFzIGEgcm91dGluZwphbGdvcml0aG0gYW5kIGRlcGxveWVkIDIwMDAgUExDLW1ldGVycyBmb3Igc21hcnQgZ3JpZCBwdXJwb3NlcyBpbiAyMDExLgpUYWtpbmcgYWR2YW50YWdlIG9mIHRoaXMgZmllbGQgdGVzdCwgd2UgaGF2ZSBiZWVuIGFjdGl2ZWx5IHBhcnRpY2lwYXRpbmcKdG8gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gYWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 Message-ID: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> Date: Wed, 31 Oct 2012 10:57:43 -0700 (PDT) From: Jon Black To: "manet@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1737431079-84039893-1351706263=:11550" Cc: "thierry.lys@erdfdistribution.fr" Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:57:45 -0000 --1737431079-84039893-1351706263=:11550 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On October 31, 2012 Thierry.Lys wrote:=0A=0AI speak in the name of EDF grou= p. =0A=0AWe started first to use LOAD as a routing=0Aalgorithm and deploye= d 2000 PLC-meters for smart grid purposes in 2011.=0ATaking advantage of th= is field test, we have been actively participating=0Ato the working group t= o adopt enhancements in the LOADng specification. =0AWe are now extremely p= leased with what=0ALOADng is capable of and are confident that future deplo= yements will be=0Aequipped with it.=A0=0A=0AThis would seem to indicate tha= t LOADng does work and in a rather large deployment.=0A=0A=0A"We believe in= rough consensus=0Aand running code" =0A=0Arough consensus : Don't you thin= k we=0Ahave a rough consensus on LOADng compared to DYMO ? 10 authors and m= ajor=0Acompanies are supporters of LOADng. =0A=0Arunning code : interopera= bility has=0Abeen checked with 4 sources and other implementations are in p= rogress. =0A=0AObviously from the list we don't have rough consensus.=A0 We= have two alternatives each with proponents.=A0 The WG should weigh the tec= hnical benefits (design, implementation/running code, maturity)=A0 of each = and the group should choose a path forward.=0A=0AIn my opinion option 3 is = not an option - this is the working group shirking its responsibility.=0A= =0AJon --1737431079-84039893-1351706263=:11550 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
On October 31, 2= 012 Thierry.Lys wrote:

I speak in the name of EDF group. =0A=0A
We started first to use LOAD = as a routing=0Aalgorithm and deployed 2000 PLC-meters for smart grid purpos= es in 2011.=0ATaking advantage of this field test, we have been actively pa= rticipating=0Ato the working group to adopt enhancements in the LOADng spec= ification.=0A
We are now ext= remely pleased with what=0ALOADng is capable of and are confident that futu= re deployements will be=0Aequipped with it. 

This would seem to indicat= e that LOADng does work and in a rather large deployment.
=0A
"We believe in rough consensus=0Aand runn= ing code"=0A
=0A
rough co= nsensus : Don't you think we=0Ahave a rough consensus on LOADng compared to= DYMO ? 10 authors and major=0Acompanies are supporters of LOADng. = =0A
=0A
running code : interoper= ability has=0Abeen checked with 4 sources and other implementations are in = progress.=0A
=0A

" Content-Type: multipart/alternative; boundary=20cf30780a7211860804cd5ede05 Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:14:06 -0000 --20cf30780a7211860804cd5ede05 Content-Type: text/plain; charset=ISO-8859-1 Certainly if the LOADng derived work in whatever form is accepted by manet it needs to be considered a manet protocol and analyzed and designed as such in ongoing work. This point is non-negotiable and I think the chairs made that clear at the last meeting but just to reiterate the point so we do not need to keep going over that. -------- Jiazi: As one chair, given my two year old review I felt DYMO-21 needed significant work and revision to be ready for STD track submission. If you feel DYMO-23 has regressed in some way in terms of clarity or specification that makes me uneasy but I have less personal insight on that at present to discuss. So other opinions would be welcome perhaps from an implementor's perspective and a non-LOADng author's view. On Wed, Oct 31, 2012 at 1:34 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > That I think has moved the goalposts. The issue is not whether LOADng is > suitable in an LLN, because we are designing here a more general purpose > MANET routing protocol. So in the MANET WG, the issue of whether suitable > for LLNs in particular principally affects any claimed use cases, rather > than being a key differentiator.**** > > ** ** > > That said, technical arguments are always of interest, and may shed > interesting light, particularly if you are suggesting there is a major > difference in some regard between the two candidates.**** > > ** ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] > *Sent:* 31 October 2012 16:47 > > *To:* Dearlove, Christopher (UK) > *Cc:* Joseph Macker; > *Subject:* Re: [manet] Reactive Protocol Situation**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how to deal with suspicious emails. > ***** > > ** ** > > On Oct 31, 2012, at 4:11 PM, Dearlove, Christopher (UK) wrote:**** > > > > **** > > I take it those are two separate sentences. You can agree with me, and you > can support 1. But you can't agree with me supporting 1, as I haven't (nor > have I supported 2).**** > > **** > > ** ** > > I was agreeing on the fact that there was work to be done. Still strongly > advocating for the option1, especially since Charlie is**** > > working to make compatibility.**** > > > > **** > > As indicated, I would like to hear the technical arguments you have > against LOADng. Here on list would seem the best place.**** > > **** > > ** ** > > I am more than happy to share lots of results showing why LOAD-ng may be a > severe issue for LLNs, since this was mentioned**** > > as a clear use cases in the LOAD-ng document.**** > > > > **** > > --**** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > **** > > *From:* JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] > *Sent:* 31 October 2012 14:03 > *To:* Dearlove, Christopher (UK) > *Cc:* Joseph Macker; > *Subject:* Re: [manet] Reactive Protocol Situation**** > > **** > > **** > > **** WARNING ******** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this process > on how to deal with suspicious emails.***** > > Completely agreeing with you. 1) with some work needed, as agreed by > Charlie.**** > > **** > > JP.**** > > **** > > On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher (UK) wrote:**** > > > > > **** > > As someone who has not (yet) stated an opinion on the matter, except I > also think option 3 is not good, I would very much like to hear technical > arguments, so if you have technical arguments against LOADng, I think we > need to hear them rather than just suggesting they exist. I haven't yet > read LOADng carefully to form a view there. I have just recently read the > AODVv2 draft carefully, and have some technical issues there (which > overlap) regarding asymmetric links, possible dependency on NHDP, and the > compatibility of options. If option 1 is followed, the draft needs work > (which Charlie has acknowledged).**** > > **** > > --**** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > **** > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *JP Vasseur (jvasseur) > *Sent:* 31 October 2012 08:29 > *To:* Joseph Macker > *Cc:* > *Subject:* Re: [manet] Reactive Protocol Situation**** > > **** > > **** > > **** WARNING ******** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this process > on how to deal with suspicious emails.***** > > Dear chairs,**** > > **** > > Remembering that I am not a co-authors of either of these drafts.**** > > **** > > *Not commenting on recent discussions but rather focussing on what I hope > will be a good solution for the WG and the Internet at large.***** > > **** > > Option 3) is my opinion *not* desirable; I wish we could have a reactive > routing protocol for MANET**** > > **** > > Option 2) is an option I would be *strongly* opposed to for a number of > technical reasons that I would be happy to elaborate on the**** > > mailing list and/or in a new I-D (which I would, should option 2 be > chosen).**** > > **** > > That being said, *I am extremely supportive of option 1)*, *especially in > light of what Charlie said*. First of all DYMO is the working group**** > > document and excellent progress has been made with recent revisions. But > even more importantly, Charlie managed to make it compatible **** > > with options, which is in my opinion *the best of both worlds*; calling > it AODVv2 is only not very sensible but avoids useful sensitivity around * > *** > > names.**** > > **** > > *Thus I would strongly support Option 1), continue the work that Charlie > has started*, which by the way is not far from completion. And **** > > as WG,we need to remember that this had been the WG document, the result > of years of work. Still by making it compatible with other options, **** > > this is technically flexible and sound.**** > > **** > > Thanks.**** > > **** > > JP.**** > > **** > > On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:**** > > > > > > **** > > Hello MANET working group (form Stan and Joe), > > As you are all probably aware, there has been WG activity lately on > competing drafts for a MANET reactive protocol - DYMO (reviving the current > working group document that was parked due to inactivity), and LOADng. Many > months ago there was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the chairs > thought this was the best approach given the authors potential to come > together and gain the best of both efforts. Since that period, there has > been some fairly strident and rancorous "at times" debate between the > authors of the two documents. > > During IETF 84 in Vancouver, the co-chairs held a discussion with some of > the co-authors of the two documents. Our guidance to the co-authors was to > find a way to merge the two documents into one, as it was perceived that > are not technically far apart and they both derive roughly from AODV > concepts and LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and gave them the > timeframe of the Atlanta to come up with an answer back to us regarding > this. As of this writing, those discussions of a potential commonn > document and authorship merger have failed. > > Therefore, we find ourselves at a crossroads. The authors of the two > documents are divided, and it is unlikely that progress on a merged > document can be reached based upon recent author feedback. I have also > polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat > disengaged on the issue at the present time. We see only 3 possible paths > forward: > > 1. Continue the work on the DYMO document, starting with whether there is > consensus on its continued approach and also the desire to rename it to > AODVv2. > 2. Replace the existing DYMO document effort with the LOADng related > document effort, defusing ealier references to LLNs as recommended in the > last meeting minutes, and to focus more motivationally on general MANET > problem spaces (the authors seem to have agreed to this issue if its a WG > document). > 3. Remove the working group charter for a reactive protocol, effectively > killing both documents, at least from a working group (WG) standpoint. This > would not be a reflection on the technology in either case, just an > admission that we are not working together and reaching consensus. > > The co-chairs request and need your opinions on the options. We have been > some silent collecting initial feedback and waiting for author feedback at > this point. Stan and I are both on travel prior to Atlanta so our > responses may be sparse and we will also likely be in a "receive mode" for > a few days. So send your opinions. > > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet**** > > **** > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ************************************************************************ > > **** > > ** ** > --20cf30780a7211860804cd5ede05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Certainly if the LOADng derived work in whatever form is accepted by manet = it needs to be considered a manet protocol and analyzed and designed as suc= h in ongoing work.=A0 This point is non-negotiable and I think the chairs m= ade that clear at the last meeting but just to reiterate the point so we do= not need to keep going over that.
--------

Jiazi: As one chair, given my two year old review I felt DY= MO-21 needed significant work and revision to be ready for STD track submis= sion. If you feel DYMO-23 has regressed in some way in terms of clarity or = specification that makes me uneasy but I have less personal insight on that= at present to discuss. So other opinions would be welcome perhaps from an = implementor's perspective and a non-LOADng author's view.






On Wed, Oct 31, 2012 at 1:34 PM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

That I think has moved th= e goalposts. The issue is not whether LOADng is suitable in an LLN, because= we are designing here a more general purpose MANET routing protocol. So in the MANET WG, the issue of whether suitable for LLNs in pa= rticular principally affects any claimed use cases, rather than being a key= differentiator.

=A0<= /p>

That said, technical argu= ments are always of interest, and may shed interesting light, particularly = if you are suggesting there is a major difference in some regard between the two candidates.

=A0<= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0<= /p>

From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
Sent: 31 October 2012 16:47


To: Dearlove, Christopher (UK)
Cc: Joseph Macker; <manet@ietf.org>
Subject: Re: [manet] Reactive Protocol Situation
=

=A0

=A0

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

=A0

On Oct 31, 2012, at 4:11 PM, Dearlove, Christopher (= UK) wrote:



I take it those are two s= eparate sentences. You can agree with me, and you can support 1. But you ca= n't agree with me supporting 1, as I haven't (nor have I supported 2).

=A0<= /p>

=A0

I was agreeing on the fact that there was work to be= done. Still strongly advocating for the option1, especially since Charlie = is

working to make compatibility.



As indicated, I would lik= e to hear the technical arguments you have against LOADng. Here on list wou= ld seem the best place.

=A0<= /p>

=A0

I am more than happy to share lots of results showin= g why LOAD-ng may be a severe issue for LLNs, since this was mentioned

as a clear use cases in the LOAD-ng document.=



--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com=A0|= =A0htt= p://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0<= /p>

From:= =A0JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]=A0
Sent:=A031 October 2012 14:03
To:=A0Dearlove, Christopher (UK)
Cc:=A0Joseph Macker; <manet@ietf.org>
Subject:=A0Re: [manet] Reactive Protocol Situation

=A0

=A0

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see=A0this process=A0on how to deal with suspicious emails= .

Completely agreeing with you. 1) with some work need= ed, as agreed by Charlie.

=A0

JP.

=A0

On Oct 31, 2012, at 11:02 AM, Dearlove, Christopher = (UK) wrote:




As someone who has not (y= et) stated an opinion on the matter, except I also think option 3 is not go= od, I would very much like to hear technical arguments, so if you have technical arguments against LOADng, I think we need to hear= them rather than just suggesting they exist. I haven't yet read LOADng= carefully to form a view there. I have just recently read the AODVv2 draft= carefully, and have some technical issues there (which overlap) regarding asymmetric links, possible dependen= cy on NHDP, and the compatibility of options. If option 1 is followed, the = draft needs work (which Charlie has acknowledged).

=A0<= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com=A0|= =A0htt= p://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0<= /p>

From:= =A0manet-bounces@ietf.= org=A0[mailto:manet-bounces@ietf.org]=A0On Behalf Of=A0JP Vasseur (jvasseur)
Sent:=A031 October 2012 08:29
To:=A0Joseph Macker
Cc:=A0<manet@ietf.org>
Subject:=A0Re: [manet] Reactive Protocol Situation

=A0

=A0

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see=A0this process=A0on how to deal with suspicious emails= .

Dear chairs,

=A0

Remembering that I am not a co-authors of either of = these drafts.

=A0

Not commenting on recent discussions but rather f= ocussing on what I hope will be a good solution for the WG and the Internet= at large.

=A0

Option 3) is my opinion=A0not= =A0desirable; I wish we could have a reactive routing prot= ocol for MANET

=A0

Option 2) is an option I would be=A0= strongly=A0opposed to for a number of technical rea= sons that I would be happy to elaborate on the

mailing list and/or in a new I-D (which I would, sho= uld option 2 be chosen).

=A0

That being said,=A0I am extremely su= pportive of option 1),=A0especially in light of what Ch= arlie said. First of all DYMO is the working group

document and excellent progress has been made with r= ecent revisions. But even more importantly, Charlie managed to make it comp= atible=A0

with options, which is in=A0my opinion=A0the best of both worlds; calling it AODVv2 is only not very sensib= le but avoids useful sensitivity around=A0

names.

=A0

Thus I would strongly support Option 1), continue= the work that Charlie has started, which by the way is not far from co= mpletion. And=A0

as WG,we need to remember that this had been the WG = document, the result of years of work. Still by making it compatible with o= ther options,=A0

this is technically flexible and sound.

=A0

Thanks.

=A0

JP.

=A0

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:





Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.=A0 Since = that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.=A0 As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.=A0 We see = only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point.=A0 Stan and I are both on travel prior to Atlanta so our resp= onses may be sparse and we will also likely be in a "receive mode" for a few days.=A0 So send your op= inions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

=A0


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

=A0

=A0


--20cf30780a7211860804cd5ede05-- From charliep@computer.org Wed Oct 31 11:24:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FA21F87DE for ; Wed, 31 Oct 2012 11:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khielMX0hC0p for ; Wed, 31 Oct 2012 11:24:05 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2124E21F877C for ; Wed, 31 Oct 2012 11:24:05 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTcxQ-0007DG-E8 for manet@ietf.org; Wed, 31 Oct 2012 14:24:04 -0400 Message-ID: <50916CC0.7010900@computer.org> Date: Wed, 31 Oct 2012 11:24:00 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86bede6dee513a75c9161fdf90ea80c711350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: [manet] Reactive protocol terminology proposal X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:24:06 -0000 Hello folks, As mentioned previously, several people have expressed the opinion that the DYMO language needs a bit of improvement. One way to do that is to use terminology that is consistent, intuitive, and conforms with other terminology in common use. With that in mind, I would like to suggest the following terminology changes for AODVv2. Comments are welcome as always. There are some other changes in the document organization that would also be very helpful, but I will cover those in another message to the list. ========================================================== - A Route Table is a collection of Route Table Entries - Each Route Table Entry has the following data: * Destination Address * Prefix * Cost / Distance / Metric * Metric Type * Route Timeout (ROUTE_DELETE_TIMEOUT) * Next Hop * Sequence Number * Sequence Number Timeout (ROUTE_SEQNUM_AGE_MAX_TIMEOUT) - Each router keeps track of which neighbors have been blacklisted; each blacklist entry has the following data: * blacklisted neighbor IP address * blacklist entry timeout - Number of RREQs sent for a required destination - Own Sequence Number Terminology proposal: - Fields in incoming RREQs: IncomingRREQ. - Fields in outgoing RREQs: OutgoingRREQ. - Fields in incoming RREPs: IncomingRREP. - Fields in outgoing RREPs: OutgoingRREP. - Fields in incoming routing messages: IncomingRteMsg. - Fields in outgoing routing messages: OutgoingRteMsg. - Fields in incoming RERRs: IncomingRERR. - Fields in outgoing RERRs: OutgoingRERR. RREQs are sent by an Discovering Router to discover a route for a Target Node. RREPs are sent by a Target Router to a Discovering Router. RERRs are sent to Upstream Routers when a router discovers a broken next hop. If abbreviations are to be used, the following seem natural: TargRtr, DiscRtr, UpstRtr, TargNode ============================================================== -- Regards, Charlie P. From boberry@cisco.com Wed Oct 31 11:29:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2648021F8845 for ; Wed, 31 Oct 2012 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUKWC1xpk+Nx for ; Wed, 31 Oct 2012 11:29:42 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A90C21F8843 for ; Wed, 31 Oct 2012 11:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2861; q=dns/txt; s=iport; t=1351708181; x=1352917781; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=/mn2MvdBbzYWuF7jiYx5+2SD/ZCvN9yTKGpo3gGGQQA=; b=Qdgw/58m/b/uiR2Yya6W4Hd9bj3K6YUsIDDyBsMnuDbLmo8Nz0L7TY2Q OF7sgxKfao/AY2wYK6UUK4c6MV92oO6K6bnlg3NBTVJZwroEXiaiZ+2+p /uRrXFyrASINQsCxJen1m/yBH5MmlV63qKYTSeXPubMfXAmyJ3Hvu6pfU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANdskVBIo8UY/2dsb2JhbABExGGCHgEBAQIBAQEBAQ8BJzQQCwsYLicwBgESIodeBgubVqAdi3gbhT9hA5V2gRqNPYFrgws X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="20142499" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 31 Oct 2012 18:29:38 +0000 Received: from dhcp-64-102-54-132.cisco.com (dhcp-64-102-54-132.cisco.com [64.102.54.132]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9VITaDY022011; Wed, 31 Oct 2012 18:29:37 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Bo Berry In-Reply-To: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Wed, 31 Oct 2012 14:29:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> To: " List" , Jon Black X-Mailer: Apple Mail (2.1085) Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:29:43 -0000 For background and perspective, ran across these two docs on the origin=20= and performance of Loadng. The WG may find helpful. -Bo The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next = Generation (LOADng)=09 By T. Clausen. A. Colin de Verdiere.=20 Published in INRIA Research Report 7692 on 2011-07-25. = http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4c772= e5af46f426e77ca581.pdf A Comparative Performance Study of the Routing Protocols LOAD and RPL = with Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 By T. Clausen, U. Herberg.=20 Published in INRIA Research Report 7637 on 2011-06-01. = http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228cf68= 6a462108aef8332ceb.pdf On Oct 31, 2012, at 1:48 PM, Jon Black wrote: > Certainly smart meters are one of the types of networks that are = MANETs. Just because houses do not move it does not mean that the = connectivity between those meters isn't changing. A smart meter network = is most certainly a MANET. [One could argue that it is not an LLN since = at least from the electrical power there is no lack of power.] >=20 > Totally agree that one size does not fit all. >=20 > Jon >=20 > On October 31, 2012 John.Dowdell wrote: >=20 > While I am very pleased for you and your co-authors that the LOADng = work has been so fruitful, I am not really sure that smart meters are = really the kind of MANET devices that the working group was intended to = address. I have been party to the conversations for only a year or two, = so I am very happy to be corrected by those with longer histories, but = MANET to me means dynamically moving nodes, with links being established = and broken often and without prior warning. Examples may be = communications networks built out of nodes contained in cars, trucks and = aircraft of all sizes. I appreciate a comment on the list a while back = that the RF environment for smart metering is actually more difficult = than one would think, but I would suggest to the chairs that unless = LOADng has applications in this dynamically mobile environment (and I = have to admit I have not read the spec in enough detail to determine if = this is the case), then we come to the conclusion that the DYMO/AODVv2 = path should be followed unless we collectively feel that such a = direction is not worth pursuing (and note I am definitely not proposing = that view). > =20 > In the two years or so that I have been working with MANETs, the only = conclusion I have come to is that very many use cases exist, and that = one size does not fit all. > =20 > Regards > =20 > John >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Wed Oct 31 11:34:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFC321F8876 for ; Wed, 31 Oct 2012 11:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22ndogQPVnuB for ; Wed, 31 Oct 2012 11:34:47 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 31A4B21F8874 for ; Wed, 31 Oct 2012 11:34:47 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTd7m-0003q8-Gg; Wed, 31 Oct 2012 14:34:46 -0400 Message-ID: <50916F40.3000804@computer.org> Date: Wed, 31 Oct 2012 11:34:40 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Joseph Macker , "" References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8609d8bae8cb8378cb281c8662305eba3f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:34:47 -0000 Hello Joe and all, Thanks for reiterating this important point. I feel that some of the discussion is aimed at finding fault. For myself, I think that the LOADng effort has made a positive contribution. With some minor exceptions, LOADng is basically compatible with AODVv2 (almost by design, since both were derived from AODV). I reiterate that my goal for the WG reactive document would be to retain compatibility with LOADng. In this way, the working group will retain the benefits of LOADng (by design), reducing the need for any mutually exclusive choice of (1) or (2). I'd call this alternative (1.5). In the meantime, I continue to offer improvements to the existing AODVv2 specification, and I am confident that the results will soon satisfy the most demanding level of scrutiny. Regards, Charlie P. On 10/31/2012 11:14 AM, Joseph Macker wrote: > Certainly if the LOADng derived work in whatever form is accepted by > manet it needs to be considered a manet protocol and analyzed and > designed as such in ongoing work. This point is non-negotiable and I > think the chairs made that clear at the last meeting but just to > reiterate the point so we do not need to keep going over that. > -------- > -- Regards, Charlie P. From jpmacker@gmail.com Wed Oct 31 11:37:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6838021F887B for ; Wed, 31 Oct 2012 11:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leKvuDaNnnyV for ; Wed, 31 Oct 2012 11:37:03 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 642FC21F87E2 for ; Wed, 31 Oct 2012 11:37:03 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2083956vbb.31 for ; Wed, 31 Oct 2012 11:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3dDJbm+gqykGWNRZ2nD4DEgpvpL9abrXVdaAXRkpJ4w=; b=Hg2UpaezgQ8AGbsK6Uc5wmUiqhhsQFuvMGQqLUBjDaVzGuO2s76PCkYmgkm5BXuXKN vvTqagXka2HhpUw7ArFe2I1NXz50DllbGiRaH/kx7KoVr59CtcPIhURzL4MjMtAvgxjA 6q/c6tbyoXcFT4sWS6zaMe+UzLJEOiqLpbCZyC1pubbxXwfYivfUVjJcr3wFAZLon2nN VsIDfK5Qxn0dhPm6V5x5V1JKDNjINmuaRQrj5DeildqAWN6gUfu5lPPt/9nyCUtEXGNX Sl4SBBBz6YiMbP/ZwrjTqiJiiLX4VsmNcVVDE/L8/Ru8L3QcvHSr/lrnU86CsWTcF7LE Qzig== MIME-Version: 1.0 Received: by 10.52.70.115 with SMTP id l19mr49782418vdu.127.1351708622667; Wed, 31 Oct 2012 11:37:02 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Wed, 31 Oct 2012 11:37:02 -0700 (PDT) In-Reply-To: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> Date: Wed, 31 Oct 2012 14:37:02 -0400 Message-ID: From: Joseph Macker To: Jon Black Content-Type: multipart/alternative; boundary=20cf307abd034b3e0804cd5f3028 Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:37:04 -0000 --20cf307abd034b3e0804cd5f3028 Content-Type: text/plain; charset=ISO-8859-1 Jon: You make some good points in the technical category if we are to not choose (3). Perhaps people could provide input and discussion in these areas more as a guide. I realize these designs are not finalized and would evolve as part of the WG process but it would give us a better idea on the starting line. Design: Does it have the features we require of a modernized MANET protocol? Does it perform well as a MANET protocol? Are its features well-specified and clear to implement it both in an effective and interoperable manner? Of course this is an evolving process since the WG will have some ownership of the design. Extensible? Implementation/Running Code: Always a benefit and gives community a chance to test features and report,etc. Confidence in going forward on STD track path. Need some manet-oriented results to gain confidence in operational modes under particular expected scenarios. Also a beneficial if there is prototype open source version available to broaden the exposure and experimentation. Interops,etc ? Maturity: Has it been used or gone through relevant use cases. Are any algorithms or subprocesses well understood (goes along with design in that sense)? On Wed, Oct 31, 2012 at 1:57 PM, Jon Black wrote: > On October 31, 2012 Thierry.Lys wrote: > > I speak in the name of EDF group. > > We started first to use LOAD as a routing algorithm and deployed 2000 > PLC-meters for smart grid purposes in 2011. Taking advantage of this field > test, we have been actively participating to the working group to adopt > enhancements in the LOADng specification. > We are now extremely pleased with what LOADng is capable of and are > confident that future deployements will be equipped with it. > > This would seem to indicate that LOADng does work and in a rather large > deployment. > > "We believe in rough consensus and running code" > > rough consensus : Don't you think we have a rough consensus on LOADng > compared to DYMO ? 10 authors and major companies are supporters of LOADng. > > running code : interoperability has been checked with 4 sources and other > implementations are in progress. > > Obviously from the list we don't have rough consensus. We have two > alternatives each with proponents. The WG should weigh the technical > benefits (design, implementation/running code, maturity) of each and the > group should choose a path forward. > > In my opinion option 3 is not an option - this is the working group > shirking its responsibility. > > Jon > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307abd034b3e0804cd5f3028 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jon:

You make some good points in the technical category if we are t= o not choose (3).=A0 Perhaps people could provide input and discussion in t= hese areas more as a guide.=A0 I realize these designs are not finalized an= d would evolve as part of the WG process but it would give us a better idea= on the starting line.

Design:=A0 Does it have the features we require of a modernized MANET p= rotocol? Does it perform well as a MANET protocol?=A0 Are its features well= -specified and clear to implement it both in an effective and interoperable= manner?=A0 Of course this is an evolving process since the WG will have so= me ownership of the design. Extensible?

Implementation/Running Code:=A0 Always a benefit and gives community a = chance to test features and report,etc. Confidence in going forward on STD = track path. Need some manet-oriented results to gain confidence in operatio= nal modes under particular expected scenarios.=A0 Also a beneficial if ther= e is prototype open source version available to broaden the exposure and ex= perimentation.=A0 Interops,etc ?

Maturity: Has it been used or gone through relevant use cases. Are any = algorithms or subprocesses well understood (goes along with design in that = sense)?




On Wed, Oct 31, 2012 at 1:57 PM, Jon Black <jblack.ietf@yahoo.com&= gt; wrote:
On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantage of this field test, we have been actively participating to the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what LOADng is capable of and are confident that future deployements will be equipped with it.=A0
=
This would seem to indicate that LOADng does work and in a rather large dep= loyment.

"We believe in rough consensus and running code"

rough consensus : Don't you think we have a rough consensus on LOADng compared to DYMO ? 10 authors and major companies are supporters of LOADng.

running code : interoperability has been checked with 4 sources and other implementations are in progress.

Obviously from the list we= don't have rough consensus.=A0 We have two alternatives each with prop= onents.=A0 The WG should weigh the technical benefits (design, implementati= on/running code, maturity)=A0 of each and the group should choose a path fo= rward.

In my opinion option 3 is not an option - this is the working group shi= rking its responsibility.
Jon


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307abd034b3e0804cd5f3028-- From axel-ietf@axelcdv.com Wed Oct 31 11:43:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CB921F8554 for ; Wed, 31 Oct 2012 11:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43hz-fMgRH+Y for ; Wed, 31 Oct 2012 11:43:10 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE3821F8550 for ; Wed, 31 Oct 2012 11:43:03 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 56C405598C6 for ; Wed, 31 Oct 2012 11:43:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A46D622019C; Wed, 31 Oct 2012 11:43:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.1.1.206] (Cs-136-214.CS.UCLA.EDU [131.179.136.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D15102201A6; Wed, 31 Oct 2012 11:42:59 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= In-Reply-To: <50916F40.3000804@computer.org> Date: Wed, 31 Oct 2012 11:43:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42BBDFE1-BD2D-484D-9D5B-4E246487F14A@axelcdv.com> References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com> <50916F40.3000804@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1499) Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:43:11 -0000 Hi Charlie, I still can't really understand both how and why you would want to = develop AODVv2 as "compatible with LOADng", for several reasons: 1) LOADng is still a work in progress. Being compatible with it makes = little sense if it keeps evolving. 2) If AODVv2 were to be made "compatible" with LOADng, it would = eventually become some form of LOADng + optional features. So, instead = of losing time and energy reformatting AODVv2 and following LOADng's = changes, and since you apparently want an alternative solution, why = wouldn't we adopt LOADng as the base protocol, and develop a draft = containing all of AODVv2's additional features? Best, Axel Le 31 oct. 2012 =E0 11:34, "Charles E. Perkins" = a =E9crit : >=20 > Hello Joe and all, >=20 > Thanks for reiterating this important point. I feel that some of the = discussion > is aimed at finding fault. For myself, I think that the LOADng effort = has made > a positive contribution. With some minor exceptions, LOADng is = basically > compatible with AODVv2 (almost by design, since both were derived from > AODV). I reiterate that my goal for the WG reactive document would be = to > retain compatibility with LOADng. In this way, the working group will = retain > the benefits of LOADng (by design), reducing the need for any mutually > exclusive choice of (1) or (2). I'd call this alternative (1.5). >=20 > In the meantime, I continue to offer improvements to the existing = AODVv2 > specification, and I am confident that the results will soon satisfy = the most > demanding level of scrutiny. >=20 > Regards, > Charlie P. >=20 > On 10/31/2012 11:14 AM, Joseph Macker wrote: >> Certainly if the LOADng derived work in whatever form is accepted by = manet it needs to be considered a manet protocol and analyzed and = designed as such in ongoing work. This point is non-negotiable and I = think the chairs made that clear at the last meeting but just to = reiterate the point so we do not need to keep going over that. >> -------- >>=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From wwwrun@rfc-editor.org Wed Oct 31 13:46:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9610021F8821; Wed, 31 Oct 2012 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.714 X-Spam-Level: X-Spam-Status: No, score=-101.714 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtxzsKCuENmz; Wed, 31 Oct 2012 13:46:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3000221F881E; Wed, 31 Oct 2012 13:46:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 68D41B1E007; Wed, 31 Oct 2012 13:39:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121031203952.68D41B1E007@rfc-editor.org> Date: Wed, 31 Oct 2012 13:39:52 -0700 (PDT) Cc: manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] RFC 6779 on Definition of Managed Objects for the Neighborhood Discovery Protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:46:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6779 Title: Definition of Managed Objects for the Neighborhood Discovery Protocol Author: U. Herberg, R. Cole, I. Chakeres Status: Standards Track Stream: IETF Date: October 2012 Mailbox: ulrich@herberg.name, robert.g.cole@us.army.mil, ian.chakeres@gmail.com Pages: 67 Characters: 131403 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-manet-nhdp-mib-19.txt URL: http://www.rfc-editor.org/rfc/rfc6779.txt This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK] This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From william.d.ivancic@nasa.gov Wed Oct 31 13:50:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28D21F871F for ; Wed, 31 Oct 2012 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC7vdJpDmYTP for ; Wed, 31 Oct 2012 13:50:44 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 34F4B21F8202 for ; Wed, 31 Oct 2012 13:50:44 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 177AA148014; Wed, 31 Oct 2012 15:50:39 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q9VKoUG8022930; Wed, 31 Oct 2012 15:50:38 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Wed, 31 Oct 2012 15:50:34 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Stan Ratliff (sratliff)" Date: Wed, 31 Oct 2012 15:50:36 -0500 Thread-Topic: DLEP-03 Thread-Index: Ac23qV+W2ijlEpx9SdGQ37gZ2WGa8Q== Message-ID: <81C3F2C0-4A64-46C9-9015-14FDFE843ED9@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_81C3F2C04A6446C9901514FDFE843ED9nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-31_03:2012-10-31, 2012-10-31, 1970-01-01 signatures=0 Cc: "manet@ietf.org" Subject: [manet] DLEP-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:50:45 -0000 --_000_81C3F2C04A6446C9901514FDFE843ED9nasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stan, I re-read DLEP-03. Some minor suggestions. In Section 4: The approach of allowing for different contexts for metric data increases both the flexibility and the complexity of using metric data. This document details the mechanism whereby the data is transmitted, however, the specific algorithms (precedence, etc) for utilizing the dual-context metrics is out of scope and not addressed by this document. It would be nice to have a reference to two showing examples of how this wo= uld be or is being used. In section 9: Comment: The usefulness of Items such as RESOURCES and RELATIVE QOS is que= stionable without some consistency between radio vendors and radio models f= rom the same vendor. It may be that only a cognitive system could decipher= this information into usable input or feedback. Suggestion: Perhaps a sentence indicating that the use of OPTIONAL Data Ite= m means a implementation does not have to send these requests, not that an = implementation does not have to implement these OPTIONAL Data Items. Also, there is some minor inconsistency in section 9 where OPTIONAL TLV are= implicitly called out for some Data Items but not others. This probably sh= ould be consistent. For example: The Credit Request TLV is an OPTIONAL TLV. The Heartbeat Interval/Threshold TLV is an OPTIONAL TLV. The Current Data Rate (CDR) TLV is used in Neighbor Up, Neighbor..... - Will --_000_81C3F2C04A6446C9901514FDFE843ED9nasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Stan,

I re-read DLEP-03.  Some minor suggestions.
=


In Section 4:

 The approach of allowing fo= r different contexts for metric data
increases both the flexibility and the complexity= of using metric
data. This document details the mechanism whereby the data is=
transmitted, howev= er, the specific algorithms (precedence, etc) for
utilizing the dual-context metrics is= out of scope and not addressed
by this document.
It would be ni= ce to have a reference to two showing examples of how this would be or is b= eing used.

In section 9:

= Comment:  The usefulness of Items such as RESOURCES and RELATIVE QOS i= s questionable without some consistency between radio vendors and radio mod= els from the same vendor.  It may be that only a cognitive system coul= d decipher this information into usable input or feedback.

Suggestion: Perhaps a sentence indicating that the use of OPTIONAL= Data Item means a implementation does not have to send these requests, not= that an implementation does not have to implement these OPTIONAL Data Item= s.  

Also, there is some minor inconsistency = in section 9 where OPTIONAL TLV are implicitly called out for some Data Ite= ms but not others. This probably should be consistent.  For example:

 The Credit Request TLV is an= OPTIONAL TLV.

 The Heartbeat Interval/Threshold TLV is an= OPTIONAL TLV.
<= span class=3D"Apple-style-span" style=3D"font-size: 13px;">
 The Current Data Rate (CDR) TLV is used in Neig= hbor Up, Neighbor.....

<= br>

- Will
= --_000_81C3F2C04A6446C9901514FDFE843ED9nasagov_-- From william.d.ivancic@nasa.gov Wed Oct 31 13:51:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55021F8821 for ; Wed, 31 Oct 2012 13:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDJiEUYvbIMg for ; Wed, 31 Oct 2012 13:51:01 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 44EDE21F8810 for ; Wed, 31 Oct 2012 13:51:01 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 991352D8071; Wed, 31 Oct 2012 15:51:00 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q9VKoLNu032325; Wed, 31 Oct 2012 15:50:59 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Wed, 31 Oct 2012 15:50:43 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Stan Ratliff (sratliff)" Date: Wed, 31 Oct 2012 15:50:44 -0500 Thread-Topic: DLEP-03 Thread-Index: Ac23qWTe1zu6nJYFSuC24nV+Q7tNVg== Message-ID: <12D349D8-D6C8-46C5-8448-4C5CF4ADF5FA@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_12D349D8D6C846C584484C5CF4ADF5FAnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-31_03:2012-10-31, 2012-10-31, 1970-01-01 signatures=0 Cc: "manet@ietf.org" Subject: [manet] DLEP-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:51:02 -0000 --_000_12D349D8D6C846C584484C5CF4ADF5FAnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stan, I re-read DLEP-03. Some minor suggestions. In Section 4: The approach of allowing for different contexts for metric data increases both the flexibility and the complexity of using metric data. This document details the mechanism whereby the data is transmitted, however, the specific algorithms (precedence, etc) for utilizing the dual-context metrics is out of scope and not addressed by this document. It would be nice to have a reference to two showing examples of how this wo= uld be or is being used. In section 9: Comment: The usefulness of Items such as RESOURCES and RELATIVE QOS is que= stionable without some consistency between radio vendors and radio models f= rom the same vendor. It may be that only a cognitive system could decipher= this information into usable input or feedback. Suggestion: Perhaps a sentence indicating that the use of OPTIONAL Data Ite= m means a implementation does not have to send these requests, not that an = implementation does not have to implement these OPTIONAL Data Items. Also, there is some minor inconsistency in section 9 where OPTIONAL TLV are= implicitly called out for some Data Items but not others. This probably sh= ould be consistent. For example: The Credit Request TLV is an OPTIONAL TLV. The Heartbeat Interval/Threshold TLV is an OPTIONAL TLV. The Current Data Rate (CDR) TLV is used in Neighbor Up, Neighbor..... - Will --_000_12D349D8D6C846C584484C5CF4ADF5FAnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Stan,

I re-read DLEP-03.  Some minor suggestions.
=


In Section 4:

 The approach of allowing fo= r different contexts for metric data
increases both the flexibility and the complexity= of using metric
data. This document details the mechanism whereby the data is=
transmitted, howev= er, the specific algorithms (precedence, etc) for
utilizing the dual-context metrics is= out of scope and not addressed
by this document.
It would be ni= ce to have a reference to two showing examples of how this would be or is b= eing used.

In section 9:

= Comment:  The usefulness of Items such as RESOURCES and RELATIVE QOS i= s questionable without some consistency between radio vendors and radio mod= els from the same vendor.  It may be that only a cognitive system coul= d decipher this information into usable input or feedback.

Suggestion: Perhaps a sentence indicating that the use of OPTIONAL= Data Item means a implementation does not have to send these requests, not= that an implementation does not have to implement these OPTIONAL Data Item= s.  

Also, there is some minor inconsistency = in section 9 where OPTIONAL TLV are implicitly called out for some Data Ite= ms but not others. This probably should be consistent.  For example:

 The Credit Request TLV is an= OPTIONAL TLV.

 The Heartbeat Interval/Threshold TLV is an= OPTIONAL TLV.
<= span class=3D"Apple-style-span" style=3D"font-size: 13px;">
 The Current Data Rate (CDR) TLV is used in Neig= hbor Up, Neighbor.....

<= br>

- Will
= --_000_12D349D8D6C846C584484C5CF4ADF5FAnasagov_-- From ietf@thomasclausen.org Wed Oct 31 14:50:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1663D21F883E for ; Wed, 31 Oct 2012 14:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_93=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtggGsHBL1Nb for ; Wed, 31 Oct 2012 14:50:17 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 17DD921F8558 for ; Wed, 31 Oct 2012 14:50:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id C977956FEFE for ; Wed, 31 Oct 2012 14:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5A98D1C07B2 for ; Wed, 31 Oct 2012 14:50:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.149.201.158] (unknown [37.160.27.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 533661C07DE for ; Wed, 31 Oct 2012 14:50:14 -0700 (PDT) References: <20121031203952.68D41B1E007@rfc-editor.org> From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10A403) In-Reply-To: <20121031203952.68D41B1E007@rfc-editor.org> Message-Id: <6FB5AA6F-2E7F-4A3F-BC85-48A360064949@thomasclausen.org> Date: Wed, 31 Oct 2012 22:50:11 +0100 To: " List" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [manet] RFC 6779 on Definition of Managed Objects for the Neighborhood Discovery Protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:50:18 -0000 Congrats, guys - and thanks. MIBs are a drag to work up right, and you've do= ne a splendid job! Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 31 oct. 2012, at 21:39, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6779 >=20 > Title: Definition of Managed Objects for=20 > the Neighborhood Discovery Protocol=20 > Author: U. Herberg, R. Cole, > I. Chakeres > Status: Standards Track > Stream: IETF > Date: October 2012 > Mailbox: ulrich@herberg.name,=20 > robert.g.cole@us.army.mil,=20 > ian.chakeres@gmail.com > Pages: 67 > Characters: 131403 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-manet-nhdp-mib-19.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6779.txt >=20 > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in the Internet > community. In particular, it describes objects for configuring > parameters of the Neighborhood Discovery Protocol (NHDP) process on a > router. The MIB module defined in this document, denoted NHDP-MIB, > also reports state, performance information, and notifications about > NHDP. This additional state and performance information is useful to > troubleshoot problems and performance issues during neighbor > discovery. [STANDARDS-TRACK] >=20 > This document is a product of the Mobile Ad-hoc Networks Working Group of t= he IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestion= s > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html= . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Wed Oct 31 14:57:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB8021F886D for ; Wed, 31 Oct 2012 14:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.396 X-Spam-Level: X-Spam-Status: No, score=-8.396 tagged_above=-999 required=5 tests=[AWL=2.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue5tSi1TK60U for ; Wed, 31 Oct 2012 14:57:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF3421F8853 for ; Wed, 31 Oct 2012 14:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3086; q=dns/txt; s=iport; t=1351720644; x=1352930244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=56HRnhLJHdLbDHVet6Hhr7gttuG8oI/8HvhtbVUmyJE=; b=nAUP3S9wFIzkfNTUCxMIJ67FpxkW5kcEnfxWZZT6QHZ1/oBaGO7D/R7t r3iqsNe7kjCZ0SC4zOXRFzbHWkN/dOLGkBtogJgAnll/miWaSiGc7Verm 6LrB2YhI3NikgsefWtRlCO8OgpCAj/YI+egf4hTBDOFCTTfcF9VUrgHl9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAGOekVCtJXHA/2dsb2JhbABEgkmDB74PgQiCHwEBBAEBAQ8BZhACAQgEChQkJwslAgQODRqHZAubDKAsBIt4hVphA6RNgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208,217";a="137507371" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2012 21:57:23 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9VLvNPZ006946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 21:57:23 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 16:57:23 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt7K0LPVi/cSo/ES1hdb7zda62w== Date: Wed, 31 Oct 2012 21:57:22 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204632D@xmb-rcd-x02.cisco.com> References: <1351704196.28009.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1351704196.28009.YahooMailNeo@web160603.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--38.402500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204632Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:57:25 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204632Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 31, 2012, at 6:23 PM, Jon Black wrote: On October 31, 2012 at 12:45 PM, JPVasseur wrote: >JP> Well let's see what the chairs think of course. Having all authors of = Load-NG supporting it was expected though. And hearing from the RPL authors not supporting it is expected. Well =85 quite frankly, the issue is using a reactive protocol in LLNs. I d= o support option 1 and this is a reactive protocol too. --_000_03B78081B371D44390ED6E7BADBB4A772204632Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <160F565012AF2648B35D4C24BAE9184B@cisco.com> Content-Transfer-Encoding: quoted-printable
On Oct 31, 2012, at 6:23 PM, Jon Black wrote:

On October 31, 2012 at 12:45 PM, JPVasseur wrote:

>JP> Well let's see what the chairs think of course. Having all = authors of Load-NG supporting it was expected though.

And hearing from the RPL authors not sup= porting it is expected.

Well =85 quite frankly, the issue is using a reactive protocol in LLNs= . I do support option 1 and this is a reactive protocol too.


--_000_03B78081B371D44390ED6E7BADBB4A772204632Dxmbrcdx02ciscoc_-- From jvasseur@cisco.com Wed Oct 31 15:00:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BB721F876A for ; Wed, 31 Oct 2012 15:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.13 X-Spam-Level: X-Spam-Status: No, score=-9.13 tagged_above=-999 required=5 tests=[AWL=1.468, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVuD4CPD9A4D for ; Wed, 31 Oct 2012 15:00:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D652221F873A for ; Wed, 31 Oct 2012 15:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9994; q=dns/txt; s=iport; t=1351720855; x=1352930455; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hDWiFZC1f850AMLznVAvv4OXv2Sw9xqg5zyFp8QLdq0=; b=iaoO4n+KDi/2gVBrHiyMIq3f94zDBthh0kKavur79f5hC9Z5/VZx7E8n vOPxcFVZoj0tiKy1ftTgP3QvmeaxlP9o2dZJA22YD/R1a+yMvqU+8+L+Y b/aqUabvY+dXdGTBV7nRBy23SEJe85XnGE4ShZUmTutqAx/kqk+hC+FHz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGOekVCtJXHA/2dsb2JhbABEgknBFoEIgh8BAQQBAQEPAVsLEAIBCA4UHQcnCxQRAgQOBQgah2QLmwygLASLeBuFP2EDpE2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208,217";a="134509807" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 31 Oct 2012 22:00:54 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9VM0sT6010562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 22:00:54 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 17:00:54 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt7MyLPVi/cSo/ES1hdb7zda62w== Date: Wed, 31 Oct 2012 22:00:53 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220463A9@xmb-rcd-x02.cisco.com> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--49.514700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220463A9xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:00:56 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77220463A9xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 31, 2012, at 6:48 PM, Jon Black wrote: Certainly smart meters are one of the types of networks that are MANETs. J= ust because houses do not move it does not mean that the connectivity betwe= en those meters isn't changing. A smart meter network is most certainly a = MANET. [One could argue that it is not an LLN since at least from the elec= trical power there is no lack of power.] JP> Just observe the loosiness on these network and how much on bandwidth y= ou get especially when using PLC and you will see why this is a LLN =85 Totally agree that one size does not fit all. Jon On October 31, 2012 John.Dowdell wrote: While I am very pleased for you and your co-authors that the LOADng work ha= s been so fruitful, I am not really sure that smart meters are really the k= ind of MANET devices that the working group was intended to address. I have= been party to the conversations for only a year or two, so I am very happy= to be corrected by those with longer histories, but MANET to me means dyna= mically moving nodes, with links being established and broken often and wit= hout prior warning. Examples may be communications networks built out of no= des contained in cars, trucks and aircraft of all sizes. I appreciate a com= ment on the list a while back that the RF environment for smart metering is= actually more difficult than one would think, but I would suggest to the c= hairs that unless LOADng has applications in this dynamically mobile enviro= nment (and I have to admit I have not read the spec in enough detail to det= ermine if this is the case), then we come to the conclusion that the DYMO/A= ODVv2 path should be followed unless we collectively feel that such a direc= tion is not worth pursuing (and note I am definitely not proposing that vie= w). In the two years or so that I have been working with MANETs, the only concl= usion I have come to is that very many use cases exist, and that one size d= oes not fit all. Regards John _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77220463A9xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <97FA5FCDA0E9854583666E42442D1F62@cisco.com> Content-Transfer-Encoding: quoted-printable
On Oct 31, 2012, at 6:48 PM, Jon Black wrote:

Certa= inly smart meters are one of the types of = networks that are MANETs.  Just because houses do not move it does not mean that th= e connectivity between those meters isn't changing.  A smart meter net= work is most certainly a MANET.  [One= could argue that it is not an LLN since at least from the electrical power there is no lack of power.]

JP> Just observe the loosiness on these network and how much on ban= dwidth you get especially when using PLC and you will see why
this is a LLN =85 


Total= ly agree that one size does not fit all.

=
  Jon

On October 31, 2012 John.Dowdell wrote= :

While I am very pleased for you and yo= ur co-authors that the LOADng work has been so fruitful, I am not really su= re that smart meters are really the kind of MANET devices that the working group was int= ended to address. I have been party to the conversations for only a year or= two, so I am very happy to be corrected by those with longer histories, bu= t MANET to me means dynamically moving nodes, with links being established and broken often and without pr= ior warning. Examples may be communications networks built out of nodes con= tained in cars, trucks and aircraft of all sizes. I appreciate a comment on= the list a while back that the RF environment for smart metering is actually more difficult than one woul= d think, but I would suggest to the chairs that unless LOADng has applicati= ons in this dynamically mobile environment (and I have to admit I have not = read the spec in enough detail to determine if this is the case), then we come to the conclusion that the DY= MO/AODVv2 path should be followed unless we collectively feel that such a d= irection is not worth pursuing (and note I am definitely not proposing that= view).
 
In the two years or so that I have bee= n working with MANETs, the only conclusion I have come to is that very many use cases exist, and that one size does not fit all.
 
Regards
 
John


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

--_000_03B78081B371D44390ED6E7BADBB4A77220463A9xmbrcdx02ciscoc_-- From jvasseur@cisco.com Wed Oct 31 15:09:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9D21F87EF for ; Wed, 31 Oct 2012 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.497 X-Spam-Level: X-Spam-Status: No, score=-9.497 tagged_above=-999 required=5 tests=[AWL=1.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VD0e2xH+A3w for ; Wed, 31 Oct 2012 15:09:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 147BD21F8721 for ; Wed, 31 Oct 2012 15:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9489; q=dns/txt; s=iport; t=1351721351; x=1352930951; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tyXolb8fjFWjxMcRmz0YY+Sl+r5SX825naItY9fc1TQ=; b=SkQxcZ8B9lyGXTfyN4E0J+QMk5I0RtAmtnPNgNno+QLBSw0Oq/16jgCO JDIB00IAnzrju4L7tcFNvz93UMGcp5lBOuao5zZZpUzzOlmAP+c8cakOm EufMbNE35ohsCqkh2mR8U5O7w2OCpf71RzfMlyBAYaKUbXviU0lfkZlQu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFehkVCtJXG//2dsb2JhbABEgknBFoEIgh8BAQQBAQEPAVsLEAIBCA4UHQcnCxQRAgQOBQgTB4dkC5sDoCwEi3iFWmEDpE2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208,217";a="137491507" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2012 22:09:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9VM96i1004411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 22:09:06 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 17:09:06 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] (no subject) Thread-Index: AQHNt7RXxBNcBUy08k2NlcZzRgkbFg== Date: Wed, 31 Oct 2012 22:09:05 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> In-Reply-To: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--36.063400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220464DAxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:09:12 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77220464DAxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77220464DAxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 31, 2012, at 6:57 PM, Jon Black wrote:

On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a rout= ing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating t= o the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what= LOADng is capable of and are confident that future deployements will be eq= uipped with it. 

This would seem to indicate that LOADng does work and in a rather large dep= loyment.

JP> No this means that LoadNG works in *a* network. But the major t= echnical difference here is that reactive routing is highly impacted
by the user traffic =85 If you poll a meter every 24 hours, it may wor= k perfectly well. Now if you start having more frequent traffic flows
you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to= mitigate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT ag= ainst reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows = =85 Lessons from the past show us how difficult it is to predict user =
applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 

Hope this helps. Once again, when/if required I would be happy to shar= e many results.



"We believe in rough consensus an= d running code"

rough consensus : Don't you think we h= ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com= panies are supporters of LOADng.

running code : interoperability has be= en checked with 4 sources and other implementations are in progress.

Obviously from the list we don't h= ave rough consensus.  We have two alternatives each with proponents.&n= bsp; The WG should weigh the technical benefits (design, implementation/run= ning code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.

This is an option =85 since listed by the chairs. I agree that we shou= ld avoid it, especially when I think we have a very reasonable solution
(option1).

JP.


Jon

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

--_000_03B78081B371D44390ED6E7BADBB4A77220464DAxmbrcdx02ciscoc_-- From jvasseur@cisco.com Wed Oct 31 15:10:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE50521F8871 for ; Wed, 31 Oct 2012 15:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIRYriGgeh3I for ; Wed, 31 Oct 2012 15:10:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3179A21F8870 for ; Wed, 31 Oct 2012 15:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1661; q=dns/txt; s=iport; t=1351721453; x=1352931053; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aEC4PQAcXG+QEwHfQFWvOVudC6W4cQa0776+tRCrk1Y=; b=Wk1RCHFyk6rI5AwKdhunCNYpe+mlmFDiijAuypCCzQzP4IwHhg/jl2UK k2nuAM3LXYc6SAfqSiTfvMMm9bRr+Y8FQkHAr4MUYsTpKL0td6379iXrv PDFVRTq2yjLgHw628msvhETppdWVuYrq42iRp1kBK7mc0ZxBbY+Y2s4Kt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMGgkVCtJV2c/2dsb2JhbABEw1+BCIIeAQEBAwEBAQEPASc0CxACAQgYChQQJwslAgQOBQgMDodeBgubAqAsBIt4hVphA6RNgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208";a="137511352" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2012 22:10:52 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9VMAqr4015360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 22:10:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 17:10:52 -0500 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt0HGLPVi/cSo/ES1hdb7zda62w== Date: Wed, 31 Oct 2012 22:10:52 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204655F@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com> <50916F40.3000804@computer.org> In-Reply-To: <50916F40.3000804@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--40.066400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <6BB349B4B51DF946BB8C4A780A980D63@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:10:54 -0000 On Oct 31, 2012, at 7:34 PM, Charles E. Perkins wrote: >=20 > Hello Joe and all, >=20 > Thanks for reiterating this important point. I feel that some of the dis= cussion > is aimed at finding fault. For myself, I think that the LOADng effort ha= s made > a positive contribution. With some minor exceptions, LOADng is basically > compatible with AODVv2 (almost by design, since both were derived from > AODV). I reiterate that my goal for the WG reactive document would be to > retain compatibility with LOADng. In this way, the working group will re= tain > the benefits of LOADng (by design), reducing the need for any mutually > exclusive choice of (1) or (2). I'd call this alternative (1.5). >=20 > In the meantime, I continue to offer improvements to the existing AODVv2 > specification, and I am confident that the results will soon satisfy the = most > demanding level of scrutiny. Which I believe seems to be the RIGHT thing to do for the WG and the commun= ity. Thanks Charlie. >=20 > Regards, > Charlie P. >=20 > On 10/31/2012 11:14 AM, Joseph Macker wrote: >> Certainly if the LOADng derived work in whatever form is accepted by man= et it needs to be considered a manet protocol and analyzed and designed as = such in ongoing work. This point is non-negotiable and I think the chairs = made that clear at the last meeting but just to reiterate the point so we d= o not need to keep going over that. >> -------- >>=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Wed Oct 31 15:12:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99D521F8891 for ; Wed, 31 Oct 2012 15:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.718 X-Spam-Level: X-Spam-Status: No, score=-9.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWVGHIr0Vw9f for ; Wed, 31 Oct 2012 15:12:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D8DA721F886E for ; Wed, 31 Oct 2012 15:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3376; q=dns/txt; s=iport; t=1351721543; x=1352931143; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/8323zJ3x4mKy5Q36RPvNJvC3QcrYFJi9Ok5sQs3fQs=; b=BwAMvwpIwycepaR3Vzm6t/6GC/P6AO4ySG+nSufN/3cT9RQG7kVAasKz FRo4zPqRqNXy1svnLb/nAMN+ISc5lG9vjlpjxGk58zR4IsnYZOFyKnTy4 6WSy1JzjabRNtOdfidEjohQRWqOtCWWuKLPQnmk/0rZUr+02TyxMj3dNh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANShkVCtJXHB/2dsb2JhbABEw1+BCIIeAQEBAgEBAQEBDwFbCxACAQgYCiQnCyUCBA4FCBqHXgYLmwOgMIt4G4U/YQOXEI09gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208";a="137511694" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2012 22:12:21 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9VMCLdS001467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 22:12:21 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 17:12:20 -0500 From: "JP Vasseur (jvasseur)" To: "Bo Berry (boberry)" Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt7TLLPVi/cSo/ES1hdb7zda62w== Date: Wed, 31 Oct 2012 22:12:20 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--50.994600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:12:24 -0000 Hi Bo, We need to be very careful there =85 these documents provide results that C= ANNOT be generalized to say the least. Hypothesis made on traffic flows are such that you get the results that you= would like to see =85 Thanks JP. On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >=20 > For background and perspective, ran across these two docs on the origin=20 > and performance of Loadng. The WG may find helpful. >=20 > -Bo >=20 >=20 > The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generati= on (LOADng)=09 > By T. Clausen. A. Colin de Verdiere.=20 > Published in INRIA Research Report 7692 on 2011-07-25. > http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4c77= 2e5af46f426e77ca581.pdf >=20 >=20 > A Comparative Performance Study of the Routing Protocols LOAD and RPL wit= h Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 > By T. Clausen, U. Herberg.=20 > Published in INRIA Research Report 7637 on 2011-06-01. > http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228cf6= 86a462108aef8332ceb.pdf >=20 >=20 >=20 >=20 > On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >=20 >> Certainly smart meters are one of the types of networks that are MANETs.= Just because houses do not move it does not mean that the connectivity be= tween those meters isn't changing. A smart meter network is most certainly= a MANET. [One could argue that it is not an LLN since at least from the e= lectrical power there is no lack of power.] >>=20 >> Totally agree that one size does not fit all. >>=20 >> Jon >>=20 >> On October 31, 2012 John.Dowdell wrote: >>=20 >> While I am very pleased for you and your co-authors that the LOADng work= has been so fruitful, I am not really sure that smart meters are really th= e kind of MANET devices that the working group was intended to address. I h= ave been party to the conversations for only a year or two, so I am very ha= ppy to be corrected by those with longer histories, but MANET to me means d= ynamically moving nodes, with links being established and broken often and = without prior warning. Examples may be communications networks built out of= nodes contained in cars, trucks and aircraft of all sizes. I appreciate a = comment on the list a while back that the RF environment for smart metering= is actually more difficult than one would think, but I would suggest to th= e chairs that unless LOADng has applications in this dynamically mobile env= ironment (and I have to admit I have not read the spec in enough detail to = determine if this is the case), then we come to the conclusion that the DYM= O/AODVv2 path sh > ould be followed unless we collectively feel that such a direction is not= worth pursuing (and note I am definitely not proposing that view). >>=20 >> In the two years or so that I have been working with MANETs, the only co= nclusion I have come to is that very many use cases exist, and that one siz= e does not fit all. >>=20 >> Regards >>=20 >> John >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From axel-ietf@axelcdv.com Wed Oct 31 15:26:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DA321F861D for ; Wed, 31 Oct 2012 15:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af7yt8ZQammW for ; Wed, 31 Oct 2012 15:26:08 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E5CDE21F8992 for ; Wed, 31 Oct 2012 15:26:07 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 26E91558C75 for ; Wed, 31 Oct 2012 15:26:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C3F7622171A; Wed, 31 Oct 2012 15:26:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.1.1.206] (Cs-136-214.CS.UCLA.EDU [131.179.136.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C4F33221716; Wed, 31 Oct 2012 15:26:03 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?windows-1252?Q?Axel_Colin_de_Verdi=E8re?= In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> Date: Wed, 31 Oct 2012 15:26:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1499) Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:26:08 -0000 Hi JP, As usual, there isn't just one situation, be it in MANETs in general or = in LLNs in particular. The simulations shown did make some assumptions = on the traffic, and some other assumptions might show different results, = but that's true of any protocol. Which is why I would also be interested = in your results concerning LOADng in LLNs. Best, Axel Le 31 oct. 2012 =E0 15:12, JP Vasseur (jvasseur) a = =E9crit : > Hi Bo, >=20 > We need to be very careful there =85 these documents provide results = that CANNOT be generalized to say the least. > Hypothesis made on traffic flows are such that you get the results = that you would like to see =85 >=20 > Thanks >=20 > JP. >=20 > On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >=20 >>=20 >> For background and perspective, ran across these two docs on the = origin=20 >> and performance of Loadng. The WG may find helpful. >>=20 >> -Bo >>=20 >>=20 >> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next = Generation (LOADng)=09 >> By T. Clausen. A. Colin de Verdiere.=20 >> Published in INRIA Research Report 7692 on 2011-07-25. >> = http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4c772= e5af46f426e77ca581.pdf >>=20 >>=20 >> A Comparative Performance Study of the Routing Protocols LOAD and RPL = with Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 >> By T. Clausen, U. Herberg.=20 >> Published in INRIA Research Report 7637 on 2011-06-01. >> = http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228cf68= 6a462108aef8332ceb.pdf >>=20 >>=20 >>=20 >>=20 >> On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >>=20 >>> Certainly smart meters are one of the types of networks that are = MANETs. Just because houses do not move it does not mean that the = connectivity between those meters isn't changing. A smart meter network = is most certainly a MANET. [One could argue that it is not an LLN since = at least from the electrical power there is no lack of power.] >>>=20 >>> Totally agree that one size does not fit all. >>>=20 >>> Jon >>>=20 >>> On October 31, 2012 John.Dowdell wrote: >>>=20 >>> While I am very pleased for you and your co-authors that the LOADng = work has been so fruitful, I am not really sure that smart meters are = really the kind of MANET devices that the working group was intended to = address. I have been party to the conversations for only a year or two, = so I am very happy to be corrected by those with longer histories, but = MANET to me means dynamically moving nodes, with links being established = and broken often and without prior warning. Examples may be = communications networks built out of nodes contained in cars, trucks and = aircraft of all sizes. I appreciate a comment on the list a while back = that the RF environment for smart metering is actually more difficult = than one would think, but I would suggest to the chairs that unless = LOADng has applications in this dynamically mobile environment (and I = have to admit I have not read the spec in enough detail to determine if = this is the case), then we come to the conclusion that the DYMO/AODVv2 = path sh >> ould be followed unless we collectively feel that such a direction is = not worth pursuing (and note I am definitely not proposing that view). >>>=20 >>> In the two years or so that I have been working with MANETs, the = only conclusion I have come to is that very many use cases exist, and = that one size does not fit all. >>>=20 >>> Regards >>>=20 >>> John >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Wed Oct 31 15:31:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE3F21F8885 for ; Wed, 31 Oct 2012 15:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYQ3NFfPCl0C for ; Wed, 31 Oct 2012 15:31:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EDA4721F883D for ; Wed, 31 Oct 2012 15:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4635; q=dns/txt; s=iport; t=1351722660; x=1352932260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YqhhBo05IQjKwJg6np0YCOIOaOVDmxnYQpLRhIMuCgc=; b=fn+0ew6QCPD7JfbRbtX884ro03U6BxA6smakrvvR7prEluZdTyhOx5FA CewHt9bjqsYe4pKxuhcCxVpA8euh1zquCQ8csAZocIeRNi0QOPWWB+uCZ 2pFKcM7LnocbKB5OumwbVQ9DLUBNnvaTjfwTjP+szZsbRpXVwTH2nV+04 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANmlkVCtJV2Y/2dsb2JhbABEw1+BCIIeAQEBAgEBAQEBDwFbCwULAgEIGAokJwslAgQOBQgRCYdeBgubBKAwi3gbhT9hA5cQjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208";a="137562792" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 31 Oct 2012 22:30:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9VMUxf0002164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 22:30:59 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 17:30:59 -0500 From: "JP Vasseur (jvasseur)" To: =?Windows-1252?Q?Axel_Colin_de_Verdi=E8re?= Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt7TLLPVi/cSo/ES1hdb7zda62w== Date: Wed, 31 Oct 2012 22:30:58 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204689F@xmb-rcd-x02.cisco.com> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> In-Reply-To: <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--53.570100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <3D77431B4313D94A83A49B0284DAB82A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:31:01 -0000 Hi Axel, On Oct 31, 2012, at 11:26 PM, Axel Colin de Verdi=E8re wrote: > Hi JP, >=20 > As usual, there isn't just one situation, be it in MANETs in general or i= n LLNs in particular. The simulations shown did make some assumptions on th= e traffic, and some other assumptions might show different results, but tha= t's true of any protocol. Which is why I would also be interested in your r= esults concerning LOADng in LLNs. >=20 Will send some results - but I think that the priority was to first see wha= t the chairs decide on which way to go. See this is the real issue with reactive routing in LLNs =85 assumption on = the traffic will dictate how the protocol performs and anyone with real life traces can easily reproduce the control plane behavior and s= ee dramatic limitations =85. Thanks. JP. > Best, >=20 > Axel >=20 > Le 31 oct. 2012 =E0 15:12, JP Vasseur (jvasseur) a = =E9crit : >=20 >> Hi Bo, >>=20 >> We need to be very careful there =85 these documents provide results tha= t CANNOT be generalized to say the least. >> Hypothesis made on traffic flows are such that you get the results that = you would like to see =85 >>=20 >> Thanks >>=20 >> JP. >>=20 >> On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >>=20 >>>=20 >>> For background and perspective, ran across these two docs on the origin= =20 >>> and performance of Loadng. The WG may find helpful. >>>=20 >>> -Bo >>>=20 >>>=20 >>> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Genera= tion (LOADng)=09 >>> By T. Clausen. A. Colin de Verdiere.=20 >>> Published in INRIA Research Report 7692 on 2011-07-25. >>> http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4c= 772e5af46f426e77ca581.pdf >>>=20 >>>=20 >>> A Comparative Performance Study of the Routing Protocols LOAD and RPL w= ith Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 >>> By T. Clausen, U. Herberg.=20 >>> Published in INRIA Research Report 7637 on 2011-06-01. >>> http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228c= f686a462108aef8332ceb.pdf >>>=20 >>>=20 >>>=20 >>>=20 >>> On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >>>=20 >>>> Certainly smart meters are one of the types of networks that are MANET= s. Just because houses do not move it does not mean that the connectivity = between those meters isn't changing. A smart meter network is most certain= ly a MANET. [One could argue that it is not an LLN since at least from the= electrical power there is no lack of power.] >>>>=20 >>>> Totally agree that one size does not fit all. >>>>=20 >>>> Jon >>>>=20 >>>> On October 31, 2012 John.Dowdell wrote: >>>>=20 >>>> While I am very pleased for you and your co-authors that the LOADng wo= rk has been so fruitful, I am not really sure that smart meters are really = the kind of MANET devices that the working group was intended to address. I= have been party to the conversations for only a year or two, so I am very = happy to be corrected by those with longer histories, but MANET to me means= dynamically moving nodes, with links being established and broken often an= d without prior warning. Examples may be communications networks built out = of nodes contained in cars, trucks and aircraft of all sizes. I appreciate = a comment on the list a while back that the RF environment for smart meteri= ng is actually more difficult than one would think, but I would suggest to = the chairs that unless LOADng has applications in this dynamically mobile e= nvironment (and I have to admit I have not read the spec in enough detail t= o determine if this is the case), then we come to the conclusion that the D= YMO/AODVv2 path sh >>> ould be followed unless we collectively feel that such a direction is n= ot worth pursuing (and note I am definitely not proposing that view). >>>>=20 >>>> In the two years or so that I have been working with MANETs, the only = conclusion I have come to is that very many use cases exist, and that one s= ize does not fit all. >>>>=20 >>>> Regards >>>>=20 >>>> John >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From ulrich@herberg.name Wed Oct 31 16:00:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF83921F8872 for ; Wed, 31 Oct 2012 16:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhEFbsyrMccL for ; Wed, 31 Oct 2012 16:00:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E821F886F for ; Wed, 31 Oct 2012 16:00:30 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2341173vbb.31 for ; Wed, 31 Oct 2012 16:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=PhP7KzpL3olPM13zgN9HWuflj5je78bzV90l8LBtJc4=; b=Di47HlBLZMVZGG+2Q+dz6XD7mDu5U8qRiphrW4Xe15Oih7R0VSarD6R29wGoIfqTdA p+NPCI8IH8yyskL753kQWAU0M4m42NRpfdpAfFZCxUBfhzJYD3o0rCHrsQWEjrIhwk2q q+tM6z6Zj3etZpT9+NS0rOz1/gleov3D1qzpM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=PhP7KzpL3olPM13zgN9HWuflj5je78bzV90l8LBtJc4=; b=eYo8kEz5eAdapooaRJXHDXPNPVdAlcIu8jQ0hvkuDM4xr4U90TNiWSGZiH9PjDdZmw rcO8NTND++lXz24VNfifk/OmclAK5j08C2hW1GRPDeg69lg+4LSiltKUaOwi1M6DQsA5 ri1++fRXUWMWMGW9+Lf//Zwqmwzx+uLADEc2+hWmguQEJ8eMxiO/EpPR667sul4Sfuik Qm5qm0HrrRy+qadevtwa54jRmrnuPzuKoSkeE0an1ZzuXkuPiT4+hsGlv0wH1tr8LZ6G 3Z8yNMpXVTR54YRjC6OJGxZJk/sAbJurtTkD7yTnGE7bHSJv27IiFztt13ZA4i0p3GQn Mhpw== MIME-Version: 1.0 Received: by 10.52.67.44 with SMTP id k12mr48563452vdt.15.1351724429590; Wed, 31 Oct 2012 16:00:29 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Wed, 31 Oct 2012 16:00:29 -0700 (PDT) Date: Wed, 31 Oct 2012 16:00:29 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf307abeb575c1fc04cd62de13 X-Gm-Message-State: ALoCoQlo4csiAI6hVXmUpyOkV4+avHUD5PY3aVVcbr0Y/jgFF1Hzd9bgKfw1fxh2GEJw0R4khMHH Subject: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 23:00:31 -0000 --20cf307abeb575c1fc04cd62de13 Content-Type: text/plain; charset=ISO-8859-1 Hello, for those who present at the MANET meeting: please send your slides (in ppt or pdf) to the chairs and me. Please send them by this weekend, so that I can upload the slides on Sunday. Thank you Ulrich --20cf307abeb575c1fc04cd62de13 Content-Type: text/html; charset=ISO-8859-1 Hello,

for those who present at the MANET meeting: please send your slides (in ppt or pdf) to the chairs and me. Please send them by this weekend, so that I can upload the slides on Sunday.

Thank you
Ulrich
--20cf307abeb575c1fc04cd62de13-- From trac+manet@trac.tools.ietf.org Tue Oct 30 10:42:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3931F21F8752 for ; Tue, 30 Oct 2012 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g5peqnE16G4 for ; Tue, 30 Oct 2012 10:42:23 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7B26E21F874E for ; Tue, 30 Oct 2012 10:42:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:37037 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTFpT-0000H5-6H; Tue, 30 Oct 2012 18:42:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 30 Oct 2012 17:42:19 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/2 Message-ID: <061.9ade0aa6aa05287725babd1e29bd3153@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 31 Oct 2012 16:09:59 -0700 Cc: manet@ietf.org Subject: [manet] #2: Terminology for reactive protocol document X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:42:24 -0000 #2: Terminology for reactive protocol document Several people have commented that the DYMO/AODVv2 specification is hard to understand. Part of the problem is that the terminology is not always consistent with the terminology used in other documents (e.g., OLSRv2). Also, some of the language used in the document is not very natural. Finally, important datasets within the reactive protocol document should be identified and used consistently within the specification. As one example, the fields of a Route Table Entry are already listed in section 4.1. Other such datasets should be identified and made more precise (for instance, as may be needed for blacklisted neighbors). Another possible source of confusion is that some terms (e.g., OrigNode) might be thought to mean different things in different parts of the document. The proposal is to use terminology from OLSRv2 where appropriate, and to change the names of other important concepts within the reactive protocol wherever they may be unclear, and to attempt to use terms that mean the same thing throughout the document. -- --------------------------------+--------------------------------- Reporter: charliep@… | Owner: Charlie Perkins Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: terminology clarity --------------------------------+--------------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Tue Oct 30 11:07:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49D21F8457 for ; Tue, 30 Oct 2012 11:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uClOCOzh9+P for ; Tue, 30 Oct 2012 11:07:45 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A92C621F8453 for ; Tue, 30 Oct 2012 11:07:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:39548 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTGDr-0003zz-EZ; Tue, 30 Oct 2012 19:07:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 30 Oct 2012 18:07:31 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/3 Message-ID: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 31 Oct 2012 16:09:59 -0700 Cc: manet@ietf.org Subject: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 18:07:46 -0000 #3: Use msg-hop-count in RFC 5444 header to limit # of hops The current AODVv2 specification uses msg-hop-limit to control the dissemination of routing messages. It is proposed instead to use msg-hop- count to have a direct hop count for disseminated routing messages, and to use a protocol constant to limit the number of hops (e.g., MAX_HOP_COUNT == 64). Even 64 is too much for practically any foreseeable ad hoc network. For networks that need to have finer-grained control (e.g., controlling dissemination to be less than the manifest constant), msg-hop- limit could be used for just those messages needing it. The specification can (independently) still specify TTL=255 according to RFC 5082. -- --------------------------------+---------------------------------- Reporter: charliep@… | Owner: Charlie Perkins Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: hop count, hop limit --------------------------------+---------------------------------- Ticket URL: manet From salo@saloits.com Wed Oct 31 16:24:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1D521F8554 for ; Wed, 31 Oct 2012 16:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlDoynBw2ysz for ; Wed, 31 Oct 2012 16:24:23 -0700 (PDT) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id D33E421F8551 for ; Wed, 31 Oct 2012 16:24:22 -0700 (PDT) Received: from [192.168.1.231] (mail.gdmfinancial.com [64.122.144.190] (may be forged)) by server.saloits.com (8.14.4/8.14.3) with ESMTP id q9VNOIPE025148; Wed, 31 Oct 2012 18:24:19 -0500 Message-ID: <5091B324.8000504@saloits.com> Date: Wed, 31 Oct 2012 18:24:20 -0500 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: "" References: <50906802.9070904@saloits.com> <03B78081B371D44390ED6E7BADBB4A7722041A10@xmb-rcd-x02.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 23:24:23 -0000 On 10/31/2012 10:25 AM, Ulrich Herberg wrote: > Hi JP, > Then please let me hear your technical arguments. So far, you > have been only saying that one protocol is in a "GREAT" shape, > the other is not, and I believe it is no secret that Cisco also > has a company roadmap in this space. I second this request for arguments based on technical differences between LOADng and DYMO. There seems to be a growing consensus that the LOADng and DYMO protocols are not all that different. Further, the DYMO protocol seems likely to become even more similar to LOADng. Yet, your email barrage strongly argues for DYMO over lOADng. Why? As far as I can tell, your technical arguments against LOADng are simply generic arguments against reactive protocols, arguments that appear to apply equally to LOADng and DYMO. If this not the case, please explain what features of DYMO make it scale better than LOADng. Your opposition to the LOADng specification is clear. However, I haven't seen you offer any technical arguments specific to LOADng (as opposed to arguments that are equally applicable to both LOADng and DYMO). Or, is this not really about technical issues? -tjs From jblack.ietf@yahoo.com Wed Oct 31 16:39:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB121F8602 for ; Wed, 31 Oct 2012 16:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCQBiyTQvUcy for ; Wed, 31 Oct 2012 16:39:39 -0700 (PDT) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8B21F851A for ; Wed, 31 Oct 2012 16:39:39 -0700 (PDT) Received: from [98.139.212.145] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 23:39:38 -0000 Received: from [98.139.212.198] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 23:39:38 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 23:39:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 363931.2597.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 20120 invoked by uid 60001); 31 Oct 2012 23:39:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351726778; bh=CrbjWIxb0gyoId85XvYrmvc4tXh0qjaC+zFGPRrwxgI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XlETEnKzUIC3xPBa52ubZ+go7XelGFOO0YrXrVImU/xdQ2ws1/wuqk4+jh08H27iq5L52POiOMIjRQlo7mXFSD5VuqtSchOdyuCMz0adMAg8ycabzc3t/bHRsWMyaewOfiCztXyaElQfxXhuEEJJzMPqfoAhY/xwSmHHz9FItjQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HBf9lrOMU0kJ8yoir3ogDbLXKlKIaSl47quGIrd+nLP+oEuPQjZyP+F8OcqyZmK8eEDqbAs3Q6cZYN74Oka6k7AQMZ0wXBD4c5AkQsMP0ICf+xZ+RDjmPk5cfYzrZ/8zaLFS5z1jWXa/yVo1dNLS1Mcjf0HfnYY60UuywSOg1N8=; X-YMail-OSG: uzW00OwVM1kF.MXXl_alEjPsXFv4UW4ImOJ6nrdXv.vVr3n EubAq_xxl4Y6pxQC1RuLYGRCWJPnwpe0EoepBX5corpElYYQWV5wdxARTHPq KVGsNtnD8nMK8w7SdjOagxDO12e3xvQt.QYjHYp6MiKMAMbqXHCPre7Y641G .aegqEB21Gf5u3BOzQp7kkYrJ9sNP9FzQiyrxIMFA3echHChfm2BYvIW7kke qVp6Yp1C57Bshsil8spWNJiI.HwV1hKz3GxLcJGZOcMko5ScMY4aZfKLM_f6 Vel786e6lvSD.glrZLIiohgywvmJJT8l1DzZNYiaJO0WkgKvvX.d6pSIKMTV VK1SwNPBObuBEXlxfzK7ddw591gWtt.mGm8iGOsV71Z2r0HVnjnpERMM2yID ejI0Lc90TlZyJTwaOVhr0Euy5cXoklKPanTR5Nn3U.0v4xep1tF2UhOzRNeE x7CbKDRy6 Received: from [173.193.202.116] by web160602.mail.bf1.yahoo.com via HTTP; Wed, 31 Oct 2012 16:39:37 PDT X-Rocket-MIMEInfo: 001.001, WWVzIGl0IHNob3dzIHRoYXQgaXQgZG9lcyB3b3JrIGluIGEgcmF0aGVyIGxhcmdlIGRlcGxveW1lbnQuwqAgSSBoYXZlIGhlYXJkIG90aGVycyBzYXkgdGhhdCBpdCB3b3JrcyBpbiBvdGhlciBkZXBsb3ltZW50cyBhcyB3ZWxsIC0ganVzdCB0aGUgc2FtZSBhcyB5b3Ugc2F5IFJQTCB3b3JrcyBpbiBzb21lIGRlcGxveW1lbnRzLgoKUGxlYXNlIHNoYXJlIHlvdXIgcmVzdWx0cy7CoCBZb3Uga2VlcHMgc2F5aW5nIHlvdSB3aWxsIGFuZCB5b3Ugd2Uga2VlcCBhc2tpbmcgeW91IHRvIC0gd2hlcmUncyB0aGUgcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> Message-ID: <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Wed, 31 Oct 2012 16:39:37 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-1989582210-1351726777=:19955" Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 23:39:40 -0000 ---1725615817-1989582210-1351726777=:19955 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes it shows that it does work in a rather large deployment.=C2=A0 I have h= eard others say that it works in other deployments as well - just the same = as you say RPL works in some deployments.=0A=0APlease share your results.= =C2=A0 You keeps saying you will and you we keep asking you to - where's th= e results so they can be reviewed.=0A=0A=0AJon=0A=0A=0A=0A_________________= _______________=0A From: JP Vasseur (jvasseur) =0ATo: J= on Black =0ACc: "manet@ietf.org" ; = "thierry.lys@erdfdistribution.fr" =0ASent= : Wednesday, October 31, 2012 4:09 PM=0ASubject: Re: [manet] (no subject)= =0A =0A=0A=0A=0AOn Oct 31, 2012, at 6:57 PM, Jon Black wrote:=0A=0AOn Octob= er 31, 2012 Thierry.Lys wrote:=0A>=0A>=0A>I speak in the name of EDF group.= =0A>=0A>We started first to use LOAD as a routing algorithm and deployed 2= 000 PLC-meters for smart grid purposes in 2011. Taking advantage of this fi= eld test, we have been actively participating to the working group to adopt= enhancements in the LOADng specification. =0A>We are now extremely pleased= with what LOADng is capable of and are confident that future deployements = will be equipped with it.=C2=A0=0A>=0A>=0A>This would seem to indicate that= LOADng does work and in a rather large deployment.=0A>=0A=0AJP> No this me= ans that LoadNG works in *a* network. But the major technical difference he= re is that reactive routing is highly impacted=0Aby the user traffic =E2=80= =A6 If you poll a meter every 24 hours, it may work perfectly well. Now if = you start having more frequent traffic flows=0Ayou can either cache paths (= ending up with more frequent broken paths considering how flappy these netw= orks are, thus leading to more=0Afloods =E2=80=A6 very undesirable =E2=80= =A6 especially when you have hundreds of meters sharing a few Kbits/s) or y= ou use short cache timers and you=0Akeep flooding :-( If you take actual tr= aces of these networks (both using 15.4g and P1901.2) and you start adjusti= ng the user traffic rate you=0Aimmediately see the issues in terms of scala= bility. Yes you can try to mitigate the undesirable flooding effect to some= extends but showing=C2=A0=0Athe limits in terms of scalability is easy to = show. Note that I MOT against reactive routing by any means, this is IMO ju= st not applicable to=0ALLNs unless the traffic flows are deterministic and = very well knows =E2=80=A6 Lessons from the past show us how difficult it is= to predict user=C2=A0=0Aapplications. We all started with meter reading to= continue with that example and now many utilities wants to use these smart= metering=C2=A0=0Anetworks for a number of applications which different SLA= , =E2=80=A6=C2=A0=0A=0AHope this helps. Once again, when/if required I woul= d be happy to share many results.=0A=0A=0A=0A>"We believe in rough consensu= s and running code" =0A>=0A>rough consensus : Don't you think we have a rou= gh consensus on LOADng compared to DYMO ? 10 authors and major companies ar= e supporters of LOADng. =0A>=0A>running code : interoperability has been ch= ecked with 4 sources and other implementations are in progress. =0A>=0A>Obv= iously from the list we don't have rough consensus.=C2=A0 We have two alter= natives each with proponents.=C2=A0 The WG should weigh the technical benef= its (design, implementation/running code, maturity)=C2=A0 of each and the g= roup should choose a path forward.=0A>=0A>In my opinion option 3 is not an = option - this is the working group shirking its responsibility.=0A>=0A=0ATh= is is an option =E2=80=A6 since listed by the chairs. I agree that we shoul= d avoid it, especially when I think we have a very reasonable solution=0A(o= ption1).=0A=0AJP.=0A=0A=0A>Jon=0A> =0A>=0A>=0A_____________________________= __________________=0A>manet mailing list=0A>manet@ietf.org=0A>https://www.i= etf.org/mailman/listinfo/manet=0A> ---1725615817-1989582210-1351726777=:19955 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes it sho= ws that it does work in a rather large deployment.  I have heard other= s say that it works in other deployments as well - just the same as you say= RPL works in some deployments.


Jon
From: JP Vasseur (jvasseur) <jvasseur@= cisco.com>
To: Jon = Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>; "thierry.lys@erd= fdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Wednesday, October 31, 2012 4:09 PM
Subject: Re: [manet] (no subject)

=0A
=0A=0A =0A=0A
=0A
=0A
=0AOn Oct 31, 2012, at 6:57 PM, Jon Black wrote:
=0A
=0A
=0A
=0A=0A
On = October 31, 2012 Thierry.Lys wrote:
=0A

=0A
=0A
=0AI speak in the name of EDF gr= oup.
=0A
=0AWe started f= irst to use LOAD as a routing algorithm and deployed 2000 PLC-meters for sm= art grid purposes in 2011. Taking advantage of this field test, we have bee= n actively participating to the working group to adopt enhancements=0A in t= he LOADng specification.
=0AWe are now extremely pleased with what LOADng is capable of and are confid= ent that future deployements will be equipped with it. 
= =0A
=0A
=0A=
=0A
=0AThis would seem to= indicate that LOADng does work and in a rather large deployment.
=0A=0A
=0A
=0A
=0A

=0A
=0A
JP> No= this means that LoadNG works in *a* network. But the major technical diffe= rence here is that reactive routing is highly impacted
=0A
by the = user traffic =E2=80=A6 If you poll a meter every 24 hours, it may work perf= ectly well. Now if you start having more frequent traffic flows
=0Ayou can either cache paths (ending up with more frequent broken paths con= sidering how flappy these networks are, thus leading to more
=0A
f= loods =E2=80=A6 very undesirable =E2=80=A6 especially when you have hundred= s of meters sharing a few Kbits/s) or you use short cache timers and you=0A
keep flooding :-( If you take actual traces of these networks (b= oth using 15.4g and P1901.2) and you start adjusting the user traffic rate = you
=0A
immediately see the issues in terms of scalability. Yes yo= u can try to mitigate the undesirable flooding effect to some extends but s= howing 
=0A
the limits in terms of scalability is easy to sho= w. Note that I MOT against reactive routing by any means, this is IMO just = not applicable to
=0A
LLNs unless the traffic flows are determinis= tic and very well knows =E2=80=A6 Lessons from the past show us how difficu= lt it is to predict user 
=0A
applications. We all started wi= th meter reading to continue with that example and now many utilities wants= to use these smart metering 
=0A
networks for a number of ap= plications which different SLA, =E2=80=A6 
=0A

=0A
= =0A
Hope this helps. Once again, when/if required I would be happy to s= hare many results.
=0A

=0A
=0A
=0A
=0A
=0A
=0A
= =0A
=0A"We believe in rough consens= us and running code"=0A
=0A
=0Arough consensus : Don't you think we have a rough consensus on LOADn= g compared to DYMO ? 10 authors and major companies are supporters of LOADn= g.=0A
=0A
=0Arunning code= : interoperability has been checked with 4 sources and other implementatio= ns are in progress.=0A
=0A
=0A
=0AObviously from the list we don't have rough consensus.&nbs= p; We have two alternatives each with proponents.  The WG should weigh= the technical benefits (design, implementation/running code, maturity)&nbs= p; of each and the group=0A should choose a path forward.
=0A
=0AIn m= y opinion option 3 is not an option - this is the working group shirking it= s responsibility.
=0A
=0A
=0A
=0A

= =0A
=0A
This is an option =E2=80=A6 since listed by the chairs. I = agree that we should avoid it, especially when I think we have a very reaso= nable solution
=0A
(option1).
=0A

=0A
=0A
JP= .
=0A
=0A
=0A
=0A
=0A
=0AJon
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A____________________________= ___________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet=0A
=0A
=0A
=0A
=0A=0A


= ---1725615817-1989582210-1351726777=:19955-- From charliep@computer.org Wed Oct 31 19:00:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2141A21F88E0 for ; Wed, 31 Oct 2012 19:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFVKpTLQbckr for ; Wed, 31 Oct 2012 19:00:07 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0669C21F87EB for ; Wed, 31 Oct 2012 19:00:06 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTk4j-0002lE-BN; Wed, 31 Oct 2012 22:00:05 -0400 Message-ID: <5091D7A0.8090808@computer.org> Date: Wed, 31 Oct 2012 19:00:00 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ulrich Herberg References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090504080805010407000402" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b5d0187d892c6698cbe0ef7cbb38a781350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet@ietf.org Subject: Re: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 02:00:08 -0000 This is a multi-part message in MIME format. --------------090504080805010407000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Ulrich, If I can make a presentation about AODVv2, I would like to do that. Regards, Charlie P. On 10/31/2012 4:00 PM, Ulrich Herberg wrote: > Hello, > > for those who present at the MANET meeting: please send your slides > (in ppt or pdf) to the chairs and me. Please send them by this > weekend, so that I can upload the slides on Sunday. > > Thank you > Ulrich > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------090504080805010407000402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Ulrich,

If I can make a presentation about AODVv2, I would like to do that.

Regards,
Charlie P.


On 10/31/2012 4:00 PM, Ulrich Herberg wrote:
Hello,

for those who present at the MANET meeting: please send your slides (in ppt or pdf) to the chairs and me. Please send them by this weekend, so that I can upload the slides on Sunday.

Thank you
Ulrich


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



-- 
Regards,
Charlie P.
--------------090504080805010407000402-- From ulrich@herberg.name Wed Oct 31 19:29:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A072321F8600 for ; Wed, 31 Oct 2012 19:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhE3uG8Y0pq1 for ; Wed, 31 Oct 2012 19:29:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B881521F8529 for ; Wed, 31 Oct 2012 19:29:09 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2465105vcb.31 for ; Wed, 31 Oct 2012 19:29:09 -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=qsDa687Vn+2pEvq1CNxsUYQAe1qer7zrvWKsiQWeFwY=; b=MrroZ5aImvqdOyqOwxNpDOovoaUgWH/a/1S7Or4aSdDTFMRhQBR0a02DLUamCWa2xZ eQyvpnH3v1Q1va3TEifufMsVqkDWoDmtclcJbZXcFXqYu8PGc6Zr2bNRF1pv+i+uiYSQ CrEZu2b0qpazw13ybGpRkzKdvv74EmoWkL8rM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qsDa687Vn+2pEvq1CNxsUYQAe1qer7zrvWKsiQWeFwY=; b=hHzLbXszNfJ6avlNCKVDWMRKh7U+PGKVl3bfvZjsFBkVptlYoL+ESWwX9Eq10pRRVn ZR2RDU5iNFhlHb6kta1HTb64vC2gyW1CMcVqy4zeWuEZx4u0gN2CblE/5RDO7BIgJ70F dAwzg9Pu4O8VgTZLQnLW9DZz+Nl/+BNUEdQXJ+Cml2Pj6BPDZwT3E7alnY2pnWXgFCda C70ITAT9MuyUZ6TqXpe09frwz+y6kg+7zeNKKK/5A7AunUlARBwNypZbmP5iGTOT0oDL UmPm8aFnzFHeejg/RTffRsAknIjvunkN2anm9KWueRQVHmtFQdSnFPgb766Ss41hWqd2 jPQg== MIME-Version: 1.0 Received: by 10.52.67.44 with SMTP id k12mr49085932vdt.15.1351736949181; Wed, 31 Oct 2012 19:29:09 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Wed, 31 Oct 2012 19:29:09 -0700 (PDT) In-Reply-To: <5091D7A0.8090808@computer.org> References: <5091D7A0.8090808@computer.org> Date: Wed, 31 Oct 2012 19:29:09 -0700 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf307abeb5af8b4904cd65c89f X-Gm-Message-State: ALoCoQmQlwo2y4Vv9B4M8RbbspCW1x6X+fMCKS5BlEKPs0v8xdD7kPrPjCmn9w65fef5aPend7Tc Cc: manet@ietf.org Subject: Re: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 02:29:10 -0000 --20cf307abeb5af8b4904cd65c89f Content-Type: text/plain; charset=ISO-8859-1 Hello Charlie, I wrote this email in my function as WG secretary. It is up to the chairs to decide the slots and who presents. I simply upload the slides and assist the chairs with organizing the meeting. Best regards Ulrich On Wed, Oct 31, 2012 at 7:00 PM, Charles E. Perkins wrote: > > Hello Ulrich, > > If I can make a presentation about AODVv2, I would like to do that. > > Regards, > Charlie P. > > > > On 10/31/2012 4:00 PM, Ulrich Herberg wrote: > > Hello, > > for those who present at the MANET meeting: please send your slides (in > ppt or pdf) to the chairs and me. Please send them by this weekend, so that > I can upload the slides on Sunday. > > Thank you > Ulrich > > > _______________________________________________ > manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet > > > > -- > Regards, > Charlie P. > > --20cf307abeb5af8b4904cd65c89f Content-Type: text/html; charset=ISO-8859-1 Hello Charlie,

I wrote this email in my function as WG secretary. It is up to the chairs to decide the slots and who presents. I simply upload the slides and assist the chairs with organizing the meeting.

Best regards
Ulrich

On Wed, Oct 31, 2012 at 7:00 PM, Charles E. Perkins <charliep@computer.org> wrote:

Hello Ulrich,

If I can make a presentation about AODVv2, I would like to do that.

Regards,
Charlie P.



On 10/31/2012 4:00 PM, Ulrich Herberg wrote:
Hello,

for those who present at the MANET meeting: please send your slides (in ppt or pdf) to the chairs and me. Please send them by this weekend, so that I can upload the slides on Sunday.

Thank you
Ulrich


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



-- 
Regards,
Charlie P.

--20cf307abeb5af8b4904cd65c89f-- From jpmacker@gmail.com Wed Oct 31 19:34:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1C21F8545 for ; Wed, 31 Oct 2012 19:34:37 -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.407, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9+o26300BZf for ; Wed, 31 Oct 2012 19:34:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C023D21F8543 for ; Wed, 31 Oct 2012 19:34:36 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2468516vcb.31 for ; Wed, 31 Oct 2012 19:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KAJp1McocnD/5QZ7wS2qvGm47WJeoJ5qD8sKMI6dgyU=; b=hREEzd6tcHPLzX3WO2BxlAAAdgwEQhE1zNxEE11BXHLDLdYUGo/Kfv1BLrMRWGADuK zKUFTPo9mlXgNCF/L3tywXs8sOYzDZV7+FH9O7TnN7QNsefr/NcBDe0DkfV2o10ybWfX bzwM6XUM3/7EwmL9uDEzHV9bkOeiWGGg/OGhtAHsodba/692nXaasbz+lx23HtXD6aKx 1bsEthllSf96+Baz3ipnzw2MjLpkB7GGeWVlKCMqT/bKKtAOsBwW+C/ebkkg5Jr5vpwx nTBtRVG15aEF17hDNTdqphhVWeZcoBS9m/UO94lyQZHXkq5mTIMnwl8vLDVHf7wcT0od uZcA== MIME-Version: 1.0 Received: by 10.52.91.204 with SMTP id cg12mr49017227vdb.98.1351737276147; Wed, 31 Oct 2012 19:34:36 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Wed, 31 Oct 2012 19:34:36 -0700 (PDT) In-Reply-To: References: <5091D7A0.8090808@computer.org> Date: Wed, 31 Oct 2012 22:34:36 -0400 Message-ID: From: Joseph Macker To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf307ac4e52ca96104cd65dcaa Cc: "manet@ietf.org" Subject: Re: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 02:34:37 -0000 --20cf307ac4e52ca96104cd65dcaa Content-Type: text/plain; charset=ISO-8859-1 Yes slots for DYMO and LOADng authors were both requested and will be accomodated. We left ample time for reactive discussion on the schedule. -Joe On Wed, Oct 31, 2012 at 10:29 PM, Ulrich Herberg wrote: > Hello Charlie, > > I wrote this email in my function as WG secretary. It is up to the chairs > to decide the slots and who presents. I simply upload the slides and assist > the chairs with organizing the meeting. > > Best regards > Ulrich > > > On Wed, Oct 31, 2012 at 7:00 PM, Charles E. Perkins > wrote: > >> >> Hello Ulrich, >> >> If I can make a presentation about AODVv2, I would like to do that. >> >> Regards, >> Charlie P. >> >> >> >> On 10/31/2012 4:00 PM, Ulrich Herberg wrote: >> >> Hello, >> >> for those who present at the MANET meeting: please send your slides (in >> ppt or pdf) to the chairs and me. Please send them by this weekend, so that >> I can upload the slides on Sunday. >> >> Thank you >> Ulrich >> >> >> _______________________________________________ >> manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet >> >> >> >> -- >> Regards, >> Charlie P. >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307ac4e52ca96104cd65dcaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes slots for DYMO and LOADng authors were both requested and will be accom= odated.
We left ample time for reactive discussion on the schedule.
<= br>-Joe


On= Wed, Oct 31, 2012 at 10:29 PM, Ulrich Herberg <ulrich@herberg.name&= gt; wrote:
Hello Charlie,

I wrote th= is email in my function as WG secretary. It is up to the chairs to decide t= he slots and who presents. I simply upload the slides and assist the chairs= with organizing the meeting.

Best regards
Ulrich


On Wed, Oct 31, 2012 at 7:00 PM, Charles E. Perkins <charliep@computer.org> wrote:
=20 =20 =20

Hello Ulrich,

If I can make a presentation about AODVv2, I would like to do that.

Regards,
Charlie P.



On 10/31/2012 4:00 PM, Ulrich Herberg wrote:
Hello,

for those who present at the MANET meeting: please send your slides (in ppt or pdf) to the chairs and me. Please send them by this weekend, so that I can upload the slides on Sunday.

Thank you
Ulrich


_______________________________________________
manet mailing list
manet@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307ac4e52ca96104cd65dcaa--